Conversation handover checklist between areas: what must be written down, who confirms, and in how long
When a WhatsApp conversation moves from one area to another, the problem is almost never the conversation itself: it's what didn't get written down. The salesperson who was helping a customer forwards them to support and forgets to paste the order number. Support receives it, asks again, the customer gets angry because they already said it once. Or worse: administration receives the case, doesn't know if the salesperson already promised something, and ends up contradicting their colleague in front of the customer.
This checklist is for that. It's not a guide to tone or style: it's a verification list that the team prints out or copies into an internal note and checks off before moving each conversation. It's designed for businesses that handle WhatsApp with several people and at least two distinct areas (sales and support, or sales and administration, or support and logistics). If your team is a single person, it doesn't apply: there's no one to hand off to.
The logic is simple: if a handoff doesn't have required fields, an owner and a time window, it's not a handoff, it's passing the ball. And on WhatsApp, where the customer sees who writes to them and when, every badly done handoff shows.
Before you start: define the areas and the internal channel
You can't audit a handoff if it's not clear which areas the conversation moves between. Before using the checklist, the team needs to have this sorted out:
- List the real areas that handle WhatsApp in your business. Not the ideal ones: the ones that exist. If sales and administration are the same person, they're not two areas.
- Define which internal channel the handoff happens in. It can be the same WhatsApp inbox with a change of label and assigned agent, or a separate channel (an internal group, a task tool). What matters is that there's a record of who passed it and who received it.
- Agree on one label per area. In Wando, for example, contacts can be organized with labels; if you use another tool, define the equivalent. Without a label, the handoff can't be measured later.
- Name one owner per area. Not a team: one person. Handoffs to 'support' generally get lost; handoffs to 'Mariana in support' get confirmed.
This checklist assumes the handoff happens within the same WhatsApp conversation (the customer keeps seeing the same chat) or by moving to another conversation with the same number. If your business uses different numbers per area, the customer sees a change of number and that's a different experience: let them know before transferring.
Stage 1: what must be written down before moving the conversation
This is the part that gets skipped the most. The person handing off thinks the other person will read the entire history. They won't: they'll read the last message and ask for whatever is missing. So the person handing off has to write down, in a single block of text, everything the receiver needs so they don't have to ask the customer again.
| Field | What to write | How to know it's OK |
|---|---|---|
| Reason for the handoff | A concrete phrase: 'wants an invoice A', 'complaining about a delayed shipment', 'asking to change plan'. Not 'general inquiry'. | If the receiver has to open the history to understand why it reached them, the field is wrong. |
| Customer data already collected | Name, order or customer number, and any data the customer already gave that shouldn't be asked for again. | The receiver doesn't need to ask the customer anything to get started. |
| What was promised | What the area handing off already told the customer: deadlines, prices, solutions, 'we'll resolve it for you today'. Even if it wasn't fulfilled. | If there's a promise and it isn't written down, the receiver will contradict it without meaning to. |
| Emotional state | Whether the customer is angry, in a hurry, or has complained before. One line is enough. | The receiver knows whether to start by apologizing or go straight to the point. |
| What's expected of the receiver | The concrete action: 'confirm the change for them', 'send them the payment link', 'explain the real deadline to them'. | The receiver knows what they have to do, not just what it's about. |
| Expected response time | How long the customer expects to wait for a response. If it's urgent, say so. | The receiver can prioritize without asking. |
This block of text is pasted into the conversation or the internal channel, but it has to stay associated with the customer's chat. If it stays only in an internal group and the receiver doesn't see it when opening the chat, it's useless.
Stage 2: who confirms and in how long
A handoff without a confirmation of receipt isn't a handoff: it's a message thrown away. The person handing off doesn't know if the other person saw it, and the customer is left in the middle. The confirmation has to be explicit and within an agreed timeframe.
| Moment | Who acts | What has to happen | Suggested timeframe |
|---|---|---|---|
| Handoff | Area handing off | Leaves the written block from Stage 1, tags the conversation with the destination area, and notifies the receiver. | Immediately, before stopping attending the chat. |
| Confirmation of receipt | Receiving area | Replies in the internal channel with a 'received' and, if any data is missing, asks for it there, not from the customer. | Within the same shift. If the receiving area isn't active, it's defined in the internal policy. |
| First contact with the customer | Receiving area | Writes to the customer from the same conversation, introducing themselves if necessary and picking up the reason. | Within the agreed service hours. If the customer expected an immediate response, let them know beforehand. |
| Closing the handoff | Area that handed off | Verifies that the receiver actually replied. If not, escalates. | At the end of the shift or the next day, depending on volume. |
The timeframes in this table are a proposed internal policy, not a rule of WhatsApp or Meta. Each business defines its own according to its service hours and volume. What matters isn't the exact number, but that there's an agreed number and that someone reviews it.
Stage 3: responsibility matrix by case type
Not all handoffs are the same. A billing case is not as urgent as a price inquiry, and they are not confirmed by the same person. This matrix organizes who hands off, who receives, and who confirms the closure based on the type of case.
| Case type | Hands off | Receives | Confirms closure |
|---|---|---|---|
| Price or availability inquiry | Sales | Sales (same team, different shift) | Shift supervisor |
| Order or shipping complaint | Sales or support | Logistics or support | Support |
| Billing, payments, receipts | Sales or support | Administration | Administration |
| Plan change or cancellation | Sales | Administration | Administration with notice to sales |
| Product technical issue | Support | Tier 2 support or vendor | Support |
| Angry customer or threat of public complaint | Anyone | Area lead | Owner or manager |
The 'confirms closure' column is the one that almost never exists and the one that prevents a case from staying open forever. Someone has to check, even once a day, that the handoffs in their area have been closed.
Stage 4: what to review the next day (handoff audit)
The checklist does not end when the receiver replies. It ends when someone checks that the handoff worked. This is the minimum audit, to be done once a day or every two days depending on volume.
- Count how many conversations were tagged with each area during the day. If the number is very different from previous days, something happened: it could be more volume or someone may be tagging incorrectly.
- Review the conversations tagged with an area that did not get a response from that area. These are the dropped handoffs.
- Verify that the Stage 1 block is present in the day's handoffs. If it is missing in more than half, the team is not using the checklist: it needs to be reinforced, not audited more strictly.
- Check whether the customer had to repeat information. If they repeated the order number or the reason, the handoff failed even if the receiver replied.
- Note the handoffs that returned to the original area. A case that bounces between two areas is a problem of responsibility definition, not speed.
- Count how many handoffs were closed without explicit confirmation. If the receiver replies but no one marks the closure, the case stays in administrative limbo.
If you use Wando, the inbox with tags and the conversation history allow you to do this review without leaving the tool. If you use another, you need the internal channel and the customer chat to be linked in some way: if the handoff lives in two places that do not talk to each other, the audit becomes manual and gets abandoned within a week.
Signs that the handoff failed (and what to do)
Not every failed handoff looks the same. These are the typical signs, ordered from the mildest to the most serious, with what to do in each case.
| Sign | What it means | What to do |
|---|---|---|
| The receiver asks for a piece of information that was already in the block | The block was not read or was not written | Reinforce the checklist at the next team meeting. If it happens often, shorten the block: if it is too long, it does not get read. |
| The customer repeats information | The receiver did not read the block or the block was not associated with the chat | Check where the block is being pasted. It has to be in the customer's conversation, not only in the internal channel. |
| The case goes back to the original area without resolution | Responsibilities are not clear or the receiver does not have what they need to resolve it | Review the responsibility matrix. If the receiver cannot resolve it, the problem is permissions or information, not attitude. |
| Days go by and the case is still open | No one is confirming closures | Assign a closure owner per area and a daily review. Without that, open cases pile up without anyone noticing. |
| The customer writes again asking what happened | The handoff was made without notifying the customer | Notify the customer before or immediately after transferring: 'X from such area is going to write to you.' Silence is what generates the complaint. |
| Two areas answer at the same time | The handoff was not marked as received | Explicit confirmation of receipt before the receiver writes to the customer. Confirmation prevents duplication. |
When the handoff fails, the temptation is to blame the person. Almost always the problem is in the process: a field that was not defined, an owner that was not named, a time window that was not agreed on. Adjust the process before adjusting the team.
How to measure whether the handoff between areas improved
A checklist without measurement gets abandoned. These are the three minimum metrics to know whether the handoff between areas is working, with the formula to calculate them. Your business sets the numbers: here is the method.
- Confirmed handoff rate: handoffs with explicit confirmation of receipt divided by total handoffs in the period. If it is low, the problem is confirmation, not speed. Set the threshold with the team after two weeks of measuring: a number set in advance says nothing about your operation.
- Customer repetition rate: conversations where the customer repeats a piece of information they had already given, divided by total transferred conversations. Every repetition is a poorly assembled handoff.
- Time until the receiver's first contact: from when it is transferred until the receiving area writes to the customer. It is measured by area, not globally: administration and support usually have different times and comparing them is useless.
These three can be calculated by hand with a spreadsheet if the volume is low. With high volume, you need the labels and the history to be in the same tool. If you have to export from one place and cross-reference with another, the measurement is done once and not repeated.
Common mistakes when building this checklist
- Putting in too many fields. If the handoff block has twelve fields, nobody fills it out. Six are enough: reason, data, promise, status, expected action, deadline.
- Not naming a closing owner. The handoff is confirmed upon receipt, but nobody closes it. The case stays open and shows up in the audit as a failure when it was actually resolved.
- Setting deadlines the team can't meet. If the receiving area is open from 9:00 to 17:00 and the handoff happens at 16:55, the 'same shift' deadline is unrealistic. Adjust the deadline to the real schedule, not the ideal one.
- Handing off without telling the customer. The customer sees that the usual person stopped writing and someone else writes to them. If they weren't told, they write asking what happened.
- Auditing every handoff. You can't. Audit a sample: the previous day's, or one area per day. The full audit gets abandoned in the second week.
- Confusing handoff with escalation. A handoff changes areas; an escalation goes up a level within the same area. If they get mixed up, the responsibility matrix is useless.
Template to copy: handoff block
This is the minimum block to paste into the conversation or the internal channel before transferring. You copy it, fill it out, and send it. If a field doesn't apply, write 'not applicable', don't leave it blank: a blank makes the receiver doubt.
- Reason: (one specific sentence)
- Data already collected: (name, order or customer number, whatever the customer already gave)
- What was promised: (deadlines, prices, solutions; if nothing was promised, 'not applicable')
- Customer status: (normal / in a hurry / angry / prior complaint)
- Expected action: (what the receiving area has to do)
- Expected deadline: (when the customer expects a response)
- Hands off: (name of the person passing the conversation)
- Receives: (name of the person taking it)
Eight lines. If your team doesn't fill out eight lines before transferring, the problem isn't the checklist: it's that the handoff isn't being treated as part of the work, but as a formality to get the chat off their back. That gets fixed in the team meeting, not in the tool.
When this checklist doesn't apply
Not every business needs this. If you're the only one handling things, there's no handoff between areas: there's a change of topic in your own head. If you have two people but they handle the same things and cover each other by shifts, what you need is a shift handoff checklist, not an inter-area one. And if your volume is so low that one case a week moves from one area to another, the formal checklist is more bureaucracy than help: a clear internal message and a confirmation are enough.
The sign that you do need it is simple: the customer repeats information, or two people answer the same thing, or a case stays open longer than it should without anyone knowing whose it was. When that happens often, the checklist stops being a document and becomes the way the team works.
Frequently asked questions
What must be written down before handing over a WhatsApp conversation to another area?+
At minimum: reason for the handover, data the customer already gave (name, order or customer number), what was promised to them, the customer's emotional state, the expected action from the receiving area, and the expected response time. The block must be linked to the customer's conversation, not just in an internal channel.
Who confirms receipt of a handover between areas?+
The receiving area, explicitly and in the internal channel, before writing to the customer. If any data is missing, they ask for it there, not from the customer. The area that handed over then verifies that the receiver replied and, if not, escalates.
How long does the receiving area have to respond?+
There is no universal deadline: it depends on each business's service hours and volume. What matters is that there is an agreed deadline per area and that someone reviews compliance. If the handover happens outside the receiving area's hours, the deadline must reflect that.
How do you measure whether the handover between areas is working?+
With three metrics: rate of handovers with explicit confirmation, customer repetition rate (how many times they repeat data they already gave), and time until the receiving area's first contact. They are calculated per area, not globally, because administration and support times are usually different.
What do I do if a case bounces between two areas?+
Review the responsibility matrix: if the case returns to the original area without resolution, the problem is usually the definition of responsibilities or the receiving area's permissions, not speed. Assign a closing owner per area and a daily review of open cases.
Does this checklist work if I'm the only person handling chats?+
No. If you're the only one, there is no handover between areas: there's a change of topic within the same person. The checklist applies when there are at least two differentiated areas handling WhatsApp and conversations move from one to the other.
Answer WhatsApp with AI
Try Wando free. No credit card required.