WhatsApp Ticketing System: Turn Chats Into Tickets With SLAs That Fit the 24-Hour Window

WhatsApp Ticketing System: Turn Chats Into Tickets With SLAs That Fit the 24-Hour Window

WhatsApp Ticketing System: Turn Chats Into Tickets With SLAs That Fit the 24-Hour Window

A WhatsApp ticketing system turns every customer conversation into a tracked request with one owner, a status, a priority and a response-time target, so support work on WhatsApp becomes measurable instead of scattered across chat threads.

The complication is that WhatsApp is not a neutral channel. Meta runs a 24-hour clock on every service conversation, and that clock decides whether your next reply is a free-form message or a pre-approved template. Set your response targets without accounting for it and your policy and the platform will disagree.

This guide covers the decision between a shared inbox and a WhatsApp ticketing system, what the 24-hour rule actually says, and how to write first-response and resolution targets that fit inside it — including the Friday-evening-before-a-public-holiday case.

What is a WhatsApp ticketing system?

A WhatsApp ticketing system captures inbound WhatsApp conversations as tickets: tracked units of work, each with an owner, a status, a priority and a deadline. The customer keeps chatting in WhatsApp. Your team works a queue where every request carries a name and a clock.

The lifecycle runs in one pass:

  1. A customer messages your business number.
  2. The message opens a new ticket or attaches to an open one.
  3. The ticket gets categorised, prioritised and routed to an owner.
  4. The owner works it, logs time against it, and resolves it.
  5. If the customer returns on the same issue, the ticket reopens instead of starting a thread nobody recognises.

What changes is not the conversation. It is that you can answer three questions at any moment: who owns this, is it late, and what is still open.

Is a shared WhatsApp inbox the same as a ticketing system?

No. A shared inbox solves access. A ticketing system solves accountability.

A shared WhatsApp inbox for teams lets several agents work one WhatsApp number without passing a phone around. Everyone sees the thread, replies go out under one business identity, and conversations stop dying in one person’s chat list. A ticketing system sits on top of that and adds structure: an owner per request, a state, a target time, and a record you can report on afterwards.

QuestionShared inboxTicketing system
Who owns this request?Whoever picks it upOne named owner, assigned and reassignable
What state is it in?Read or unreadConfigurable statuses from new through to resolved
Is there a deadline?NoFirst-response and resolution targets per priority
What can you report on?Volume and activityResponse times, breaches, reopens, per-agent performance
What happens when the customer returns?A new message in the threadThe original ticket reopens with its history
What is the audit trail?The chat historyA logged record of every status change, owner and edit

The decision rule is short. If your problem is two agents replying to the same customer, or a conversation nobody else can see, a shared inbox closes it. If your problem is that you cannot say whether a request was answered in time, who owned it, or what is still open, you need a WhatsApp ticketing system on top.

Build the inbox first, then add ticketing to it.

What is the WhatsApp 24-hour customer service window?

When a customer messages or calls your business on WhatsApp, a 24-hour clock starts. Inside it, you reply with free-form messages. When it closes, your options change.

According to Meta’s WhatsApp Business Platform documentation, a 24-hour customer service window opens when a WhatsApp user messages or calls your business, and the timer resets to 24 hours if they message or call again before it expires. Every new inbound message buys you another full day.

This is the part that circulating summaries get wrong. It is not true that you cannot reply after 24 hours. Meta’s documentation states that when the window closes, you can only send pre-approved template messages.

What expires is the free-form reply, not your ability to reach the customer — but the template has to be written and approved in advance, so the conversation continues on the platform’s terms rather than yours.

One scope note worth having: this rule governs the WhatsApp Business Platform, the API-based route that inbox and ticketing tools connect through. If you have not set that up yet, start with WhatsApp Business API setup in Africa.

Why the 24-hour window changes how you set support SLAs

A service-level agreement (SLA) is the response-time promise you make to a customer and then measure yourself against. On WhatsApp, a first-response target is not only a service promise. It decides which kind of message your reply is.

Meta replaced conversation-based pricing with per-message pricing on 1 July 2025, according to its own deprecation notice. Under that model, Meta’s pricing documentation states that you are only charged when a template message is delivered, and that Meta does not charge for non-template messages, which can only be sent inside an open customer service window.

So a reply that lands inside the window and a reply that lands after it are not the same transaction. The first is a free-form message on a conversation that is already open, and it carries no charge. The second has to be a template, and template messages are charged: a message you pay for, and would not have needed to send, because the clock ran out.

Every first response that lands late turns a reply you could have sent for nothing into one you pay for. Current rates sit on Arkesel’s pricing page.

There is a second cost that has nothing to do with billing. A template is copy you wrote and submitted for approval in advance, so restarting a lapsed conversation takes a step that a timely reply never needed.

That gives you a concrete design constraint. Your first-response target has to sit comfortably inside 24 hours of real elapsed time, not 24 hours of working time. Those are different numbers the moment a weekend or a public holiday is involved.

How to set WhatsApp customer support SLAs that fit the 24-hour window

Start from the window and work backwards. Every first-response target belongs well inside 24 hours of the customer’s last message, with enough margin that a queue spike does not push it over.

PriorityTypical requestFirst responseResolution targetAt breach
UrgentPayment taken but no order created; account compromised; service down15 minutes4 hoursWarn the owner at 10 minutes; alert the supervisor and reassign at breach
HighDelivery overdue; account locked; wrong item shipped1 hourSame working dayEscalate to the team lead at 45 minutes
NormalProduct questions, order changes, account details4 hours1 working dayWarn the owner at 3 hours
LowGeneral enquiries, feedback, feature requestsAcknowledged inside the window, substantive reply by the next working day3 working daysWeekly queue review
WhatsApp support SLA targets by priority: Urgent, 15 minutes to first response and 4 hours to resolution, warn the owner at 10 minutes and reassign at breach; High, 1 hour and same working day, escalate to the team lead at 45 minutes; Normal, 4 hours and 1 working day, warn the owner at 3 hours; Low, acknowledged inside 24 hours with a substantive reply by the next working day and 3 working days to resolve, reviewed weekly. Every first-response target sits well inside the 24-hour customer service window, which runs on real elapsed time.

Two rules make a table like this work on WhatsApp specifically.

Any resolution target longer than a day needs a defined re-contact step. If a Normal ticket will not close the same day, your policy has to say what happens once the window shuts: either you wait for the customer’s next message to reopen it, or you re-engage with an approved template. Decide that in writing, so an agent is not discovering it at 9am in front of a lapsed thread.

The same logic sets the floor on the Low tier: acknowledge inside the window even when the substantive answer waits for the next working day, because a first-response target measured in working days will cross the window every weekend.

The window does not observe your working hours. It runs on real elapsed time, counting overnight, on Sundays and through every public holiday.

Working hours, weekends and public holidays

Take a message that arrives at 6:00pm on the Friday before a Monday public holiday — a long weekend any team working to Ghana’s public-holiday calendar plans around, and a shape that repeats on every calendar your customers keep.

The window expires at 6:00pm on Saturday. By the time your team is back at their desks on Tuesday, the free-form reply is long gone — for a customer who messaged on an ordinary working day.

Timeline of the WhatsApp 24-hour customer service window over a long weekend: a customer messages Friday at 6:00pm and the clock starts, the window expires Saturday at 6:00pm while the office is closed, and the team returns Tuesday at 9:00am to find only a pre-approved template can reopen the conversation.

The fix is a policy decision rather than a heroic one. Pick one and write it down: staff a holiday rota that covers first response only, or set an after-hours acknowledgement that tells the customer what to expect and when, then plan the template re-engagement for the morning you return. A well-built WhatsApp auto-reply setup covers the acknowledgement; the rota covers the resolution.

Then configure your published support hours and holiday closures in the tool that measures the SLA. A clock that counts Sunday night against your agents produces breach reports nobody trusts, and a team that ignores its breach reports has no SLA at all.

KOVA IQ turns every WhatsApp, social and live-chat conversation into a ticket with an owner, a status and an SLA, with working hours and public holidays built into how those targets are measured. See how KOVA IQ runs support operations.

How do you convert WhatsApp messages to tickets?

Six steps, start to finish.

Capture. Every inbound message lands in one queue rather than on a device. The first message on a new issue creates the ticket; follow-ups attach to it.

Categorise and prioritise. Tag the request type and set a priority. Priority sets the clock, which is why your priority definitions belong in writing and shared with the team rather than decided per agent.

Route to an owner. Routing rules send the ticket to the right team or agent. If a bot took the first pass, this is the point of handing a chatbot conversation to a human agent with the transcript attached, so the customer does not repeat themselves.

Work and time-track. The owner replies, logs time against the ticket, and leaves internal notes on it rather than in a side chat. If two threads turn out to be the same issue, merge them. If one thread carries two issues, split it.

Resolve. Move the ticket to resolved with a resolution note. That note is what makes the next reopen fast.

Reopen. When a customer comes back about a resolved issue, the ticket reopens with its history. If their reply lands after the window has closed, that message itself opens a fresh 24-hour window, because the customer’s inbound message is what starts the clock. Your agent has a full day of free-form replies again, and the reopen is the moment to use it.

What to measure once WhatsApp support runs on tickets

Five numbers cover it, and a WhatsApp ticketing system records every one of them as a by-product of the work.

The five numbers a WhatsApp ticketing system records as a by-product of the work: first-response time, resolution time, reopen rate, per-agent SLA result, and window-expiry rate — the WhatsApp-specific measure, highlighted, because a closed window turns a service problem into an outbound-message problem.

First-response time. Measured from the customer’s message to your first human reply, against the target for that priority. This is the number that connects service quality to the window.

Resolution time. Measured to the resolved status and reported by priority and by category. Sort it by category: the categories that run long are where to look first for a fix outside the support team.

Reopen rate. The share of resolved tickets a customer comes back on. A climbing reopen rate means tickets are being marked resolved before the customer agrees they are.

Per-agent SLA performance. Response and resolution results by owner. Use it to rebalance workload and find the queues that are structurally understaffed, not to rank people.

Window-expiry rate. The share of conversations where the 24-hour window closed before your first reply. This is the WhatsApp-specific number, and it is the one that turns a service problem into an outbound-message problem.

Where WhatsApp support breaks without tickets

If your team answers customers from personal phones, or from one device everybody reaches for, here is what you lose.

  • Ownership. Two agents answer the same customer, or nobody does, and there is no record of which was supposed to happen.
  • History. When an agent leaves, the conversations on their phone leave with them.
  • Deadlines. Without a clock on each request, “we got back to them” and “we got back to them in time” look identical in a status meeting.
  • Duplicates. One customer with one problem opens three threads across three numbers, and every agent starts from zero.
  • The reopen path. A customer returns a week later. Nobody knows what was decided, so the conversation restarts — often after the window has closed, which means it restarts on a template.

None of this is WhatsApp’s doing. It is what happens when a channel carrying real support volume runs without the structure a WhatsApp ticketing system supplies. For the wider picture of running sales and support on WhatsApp in Ghana, our full guide covers the sell, serve and follow-up side together.

Running SLA-backed WhatsApp support with KOVA IQ

KOVA IQ is Arkesel’s messaging-first CRM and customer engagement platform. WhatsApp, Facebook Messenger, Instagram DM, Telegram and website live chat land in one agent queue, and every conversation sits against a single Customer 360 timeline rather than in a channel-specific silo.

On the ticketing side, KOVA IQ ships conversation-to-ticket conversion, configurable ticket statuses and priorities, routing rules, ticket merge and split with undo, ticket time tracking, ticket audit logging, and an OTP-gated customer ticket portal that lets customers check and reply to their own ticket without an account or password.

On the SLA side, it tracks conversation SLAs and delivers SLA warnings and breach alerts, working hours and public-holiday schedules, and per-agent SLA reporting. That last set is what makes the policy in this article enforceable rather than aspirational: targets measured against your real calendar, a warning before a breach rather than a report after it, and per-owner results you can act on.

Because the same platform runs your WhatsApp Business API messaging, your campaigns and your customer record, a ticket does not sit in one tool while the customer’s order history sits in another. That matters most for teams graduating off personal-phone support, where the whole point of the move is getting one view of the customer.

Frequently asked questions

Can I use WhatsApp as a helpdesk or support ticket system?

Yes, through the WhatsApp Business Platform. A WhatsApp ticketing system connects to your business number, and the work splits cleanly: the messaging happens in WhatsApp, while the ticketing, routing, SLA clocks and reporting happen in the connected platform. A WhatsApp helpdesk is that arrangement, not a feature inside the chat app.

How do I turn WhatsApp messages into support tickets automatically?

Connect your WhatsApp business number to a WhatsApp support ticket system with conversation-to-ticket conversion, then set rules for which inbound messages open a ticket and how they are categorised and routed. After that, the first message on a new issue creates the ticket and follow-ups attach to it.

What happens if you reply to a WhatsApp customer after 24 hours?

You can still reach them, just not with a free-form message. Meta’s documentation is explicit that when the window closes, you can only send pre-approved template messages. Its pricing documentation is equally explicit that template messages are charged while non-template messages are not, so the late reply costs you something the in-window reply would not have. The customer’s next inbound message opens a new window and returns you to free-form replies.

What SLA should you set for WhatsApp support?

Set first-response targets that sit comfortably inside 24 hours of real elapsed time for every priority tier, then resolution targets by priority on top. Anything longer than a day needs a defined re-contact step, because the free-form window will have closed by then.

How do you track first-response and resolution time on WhatsApp?

Measure from the customer’s message to your first human reply, and from ticket creation to resolved status. Both come from the ticket layer, which is where the target, the owner and the breach state live.

What happens when a customer replies to a resolved WhatsApp ticket?

The ticket reopens with its history intact, and the customer’s message opens a fresh 24-hour customer service window. That gives your agent a full day of free-form replies to close it out properly.

Is a shared WhatsApp inbox enough on its own?

It is enough if your problem is access. Once you need to prove who owned a request and whether it was answered in time, add the ticket layer.

Start measuring what your team already does

Support on WhatsApp stops being guesswork the moment a WhatsApp ticketing system gives every conversation an owner, a status and a clock that respects the platform’s 24-hour window. Write the policy first, then configure the tool to measure it.

Turn your WhatsApp conversations into SLA-backed tickets with KOVA IQ, create an account to get started, or talk to the team about your support workflow.

Scroll to Top