---
title: "Conversations versus tickets"
description: "What a conversation holds, what a ticket holds, which of the two carries an SLA clock in CloudFly Helpdesk, and how to decide where a request belongs."
updated: "2026-08-28"
audience: [agent, administrator]
source: "https://helpdesk-docs.svr1.feedapp.click/en/khai-niem/hoi-thoai-vs-ticket"
---

The console keeps two kinds of work records. Conversations live under
**Conversations**; tickets live under **Tickets**. Neither replaces the other,
and filing a request in the wrong one is a familiar way to lose track of it.

## A conversation is a live message stream [#a-conversation-is-a-live-message-stream]

This is where a customer and your team talk. Every conversation belongs to one
inbox and carries the channel the customer wrote in from.

* Exactly three states and no others: **Open**, **Snoozed**, **Resolved**.
* One **Assignee**, plus any number of **Teams** pulled in; nobody is removed
  when the next team joins.
* **Internal discussion** sits inline in the chat pane, yet the customer never
  receives it.
* Presence, typing and read receipts run in real time on both sides.

No deadline is attached to a conversation. Its measure is the time since the
last reply, and it ends when the customer has no further questions.

## A ticket is a unit of work with a deadline [#a-ticket-is-a-unit-of-work-with-a-deadline]

A ticket records something that has to be finished, including work that spans
several days and several people.

* A global reference of the form `HD-0001`, handed out by an atomic counter, so
  two tickets never share one.
* Columns on the **Kanban** board, configured per team; dragging a card moves it
  and the move is written to the stage history.
* Four levels of **Priority**: **Low**, **Medium**, **High**, **Urgent**.
* **SLA Policies** attach by tag, customer or team, and the clock follows your
  **Working Calendars** rather than wall time.
* A single timeline where a **Public Reply** and a reply badged **Internal**
  share one list.

## The two records are independent [#the-two-records-are-independent]

There is no button that turns a conversation into a ticket. In the database
schema the `tickets` table holds no foreign key to any conversation; the contact
both records point at is what ties them together.

So when a request needs longer follow-up, open a new ticket, copy across the
detail that matters, and keep answering the customer in the conversation.

## Deciding where a request belongs [#deciding-where-a-request-belongs]

| Situation                                                                 | Where it goes                               |
| ------------------------------------------------------------------------- | ------------------------------------------- |
| A question answered in a single round trip                                | Conversation                                |
| Work spanning several days and several people                             | Ticket                                      |
| A response time promised to the customer and measured                     | Ticket                                      |
| Anything arriving from the widget, a Facebook Page, a Zalo OA or Telegram | Conversation — that is the only entry point |
| Internal work with no customer waiting                                    | Ticket                                      |

Large requests usually need both: the customer talks in the conversation while
your team tracks progress on the ticket.

> **Note:** Conversation list endpoints have no pagination yet. The interface caps how
> many records it fetches and virtualizes the list, so narrow a long queue with
> filters rather than scrolling.

## Read next [#read-next]

* [Shared inboxes and channels](/en/khai-niem/inbox-va-kenh)
* [Roles and per-feature permissions](/en/khai-niem/vai-tro-va-quyen)
* [Glossary of helpdesk terms](/en/khai-niem/thuat-ngu)