WhatsApp Shared Team Inbox
A WhatsApp shared team inbox is a single business number that several agents log into at the same time, each seeing their own assigned queue instead of the whole flood. It runs on the official WhatsApp Business API, so conversations get assigned, labelled, noted and measured rather than left on one person's phone. The free WhatsApp Business App was never built for this: it is designed around one primary device with a limited number of linked devices. This guide covers how to structure queues, set first-response targets, handle escalation and shift handover, and stay on the right side of the 24-hour customer service window.
- The free WhatsApp Business App assumes one owner on one primary device, so a growing team hits double replies, missed chats and no ownership trail.
- A shared inbox on the official API gives every agent a separate login and a separate queue on the same business number.
- Design queues around work, not people: enquiries, order status, billing, technical issues and escalations each behave differently.
- Replies are free-form for 24 hours after a customer messages you. Outside that window you need an approved template, which changes how you handle backlogs.
- Measure first response time, resolution time and reopened chats. Without those numbers, an SLA is just a promise nobody checks.
Why one phone stops working at around three people
Most Indian businesses start the same way. One number, one phone, one person who "handles WhatsApp". It works until volume grows, and then the failure modes arrive in a predictable order.
First comes double replying. Two people open the same chat on linked devices and both answer, often with different information. Then comes the silent drop: a message gets read on someone's screen at 11pm, the blue ticks tell the customer it was seen, and nobody picks it up in the morning because there is no unread marker left. Then ownership disappears. When a customer calls to ask what was promised, nobody can say who replied or what was committed, because the thread has no author.
The structural problems are worse than the daily ones. The number usually sits on a staff member's personal handset, which means the business does not really control it. When that person resigns, takes leave or loses the phone, the customer history goes with them. You cannot restrict who sees which conversation, you cannot report on how fast anyone replies, and you cannot hand a queue over cleanly at shift change.
None of this is a flaw in the app. The WhatsApp Business App was built for a solo owner or a very small shop, with a primary device and a limited set of linked devices. Once you need several people replying in parallel with accountability, you have outgrown the tool, not the platform.
What actually changes on a shared team inbox
Moving to the official WhatsApp Business API does not change your number or force customers to do anything differently. They still message the same business number. What changes is everything behind it: instead of one device holding the conversation, a server holds it and hands each chat to a named agent who has their own login.
| Dimension | Personal phone / Business App | Shared team inbox on the API |
|---|---|---|
| Ownership of the number | Tied to a handset and a SIM someone carries home | Owned by the business account; agents get revocable logins |
| Routing | Whoever opens the chat first, or nobody | Assignment and routing rules push each chat to one owner or one queue |
| Records | History lives on the device; lost when staff or phones change | Full thread stored centrally with the agent name against each reply |
| Reporting | None beyond counting chats manually | Response time, resolution and volume per agent and per queue |
| Continuity | Shift handover happens by shouting across the room | Open chats reassign to the next shift with internal notes attached |
| After hours | Messages sit unread, or staff reply from bed | Working hours plus an automated first response that captures details |
The practical difference is that support stops depending on who happens to be looking at a screen. Every chat has an owner, a status and a clock, and all three are visible to a supervisor.
How to set up a shared WhatsApp support desk in 6 steps
- Pick and free up the number. Decide which number becomes the business line. It must not be active on the WhatsApp Business App or consumer WhatsApp when you migrate it, so plan the switch for a quiet window. If the number currently sits on an employee's personal SIM, move it to a company connection before anything else.
- Complete business verification and get the API connected. This is where the Meta Business account, display name and business details are checked. Get your legal entity name, GST or registration details and a working business website or landing page ready in advance, because incomplete details are the usual cause of delay.
- Create agent logins and roles. One login per person, never a shared password. Decide who can only reply, who can reassign, and who can see reports. This is the step most teams skip, and it is the one that makes offboarding safe later.
- Build your queues and routing rules. Map the two or three questions a customer answers at the start of a chat to a queue, then route that queue to the right group of agents. Keep the menu short; three options answered correctly beats seven options that customers ignore.
- Write the automation layer. A greeting, a short qualifying flow, an out-of-hours message, and a set of canned replies for the questions your team answers every day. If you also use WhatsApp to capture demand, our chatbot for lead generation guide covers how to design that flow without over-automating.
- Set targets, then watch the reports for two weeks. Publish first-response targets, label statuses consistently, and review the numbers weekly. Almost every team gets the queue split wrong on the first attempt and needs one round of correction.
Done in this order, a small team can be live quickly. The long pole is almost always step two, because verification depends on your paperwork rather than on the software.
Designing queues that match how your team actually works
The most common mistake is creating one queue per person. That looks tidy on day one and breaks the moment someone takes leave. Build queues around types of work instead, and staff them with people. If an agent is absent, the queue keeps running.
Start by listing the last hundred conversations your team handled and sorting them into buckets. Most Indian businesses end up with something close to the table below. Treat the response targets as a starting commitment you can defend to customers, not as an industry law; the point is that a target exists and is measured.
| Queue | What lands here | Who staffs it | First-response target |
|---|---|---|---|
| New enquiries | Pricing, availability, demo requests, ad clicks | Sales, with a bot doing qualification first | Under 5 minutes in working hours |
| Order and delivery status | "Where is my order", tracking, address changes | Junior support, mostly canned replies | Under 15 minutes |
| Payments and billing | Invoices, refunds, failed payments, GST queries | Accounts, with one support agent as backup | Under 30 minutes |
| Technical or product issues | Something is broken, setup help, how-to questions | Senior support or product specialists | Under 30 minutes, resolution same day |
| Complaints and escalations | Angry customers, repeat issues, public threats | Team lead only, never auto-assigned | Under 10 minutes, owner named in the reply |
| After hours | Anything arriving outside working hours | Bot captures details, morning shift picks up | Acknowledged instantly, human reply by 10am |
Two rules keep this working. First, only one queue may be the default, and it should be the broadest one, so nothing falls through when a customer types something unexpected. Second, escalations are pulled by a lead, never pushed round-robin, because an angry customer bounced between three agents becomes a much bigger problem.
First response, escalation and making an SLA real
An SLA that lives in a slide deck does nothing. To make it operate, you need three things in the inbox itself.
A visible clock on every open chat
Agents should be able to see, at a glance, which chats are closest to breaching. If your inbox sorts by newest message, the oldest unanswered chat quietly rots at the bottom. Sort the working view by waiting time instead.
A written escalation path
Define what triggers an escalation: a second complaint on the same order, any refund above a threshold, any mention of legal action or social media, or a chat still unresolved after a defined number of hours. Attach an internal note explaining what has already been tried, then reassign. Escalation without context just restarts the conversation.
Labels that mean one thing
Keep the label set short and mutually exclusive: new, in progress, waiting on customer, waiting on internal team, resolved. "Waiting on customer" is the label that saves your averages, because it separates chats you are sitting on from chats the customer is sitting on. If you also track deals, a pipeline view on top of labels lets sales and support share one thread without fighting over status.
The 24-hour customer service window, in plain terms
This is the single rule that shapes WhatsApp support operations, and it catches most teams out in their first month.
When a customer sends you a message, a 24-hour customer service window opens. Inside that window your agents can reply freely: normal text, images, PDFs, voice notes, whatever the conversation needs. Once 24 hours pass without a new message from the customer, that freedom closes. To reopen the conversation you must send a message template that Meta has approved in advance, and the customer's reply reopens the free-form window again.
The operational consequences are concrete:
- Do not let chats age past the window. A ticket you meant to answer "tomorrow" may need a template by the time you get to it. Build a rule that anything approaching the window boundary gets a holding reply or a formal escalation.
- Keep a small set of approved templates ready. A follow-up template, an order update template and a "we tried to reach you" template will cover most reopen situations. Get them approved before you need them, not during a crisis.
- Train agents on the difference. Agents should know why the reply box behaves differently on an old chat, otherwise they assume the tool is broken.
- Budget for it. Template messages are billed by Meta according to their category, and those rates change over time. We break down what that means for an Indian business in our WhatsApp Business API pricing guide.
Teams that internalise this rule design for speed, because a fast first response is not just good service on WhatsApp, it is also cheaper than reopening a closed window later.
Shift handover without losing the thread
Handover is where multi-agent support usually leaks. The fix is a fifteen-minute ritual at the end of each shift, and it is mostly discipline rather than software.
Before logging off, an agent should close everything that is genuinely resolved, add an internal note to everything that is not, and reassign open chats to the incoming shift or back to the queue. The note matters more than the reassignment: one line covering what the customer wants, what has been tried, and what the next step is. An incoming agent who has to read forty messages to understand a chat will simply ask the customer to repeat themselves, which is the fastest way to annoy someone who has already explained the problem twice.
For businesses running extended or weekend coverage, put the handover rule in writing and review breaches weekly. It is far easier to fix a handover habit than to fix the reputation damage from a dropped complaint.
What to measure once the desk is running
Four numbers tell you almost everything about a WhatsApp support desk.
- First response time. Track the median and the worst case separately. Averages hide the customer who waited four hours.
- Resolution time by queue. Billing and technical queues will always be slower than order status. Comparing them against each other is meaningless; comparing each against last month is not.
- Reopened conversations. A chat marked resolved that the customer restarts within a day usually means the first answer was wrong or incomplete. This is your quality signal.
- Volume per agent per queue. Useful for staffing decisions, dangerous as a performance metric on its own, since the agent handling escalations will always show lower volume.
Review these weekly with the team rather than monthly with management. Weekly cadence catches a broken routing rule before it becomes a month of poor service.
Where ZupiChat fits
ZupiChat is a CRM built in India by Codelith Lab on the official WhatsApp Business API, designed around exactly this problem. The shared team inbox lets many agents work one WhatsApp number with separate chat queues, so nobody is scrolling through conversations meant for someone else. A no-code chatbot handles the first response and routes the chat into the right queue, labels and a pipeline view keep status honest, broadcasts go out through approved templates, and analytics cover response and resolution.
Pricing is in INR with no currency conversion surprises. Growth is Rs. 999 per month for three numbers and three agents, which suits a small shop or a founder-plus-two support setup. Enterprise is Rs. 2,499 per month for unlimited agents, which is where most scaling teams land. There is a free Starter plan, setup is typically completed in under 24 hours once your business details are in order, and support is available in Hindi and English.
If you are still comparing options, our roundup of the best WhatsApp CRM software for Indian businesses lays out what to check before you commit a business number to any platform.
Put your whole support team on one WhatsApp number
Separate agent queues, routing, labels and response reporting, live in under 24 hours.
Start free on the Starter planFrequently Asked Questions
How many agents can work on one WhatsApp number at the same time?
On the official API there is no hard practical cap for a support desk; the limit comes from your plan and your staffing. ZupiChat Growth covers three numbers and three agents at Rs. 999 per month, and Enterprise removes the agent limit at Rs. 2,499 per month. Add seats as queues grow.
Do agents need the WhatsApp app installed on their phones?
No. Agents log into the shared inbox in a browser with their own credentials, so nothing is tied to a personal handset and no one needs to scan a QR code. That also means access is granted and revoked centrally: when someone leaves, you disable the login and the chat history stays with the business.
What happens to messages that arrive after working hours?
Set working hours in the inbox and let a no-code bot pick up out-of-hours chats. It should acknowledge the message, state when your team is back, capture the order or invoice number, and drop the chat into the right queue so the morning shift starts with context instead of a cold backlog.
Can I see which agent replied to a customer?
Yes. Every message sent from a shared inbox carries the agent who sent it, so the thread reads as one continuous conversation to the customer while your team sees exactly who handled what. That record survives staff changes and gives you something concrete to review when a customer disputes what was promised.
What does a shared WhatsApp inbox cost in India?
There are two line items. The software: ZupiChat is free to start, with paid plans from Rs. 999 per month for three numbers and three agents, and Rs. 2,499 per month for unlimited agents, billed in INR. Then Meta bills template messages by category; free-form replies inside the 24-hour service window are not charged as templates.