What turns a message into a ticket, how to rate severity as impact times reach, what escalation actually transfers, and who gets to decide a ticket is resolved.
Key takeaways
- The representative is not being negligent. A chat channel holds no state, so a request living inside it cannot be monitored, escalated or handed over.
- Severity is impact multiplied by reach, not tone of voice. A calm customer whose system is down outranks an angry one whose button is the wrong colour.
- Escalation transfers ownership and changes update cadence. Adding a manager to a distribution list is not escalation, because nobody became accountable.
- "Resolved" and "closed" are two states. Resolved is asserted by whoever fixed it; closed is the customer's confirmation or the expiry of a confirmation window.
- WhatsApp imposes a hard time constraint: Meta documents a 24-hour customer service window that resets on each inbound message, outside which an approved template is required. A chat is not storage for an open ticket.
A request stays in one representative's chat because the chat itself is the record. It has no identifier, no severity, no due time and no second reader. Turning a message into a ticket is a defined moment: the moment a record exists that somebody else can find without asking for that representative's phone.
Why does an urgent request stay in one representative's WhatsApp?
Because the channel holds none of the fields that make a request manageable. A chat has no searchable identifier, no severity field, no due time and no declared owner. The representative is the only person who knows the request exists, and the moment they are on leave, it does not exist for the organisation. The build walkthrough is in how to create a WhatsApp bot.
There is also a hard technical constraint. Meta's Cloud API documentation states that when a customer messages you a 24-hour timer called a customer service window starts, that the timer resets to 24 hours if the customer messages again before it expires, and that reaching a customer outside that window requires a template message. A ticket waiting three days for a replacement part cannot live inside a 24-hour window. The queueing and delivery mechanics behind that are set out in handling a high-volume WhatsApp message queue.
The conversion boundary: what turns a message into a ticket
A message becomes a ticket when a record exists carrying the fields that let a different person continue it. Anything less is still a conversation.
| Field | Example value | Why there is no ticket without it |
|---|---|---|
ticket_id | TCK-2026-04412 | a number you can quote and search |
customer_id | CUS-8841 | links to history, not just to a phone number |
severity | S2 | sets update cadence and escalation path |
opened_at | 2026-10-14T08:41+03:00 | every target is measured from it |
owner_user_id | u_1174 | one person, not a team |
channel | whatsapp | where the customer expects the answer |
source_ref | the original message id | lets anyone return to the exact thread |
state | in_progress | one value from a closed list |
source_ref is the field that prevents the next complaint. Without it, a representative picking the ticket up the following day asks the customer to explain what happened again, and that is the experience that turns a small fault into a complaint about service. The row above it, channel, decides where the reply goes: a customer who wrote on WhatsApp and receives an email experiences it as no response at all. A comparable conversion of inbound messages into structured records is covered in turning WhatsApp orders into a work queue.
Severity is impact times reach, not tone of voice
| Level | Impact | Reach | Customer update cadence |
|---|---|---|---|
S1 | a business process is down with no workaround | all customers or one critical account | hourly |
S2 | a process is degraded with a known workaround | a user group or a single site | twice daily |
S3 | a local fault, work continues | a single user | once per working day |
S4 | an observation, an improvement request, a question | not blocking | at the next release |
That table is an example of a matrix each organisation sets for itself, not a standard. What matters is that it is written down, that it rests on two axes rather than on a feeling, and that it is set at intake by whoever receives the request. Three practical clarifications:
- Severity can move up and down, and every change is recorded with a reason. Whoever lowers a severity owns the explanation.
- A customer demanding
S1does not setS1. They supply information about impact; reach is determined on your side. - Three
S3tickets from the same customer in one week justify treating the pattern as oneS2, because the pattern is the problem rather than each individual event.
What escalation actually transfers
Escalation is a transfer of ownership to someone with wider authority, not the addition of recipients. Google's SRE book chapter on managing incidents describes a structure with a designated incident commander and separated roles for operations and communications, and that is exactly what breaks when escalation means adding a manager to a thread. Three things change at each rung:
- The owner becomes one new person, and the previous owner stops being accountable. Two equal owners is the same as none.
- Authority changes: a rung that can approve replacing hardware, summon a supplier, or halt a release.
- Customer update cadence shortens according to severity, and that is the part the customer feels.
Every rung carries a timeout. If there is no answer inside the agreed period, the ticket moves on by itself rather than waiting. The mechanism resembles the one described in lead follow-up SLA and ownership, but the direction is inverted: there the fear is that an opportunity cools, and here it is that damage already underway continues. For current build and running costs, see how much a chatbot costs.
A worked timeline for one ticket, TCK-2026-04412 at severity S2:
- 08:41 - an inbound WhatsApp message opens a ticket automatically with a
source_ref. - 08:53 - a first-line representative acknowledges and sets severity to S2.
- 09:41 - the first-line timeout elapses with no workaround. Ownership moves to a specialist.
- 10:20 - a workaround is found, the customer is updated, and severity drops to S3 with a recorded reason.
- 11:05 - the fix is verified with the customer. The state moves to
resolved. - 13:05 - the customer confirms and the state moves to
closed.
Who decides a ticket is resolved?
Whoever fixed it asserts resolved; the customer or the passage of time asserts closed. Two states rather than one, because they answer different questions: was the fault repaired, and does the customer agree.
resolvedis set by the handler, with a description of what was actually done rather than the word "handled".closedis set by customer confirmation, or automatically after a pre-defined confirmation window.- A reopen inside a defined window returns the original ticket with its severity rather than opening a new one. Otherwise the report shows two small faults instead of one that was never fixed.
- A ticket closed automatically is marked as such, because silence is not satisfaction.
- Closing without a fix requires an explicit value such as
not_reproducibleorby_design. Closing with no reason is how the same complaint returns a month later.
Sources
Frequently asked questions
Do you need a dedicated ticketing system from day one?
No, but you need a record with an identifier, a severity, an owner and a due time from day one. One table with eight columns beats a chat, and also beats a large system nobody fills in. Moving to a dedicated tool is justified when automatic escalation and reporting start costing more time than the handling itself.
How do you set severity when the customer and the representative disagree?
The representative sets it from the matrix, and the customer supplies the impact information. The disagreement is recorded on the ticket and travels with any escalation, so the next rung sees both the rating and the objection. A written matrix turns an argument about feelings into an argument about two fields.
What about a complaint that arrived through an employee's personal channel?
Move it into a record immediately and reply to the customer on the official channel quoting the ticket number. There is no point fighting the channel the customer chose, but the message must become a record. Somebody moving to a different role cannot take open complaints with them.
How long should a ticket stay open with no customer response?
Define one window across all severities, five business days for example, send a single reminder before closing, and close with a value marking that the closure was for want of a response. What matters is that a reopen returns the same ticket, so the measurement shows the real handling duration rather than two short tickets.
Keep reading
Related service
WhatsApp Cloud API
Templates, a two-way inbox and reminders on the official Meta API.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.