In BusinessChat, a Ticket is the core work item category designed for structured, cross-team collaboration. While conversations in the Inbox handle immediate customer interactions , Tickets manage the underlying work that requires help from other departments or third parties.
Unlike loose chats, Tickets are bound by strict timelines, auto-routed to specialized teams, and fully measurable.
1. Core Properties of a Ticket
Every Ticket in the system shares a robust underlying architecture but possesses distinct functional constraints:
One-to-One Contact Relationship: A Ticket must always be linked to exactly one customer contact. It cannot float without an owner or be attached to multiple people.
Stable Identity: Every ticket is assigned an immutable, UUID-style BusinessChat ID (e.g., TKT-2043). This ID stays the same even through reopens or external API lookups. It also supports an optional external_id for third-party integrations.
No Personal Tickets: Work is always owned by an accountable team, never purely by an individual.
Workload and Assignment Limits: The system enforces no maximum cap on the number of open tickets assigned to a single team member. If other team members are unavailable or deleted, round-robin can continue to route items to the same person.
Visibility vs. Historical Participation: Ticket visibility strictly follows your current team assignment, not historical involvement. Team members can see all tickets currently assigned to anyone within their designated team. However, "Participants"—which includes the original creator and any user ever assigned to the ticket—will continue to receive activity notifications for the entire lifetime of the ticket, even if the ticket is routed completely away from their team queue.
2. Setting Up Ticket Types
To prevent the chaos of free-form notes, admins configure specialized Ticket Types (such as Returns, Refunds, or Tech Support). Each Type acts as a template that controls these key areas:
Details, Fields, and Forms
Identity: Each type is configured with an emoji, a mandatory name, and a description.
Global Field Library: Tickets draw from a centralized pool of fields. While Title and Description are mandatory across all tickets , admins can add as many manual or reference fields (like an integrated Shopify Order ID) as needed, control their layout order, and choose which are mandatory per workflow.
Archiving/Deleting: Removing a custom field or archiving a ticket config acts as a "soft delete," impacting frontend visibility while preserving baseline database history.
Tag Groups
Admins can build custom Tag Groups tailored specifically to Tickets.
Users can select exactly one tag per group (e.g., a "Priority" group with color-coded options like High, Medium, or Low) to seamlessly filter, view, and organize queues.
3. The 5-Stage Lifecycle & The SLA Clock
All tickets conform to a rigorous, five-stage lifecycle. While you can add, rename, or reorder company-specific sub-statuses (like placing "Under Investigation" inside In Progress), you cannot alter the structural logic of the parent stages.
Parent Stage | Meaning & System Logic | SLA Clock Behavior |
Submitted | Ticket is created but not yet claimed or actively worked. | TTR Starts: The resolution timer begins running immediately. |
In Progress | Active coordination or technical work is underway. | Running: Clock ticks continuously. |
Waiting on Customer | Blocked strictly by an external customer dependency. | Paused: The clock halts. This is the only state where your team isn't penalized for delays. |
Resolved | Terminal state indicating work is complete. Triggers final notifications and surveys. | Stopped: Clock freezes permanently unless the ticket is reopened. |
Canceled | Terminal state indicating the ticket was called off or invalidated. | Stopped: Clock freezes permanently. |
Active SLA Risk Tracking
While a ticket is open (in the Submitted or In Progress stages), the system dynamically categorizes its SLA status based on the time remaining against its global target:
Low Risk: More than 25% of the total SLA time remains.
Moderate Risk: 25% or less of the total SLA time remains.
High Risk: 10% or less of the total SLA time remains.
Breached: The ticket has passed its total allocated resolution time.
⚠️ The Critical SLA Distinction: Sub-statuses mapping to internal or third-party blocks (e.g., "Waiting on Vendor" or "Legal Review") must live under the In Progress stage. Because your business still owns accountability for the case, the SLA clock will keep running.
4. Automation: Assignment and Routing Rules
Tickets use a deterministic "Round-robin, then Sticky" model to allocate work fairly without losing operational context:
Round-Robin Routing: Each custom sub-status is mapped to an owning department or team. The very first time a ticket moves into that status, the system automatically assigns it to an active member of that team in a balanced rotation.
Sticky Memory: If a ticket leaves a team (e.g., goes to Waiting on Customer) and later returns to that same sub-status, it bypasses the rotation and routes straight back to the exact agent who handled it last. This avoids constant re-explaining and handoff confusion.
Creator Team Sticky Rules: Configs can alternatively toggle an option to force a ticket back to its original creator/creator team under specific status changes. Once a ticket is generated, its designated Creator Team remains entirely immutable to lock in historical accountability.
Manual Overrides & Deletions: Admins and authorized teammates can manually reassign a ticket at any point. Doing so updates the ticket's "sticky memory" for that status moving forward. If a user account is deleted, the system forces an admin to select a specific backfill user, team, or default back to fresh round-robin routing.
5. Automated Customer Communications & CSAT
Tickets feature built-in customer communication rules that link back to the live customer chat without muddying internal work:
Resolution Notifications: Admins can designate one specific Resolved sub-status to trigger an automated outbound message. The system pulls a pre-approved template aligned with the customer's defined language profile. If no language is explicitly set, it falls back to your primary active template.
CSAT Integration: Reaching that designated Resolved sub-status can instantly trigger your native BusinessChat CSAT automation engine. You can customize an optional delay (e.g., sending the survey immediately, +1 hour, or +24 hours post-resolution) to gather precise 1-to-5 star or thumbs-up performance feedback.
Advanced CSAT Rules: A single Ticket Type can be mapped to multiple distinct CSAT automations, provided that each rule is triggered by a different Resolved sub-status (a single status can map to at most one automation).
Survey Cancellation Logic: If a ticket is reopened before its configured survey send-delay expires, the pending survey is instantly canceled by the system. Furthermore, to protect the customer experience, a customer will be surveyed at most once per single resolution round.
6. How the Reopen Process Works
Reopening a ticket is handled natively through regular status transitions rather than a separate "Reopen" button.
The Trigger: When an agent manually edits a ticket's status out of Resolved or Canceled and pushes it back into an active In Progress or Submitted state, the system automatically detects the change and logs a reopen event.
Customer Interaction Rule: Customer replies to an old WhatsApp or web-chat thread do not automatically reopen tickets. Conversations are always-open from the customer's point of view, but tickets must be explicitly managed or moved by your team.
Consequences: Pushing a ticket back to an open status increments its permanent reopen_count field, logs a line item in the internal activity feed, and instructs the existing SLA clock to resume counting exactly from where it left off. No secondary tracking ticket is ever generated.
Inbox Conversation Synchronization: Ticket creation and resolution events are explicitly mirrored inside your chat conversation view. Pushing a ticket to a terminal Resolved state or executing a manual Reopen instantly injects a historical timeline marker directly into the customer's chat thread so agents maintain real-time context. Note that intermediate sub-status transitions are hidden from the customer chat and do not alter the standalone conversation status.
7. How to create a new ticket
To create a new ticket for any case you would like to handle through this workflow, such as refunds, follow these steps:
From your profile icon, click on Settings
Choose Work Items and click on "Create Work Item Type". Name your ticket and choose an emoji and click "Create"
In the next page, you will be able to fill out all the ticket sections. Add a ticket description to serve as a reminder for your team.
Click the Fields dropdown to add the fields you need in this ticket type (exp: number, order reference...). Note: fields are preconfigure, but you can add custom field types. Toggle on or off, based on which fields are required and which are optional. Also, you can delete any field.
In the States section, add any sub-statuses you need under the pre-configured 5 main statuses, and assign the relevant team for each status. To add a sub-status, click "Add state" under the relevant Status and choose from the dropdown.
Note: you can delete a sub-status, but you cannot delete a pre-configured Status.
From the SLA section, choose the time to resolve (exp:24H) and choose the SLA calendar from the pre-configured option or create your own.
To create your own SLA calendar, click "New Calendar" and fill in your team's shifts or SLAs.
From the Notifications section, pick a WhatsApp template, and configure the sending time.Toggle on the CSAT request if you want and determine when to send it.
Once you finish setting up th five sections of the ticket, click "Create" to create the new ticket type.
Flat Internal Discussion Feed: Every ticket features a single, chronologically ordered collaboration feed at the bottom of its details page where internal team comments and system alerts merge. Note that formatting is flat—nested comment threading is entirely unsupported. Type `@` to mention an individual teammate, which instantly issues them an in-app notification and automatically subscribes them as a permanent participant to the ticket.
Note: you can edit any ticket's fields anytime. Just click the Pen icon next to the ticket name, edit what you want and save.
