Ticket Management

Tickets are the central unit of work in RapiDesq. Every customer interaction — whether it arrives through live chat, email, a web form, or the service desk — becomes a fully trackable ticket with a complete lifecycle, AI-powered analysis, performance metrics, and a rich audit trail. This guide covers every aspect of working with tickets.

Overview

A ticket represents a single customer request or issue from the moment it is received until it is fully resolved and closed. Tickets are created automatically when a customer initiates a conversation through any supported channel — Chat, Email, Web Form, or Service Desk — or they can be created manually by agents for interactions that happen outside digital channels.

Every ticket stores a comprehensive set of data:

• Identity — A unique internal UUID (id) and a human-readable display ID (displayId) such as "SUP-1234".
• Content — A subject (ticket title) and a full description that can be plain text or HTML.
• Relationships — Links to the customer contactId, the real-time conversationId, the assigned teamId, and the assignedAgentId.
• Classification — Status, priority, tags, and tenant-defined custom fields.
• AI Insights — Sentiment analysis, extracted key points, and an urgency score.
• Performance Metrics — First response time, resolution time, closure attribution, and timestamps for every lifecycle event.
• Internal Notes — A dedicated, agent-only conversation thread for private collaboration.
• Flow Context — If the ticket was routed through a conversation flow, the flowId, flowVersion, and current flowState are preserved.

Ticket Lifecycle

Every ticket progresses through six statuses that reflect where it stands in the resolution process. Understanding these statuses and the transitions between them is essential for managing your queue effectively.

Statuses

Status Transitions

Tickets follow a defined set of transitions. The diagram below illustrates the full lifecycle flow:

  +-------+         +----------+         +-------------+
  |  NEW  | ------> | ASSIGNED | ------> | IN_PROGRESS |
  +-------+         +----------+         +------+------+
                                                |     ^
                                    Agent       |     | Customer
                                    waiting     v     | replies
                                          +---------+ |
                                          | WAITING  |-+
                                          +---------+
                                                |
                                     Agent      | (back to IN_PROGRESS
                                     resolves   |  on customer reply)
                                                v
                                          +----------+         +--------+
                                          | RESOLVED | ------> | CLOSED |
                                          +----+-----+         +--------+
                                               |
                                               | Customer reopens
                                               v
                                          +-------------+
                                          | IN_PROGRESS |
                                          +-------------+
      

Transition Details

• NEW → ASSIGNED — Triggered when an agent manually picks up the ticket from the queue, or when the team's routing strategy (round-robin, PRIORITY_FIFO, etc.) automatically assigns it to an available agent. The assignedAgentId and assignedAt timestamp are recorded.
• ASSIGNED → IN_PROGRESS — Triggered when the assigned agent begins working on the ticket, typically by sending the first reply or explicitly starting work. The firstResponseAt timestamp is recorded on the first customer-facing reply.
• IN_PROGRESS → WAITING — Triggered when the agent has asked the customer a question or is waiting on information from an external party. This status keeps the ticket visible but signals that the agent cannot make further progress until a response arrives.
• WAITING → IN_PROGRESS — Triggered automatically when the customer sends a new reply to the conversation. The ticket returns to the agent's active queue so the response is not missed.
• IN_PROGRESS → RESOLVED — Triggered when the agent marks the issue as resolved via the resolve() action. The resolvedAt timestamp and resolutionTimeSeconds (time elapsed from creation to resolution) are calculated and stored.
• RESOLVED → CLOSED — Triggered when a supervisor or agent explicitly closes the ticket, or after a configurable timeout period with no customer follow-up. Closure records the closedByUserId, closureReason, and closedAt timestamp.
• RESOLVED → IN_PROGRESS — Triggered when a customer replies to a resolved ticket, effectively reopening it. This ensures no follow-up is ever lost. The resolution metrics are preserved, and new resolution metrics will be calculated if the ticket is resolved again.

Ticket Display IDs

While every ticket has an internal UUID for system-level operations, agents and customers interact with tickets using a human-readable display ID. Display IDs are constructed from the assigned team's ticket prefix and a sequential number within the tenant.

How Display IDs Work

• Each team defines a short ticket prefix during setup (for example, "SUP" for a Support team, "BIL" for Billing).
• When a ticket is created and assigned to a team, RapiDesq generates the next sequential number for that tenant and combines it with the team prefix.
• The resulting display ID follows the format PREFIX-NNNN, zero-padded for consistency.

Examples

Priorities

Every ticket carries a priority that determines its position in agent queues and affects SLA calculations. RapiDesq supports four priority levels:

Priority and Queue Ordering

When a team uses the PRIORITY_FIFO routing strategy, tickets are ordered by priority first and then by creation time within each priority level. This means an URGENT ticket that arrived five minutes ago will always appear above a LOW ticket that has been waiting for an hour. Agents working from the top of their queue will always address the most critical work first.

Setting Priority

• Manual — Agents and supervisors can set or change a ticket's priority at any time from the ticket detail view.
• Conversation Flows — An UPDATE_TICKET node in a conversation flow can set priority based on customer responses or routing logic.
• AI Urgency Scoring — RapiDesq's AI analysis assigns an urgency score from 0 to 100 based on the ticket content. While this score does not automatically change the priority, it is displayed alongside the ticket and can be used by agents and supervisors to quickly identify tickets that may need escalation. See the AI-Powered Analysis section for details.

Custom Fields

Custom fields let you capture structured data specific to your business on every ticket. They are stored as a flexible JSONB object, allowing each tenant to define the fields that matter to them without any schema changes.

Supported Field Types

Defining Custom Fields

1. Navigate to Admin > Ticket Settings > Custom Fields.
2. Click Add Field and select the field type.
3. Enter a field name and configure any type-specific options (for example, the list of values for a dropdown).
4. Save the field. It will immediately appear on the ticket detail view for all agents to populate.

Populating Custom Fields Automatically

Custom fields do not have to be filled in manually. There are two powerful automation paths:

• Conversation Flows — An UPDATE_TICKET node in a flow can set custom field values based on information gathered during the conversation. For example, a flow that asks the customer to select their product category can write that selection directly into a custom dropdown field.
• Web Form Mappings — When configuring a web form, you can map form fields directly to ticket custom fields. When the customer submits the form, the custom field values are populated automatically on the resulting ticket.

Tags

Tags provide a flexible, free-form way to categorize and label tickets. Unlike custom fields that have defined types and structures, tags are simple strings stored as an array on each ticket. They are ideal for ad-hoc classification, cross-cutting concerns, and enabling quick filtering.

Working with Tags

• Adding tags — Agents can add one or more tags from the ticket detail view. Type a tag name and press enter. If the tag has been used before, it will appear as a suggestion.
• Removing tags — Click the remove icon next to any tag to remove it from the ticket.
• Automatic tagging via flows — Conversation flows can add tags through the UPDATE_TICKET node. For example, a flow that identifies a billing-related inquiry can automatically add a "billing" tag before routing to the Billing team.

Using Tags Effectively

• Filtering — Use tags as filter criteria in the ticket list to quickly surface tickets matching a particular category, campaign, or issue type.
• Reporting — Tags feed into reporting, allowing you to analyze ticket volume, resolution times, and trends by tag. This is especially useful for tracking issues related to a specific product launch, incident, or promotion.
• Consistency — Establish a shared tagging taxonomy within your team. Standardized tags (for example, "bug", "feature-request", "billing", "onboarding") produce more meaningful data than ad-hoc variations.

AI-Powered Analysis

RapiDesq automatically analyzes ticket content using AI to give agents and supervisors actionable insights for faster triage and better prioritization. AI analysis runs on ticket content and produces three outputs:

Sentiment Analysis

Each ticket is assigned a sentiment classification:

• POSITIVE — The customer's tone is generally positive, satisfied, or appreciative.
• NEUTRAL — The customer's tone is factual, informational, or neither positive nor negative.
• NEGATIVE — The customer's tone indicates frustration, dissatisfaction, or urgency.

Sentiment is displayed on the ticket detail view and in queue listings, giving agents an immediate sense of the customer's emotional state before they open the ticket.

Key Point Extraction

The AI extracts an array of key topics and issues discussed in the ticket. These key points provide a quick summary of what the ticket is about without requiring the agent to read the full conversation. For example, a ticket about a failed payment might produce key points such as "payment declined", "credit card expired", and "subscription renewal".

Urgency Scoring

Each ticket receives an urgency score on a 0–100 scale, where higher scores indicate greater urgency based on the content analysis. This score considers factors such as the language used, the severity of the issue described, and any time-sensitive references. The urgency score is stored in aiUrgencyScore and displayed alongside the ticket's manual priority.

When Analysis Runs

AI analysis is performed after ticket creation and as conversations progress. The aiAnalyzedAt timestamp records when the most recent analysis was completed, so agents can see how current the insights are.

Using AI Insights for Triage

• Sort or filter tickets by sentiment to identify frustrated customers who may need immediate attention.
• Use the urgency score to find tickets that may warrant a priority upgrade — a ticket with NORMAL priority but an urgency score of 85 is likely worth escalating.
• Review key points to quickly understand what a batch of new tickets are about and route them to the right specialists.

Internal Notes

Every ticket has a dedicated internal notes thread, stored as a separate conversation (notesConversationId) that is completely independent of the customer-facing conversation. Internal notes are visible only to agents — they are never exposed to the customer under any circumstances.

Adding Internal Notes

From the ticket detail view, switch to the Internal Notes tab and type your note. Notes are attributed to the agent who wrote them and timestamped for a full audit trail. Multiple agents can contribute notes to the same ticket.

Use Cases

• Documenting troubleshooting steps — Record what you have tried so far, what worked, and what did not. This saves time if you need to pick up the ticket later or if another agent takes over.
• Sharing context before a transfer — Before transferring a ticket to another team or agent, add a note summarizing the current state, what the customer is expecting, and any relevant background. The receiving agent can get up to speed without asking the customer to repeat themselves.
• Recording decisions and approvals — If a resolution requires a supervisor's approval or involves a policy exception, document the decision in a note so there is a clear record.
• Logging off-channel interactions — If you spoke to the customer on the phone or in person about this ticket, note the outcome so the ticket history remains complete.

Assignment & Routing

Getting tickets to the right agent quickly is one of the most important factors in achieving fast resolution times. RapiDesq supports multiple assignment paths that can be combined based on your team's workflow.

Automatic Routing

When a ticket is created and assigned to a team, the team's configured routing strategy determines how it is distributed to agents. Strategies include round-robin, PRIORITY_FIFO (highest priority first, then first-in-first-out within the same priority), and load-balanced distribution. See Team Management for details on configuring routing strategies.

Manual Pickup

Agents can browse the unassigned ticket queue for their team and pick up tickets themselves. This is useful for specialists who want to select tickets matching their expertise, or during low-volume periods when automatic routing is unnecessary.

Supervisor Reassignment

Supervisors can reassign tickets between agents at any time. Common reasons include rebalancing workloads, routing a ticket to an agent with specialized knowledge, or covering for an agent who is unavailable.

Team Transfer

Tickets can be transferred from one team to another while preserving the full conversation history, internal notes, and all metadata. The receiving team has complete context and can continue the resolution without asking the customer to explain their issue again. When a ticket is transferred, it follows the receiving team's routing strategy to reach an agent.

Flow-Based Routing

Conversation flows can route tickets to specific teams based on customer input. For example, a flow that asks "Is this about billing or technical support?" can assign the ticket to the appropriate team based on the customer's response. The flowId, flowVersion, and flowState are preserved on the ticket so that the routing path is fully auditable.

Performance Metrics

RapiDesq tracks key performance metrics on every ticket automatically. These metrics require no manual input — they are calculated from lifecycle timestamps and stored directly on the ticket record.

Built-In Metrics

Lifecycle Timestamps

Every major lifecycle event is timestamped for a complete audit trail:

• createdAt — When the ticket was created.
• assignedAt — When the ticket was assigned to an agent.
• firstResponseAt — When the agent first replied to the customer.
• resolvedAt — When the ticket was marked as resolved.
• closedAt — When the ticket was closed.

How Metrics Feed Reporting

Ticket-level metrics are aggregated into platform-wide reports that provide visibility into team and individual performance:

• AGENT_PERFORMANCE — Individual agent metrics including average first response time, average resolution time, ticket volume, and customer satisfaction trends.
• TEAM_SUMMARY — Team-level aggregates for comparing workload distribution, throughput, and response quality across teams.
• SLA_COMPLIANCE — Tracks whether tickets are meeting defined service level agreements for first response and resolution, and identifies tickets that are approaching or have breached SLA thresholds.

Creating Tickets Manually

While most tickets are created automatically from incoming conversations, there are situations where manual creation is necessary:

• A customer reports an issue in person or over the phone and you need to track the resolution.
• An internal team member identifies a problem that requires customer-facing follow-up.
• A request arrives through a channel that is not yet connected to RapiDesq.

Step-by-Step

1. Click New Ticket from the tickets view.
2. Enter a clear, descriptive subject that summarizes the request.
3. Write the full description. You can use plain text or rich HTML formatting.
4. Associate a contact — search for an existing customer contact, or create a new one if the customer is not yet in the system.
5. Set the priority based on the urgency of the request (defaults to NORMAL).
6. Assign the ticket to a team. Optionally assign it directly to a specific agent.
7. Fill in any relevant custom fields — for example, product category, account number, or issue type.
8. Add any tags that will help with categorization and filtering.
9. Click Create to save the ticket. It will receive a display ID based on the assigned team's prefix and enter the queue.

Tips & Best Practices

• Use ticket prefixes to identify teams at a glance — Choose short, memorable prefixes (SUP, BIL, ESC) so that anyone who sees a ticket ID immediately knows which team owns it. This speeds up cross-team communication and supervisor oversight.
• Leverage AI analysis for triage — Make it a habit to check the AI sentiment and urgency score when reviewing new tickets. A NEGATIVE sentiment with a high urgency score is a signal that the ticket may need to be escalated, even if the customer did not explicitly ask for it.
• Use internal notes before every transfer — When transferring a ticket to another team or agent, always add an internal note summarizing what has been done, what the customer is expecting, and any relevant context. This eliminates redundant customer interactions and reduces resolution time.
• Define custom fields early — Set up your custom fields before your team starts processing tickets at scale. Retroactively categorizing hundreds of tickets is much harder than capturing the data as tickets come in.
• Monitor first response and resolution times — These are the two most important indicators of service quality. Review them regularly at both the agent and team level using the AGENT_PERFORMANCE and TEAM_SUMMARY reports. Set targets and track trends over time.
• Standardize your tagging taxonomy — Agree on a set of standard tags as a team and document them. Inconsistent tagging (for example, "billing" vs "Billing" vs "billing-issue") undermines filtering and reporting.
• Close resolved tickets regularly — Review resolved tickets on a regular cadence and close those that require no further action. A clean queue makes it easier to focus on active work and produces more accurate reporting.
• Use PRIORITY_FIFO for high-volume teams — If your team handles a large volume of tickets with varying urgency, the PRIORITY_FIFO routing strategy ensures that critical issues are always addressed first while maintaining fair ordering within each priority level.
• Let flows do the data entry — Configure conversation flows to capture custom field values and tags during the customer interaction. This reduces manual work for agents and ensures consistent data quality.
• Record closure reasons — When closing tickets, always provide a closure reason. This data is invaluable for understanding resolution patterns, identifying common issues, and improving your support processes over time.