Checklist to audit conversation handoffs between agents: what data to verify before closing the handoff
What this checklist is for
A poorly done conversation handover only becomes obvious when the customer asks something the new agent doesn't know, or when the original agent is already gone and no one can reconstruct what was promised. By that point, the mistake has already cost a duplicated response, a discount that wasn't authorized, or a customer who switches to the competition. This checklist organizes what to review before considering a handover closed, in what order, and with what signal you know each point is done right.
It's designed for teams that handle WhatsApp Business with several agents, whether or not they use a tool with a shared inbox. The points below don't depend on the software: they are the data any handover must leave available so the receiving agent can continue without asking the customer to repeat anything.
The 5 pieces of data every handover must leave, no matter what
Before going into the full checklist, it's worth having the basics clear. If these five pieces of data aren't there, the handover is incomplete no matter how many other points have been met.
| Data | What it includes | Signal that it's OK |
|---|---|---|
| Reason for contact | The original problem or request the customer wrote in with | The receiving agent can explain in one sentence why the customer is writing, without looking at the full history |
| Relevant history | The promises made, the agreements reached, and what has already been tried | There is a list of 2 to 5 items with date and owner, not a wall of unordered text |
| Current status | Where the case stands: waiting on something from the customer, waiting on something internal, resolved, or escalated | You can say exactly what's missing to close the case, with the name and date of whoever is doing it |
| Pending commitments | Everything promised to the customer, with date and the channel through which they will be notified | Each promise has an owner, a date, and a notification channel; none was left as "we agreed on something" |
| Customer contact | Name, phone number, and the specific detail needed for the case (order number, address, etc.) | The receiving agent has everything to identify the customer without asking for the number again |
Full checklist: 28 points to audit before closing the handover
Print it, copy it into your management tool, or check it off on paper. Each point says what to review and how to know it's right. If a point doesn't apply to your case (for example, there's no discount promise), mark it as N/A and move on.
Stage 1: before touching the handoff
- Is the reason for the contact written in the handoff, not only in the history? OK sign: the agent receiving it can read it in the notes field or in the first line of the summary, without having to open the whole conversation.
- Is the customer identified with a name and at least one verifiable contact detail? OK sign: there is a name, phone number and, if applicable, order or invoice number.
- Did the agent handing off leave their name and the date of the handoff? OK sign: it is possible to know who handled it and when, in case something needs to be asked later.
- Is the current status defined with a verb, not with a feeling? OK sign: it says "waiting for customer response since 12/3" or "escalated to internal support", not "it's complicated".
Stage 2: history and context
- Are the agreements made with the customer included, verbatim or summarized with dates? OK sign: it is possible to distinguish what was promised on Monday and what was promised on Wednesday, even if it is in two separate lines.
- Are the previous solution attempts included? OK sign: if the customer already tried restarting the device or was already offered a refund, that is noted and does not need to be asked again.
- Are the technical or case details that were mentioned included? OK sign: if a claim number, an error code or an address was mentioned, that detail is in the handoff.
- Is the history ordered chronologically or at least with dates? OK sign: the sequence can be reconstructed without reading the whole conversation.
- Is there anything the customer does NOT want or that has already been told it cannot be done? OK sign: it is noted so the next agent does not offer the same thing and create a false expectation.
Stage 3: commitments and promises
- Does each promise have an owner? OK sign: for every "we'll let you know" there is a name or a role, not a generic "we".
- Does each promise have a date? OK sign: a list of due dates can be put together for today, tomorrow and this week.
- Does each promise have a notification channel? OK sign: it is known whether the customer will be written to via WhatsApp, called or sent an email.
- Are the verbal promises that were not left in the chat noted? OK sign: if the previous agent called the customer and promised something, that is in the handoff even if it is not in the written history.
- Are there discounts, courtesy gestures or benefits pending authorization? OK sign: it is clear who has to approve it and by when. If there are none, mark N/A.
Stage 4: customer and case details
- Does the handoff have the customer's correct phone number? OK sign: it can be copied and pasted to call or write without searching the history.
- If the case has an order, claim or ticket number, is it written down? OK sign: the agent receiving it does not have to ask the customer to look up the number again.
- Are the customer's contact preferences included? OK sign: if the customer asked not to be called or to be written to only after 18:00, that is noted.
- Is there sensitive information that requires care? OK sign: if the customer shared personal or financial data, it is flagged so it is not repeated on an insecure channel.
Stage 5: the handover itself
- Is the handover done with the customer informed? OK sign: the customer was told they will continue with someone else, or the team has a clear no-notice policy and that policy is followed.
- Did the receiving agent confirm they read the handover? OK sign: there is a reply from the receiver, not just the handover sent by the person handing off.
- Does the receiving agent have access to the full history? OK sign: they can open the previous conversation without asking permission or waiting for it to be forwarded.
- Was the handover logged with date and time? OK sign: it can later be audited who handed off, who received, and when.
- Is there a deadline for the new agent's first contact? OK sign: it is defined whether the receiver has to write to the customer the same day or before a certain time.
Stage 6: after closing the handover
- Can the receiving agent explain the case in 30 seconds? OK sign: if asked what it is about, they answer without opening the history.
- Does the customer not have to repeat anything? OK sign: the new agent's first message shows they know the reason, for example "I saw you were waiting for the shipment of order 1234".
- Were promises with dates added to a follow-up list? OK sign: there is a place where commitments will come due and someone will review them.
- Was it made clear what to do if the customer writes again before the new agent makes the first contact? OK sign: there is a defined template reply or a criterion for who to route to.
- Can the handover be audited in the future? OK sign: a third party can reconstruct what happened, who promised what, and on what date, without talking to either of the two agents.
What to do when something fails
Not every handover goes perfectly. The difference is having a prepared response for typical failures, instead of improvising.
| Problem | What to do | When to escalate |
|---|---|---|
| The handover does not have the reason for the contact | Write to the agent who handed off and ask them for the detail before contacting the customer. If they do not respond, review the full history and reconstruct the reason with whatever is there. | If the history is not enough either and the customer is already waiting, notify a supervisor to decide whether to write to the customer apologizing and asking for context. |
| The customer repeats something they already said | Do not make them repeat it: tell them "Yes, I have noted that you were telling me about X, let me check and I will confirm". Then look for the detail in the history. | If the detail is nowhere, notify the person who handed off. If it still does not appear, escalate to a supervisor to avoid giving a wrong answer. |
| There is a promise without a date | Contact the customer and apologize for the delay, without making up a date. Then define a realistic date together with the team and let them know. | If the promise involves a financial benefit or a deadline that has already passed, escalate to a supervisor before promising anything new. |
| The agent who handed off does not answer questions | Note it down and continue with what you can resolve. Do not block the handover waiting for their response if the customer is waiting. | If more than 2 business hours have passed and there is a question preventing progress, escalate to a supervisor with details of what was asked and what is missing. |
| The customer writes before the new agent's first contact | Reply with a short message: "Hi, I am writing because your inquiry about X was left in my hands, I am reviewing it and will confirm shortly". | If the customer is upset about the delay or asks to speak with a person in charge, escalate with the full context. |
How to build your own checklist that your team actually uses
A 28-point checklist is impressive, but if your team is not going to complete it, it is useless. Experience shows that checklists that get used have three characteristics: they are short (fewer than 10 points), they are attached to the exact moment they are needed, and they have a clear OK signal.
- Divide it by moment: a 5-point mini-checklist for the person handing over, another 3-point one for the person receiving, and the full checklist only for periodic audits.
- Put it where the work happens: if the handover happens in a tool, the checklist has to be in that tool, not in a loose PDF.
- Test it with a real case: before implementing it, have two agents use it with a real conversation and adjust the points that were not understood.
- Review it every 3 months: handover types change, and the checklist has to change with them.
The difference between an approved handover and a rejected one
In practice, a handover is approved or rejected based on a single question: can the agent receiving it continue the conversation without making the customer repeat anything? If the answer is yes, the handover is good, even if some minor point is missing. If the answer is no, the handover is not ready to be closed, even if all 28 points are checked.
That is the final test. Before considering a handover closed, ask yourself that question. If the answer is no, go back to the checklist and look for what is missing. If the answer is yes, the handover is ready, and the checklist did its job.
Frequently asked questions
How much time do I have to make the first contact after receiving a handoff?+
There is no single deadline that applies to all cases: it depends on each team's setup and the type of conversation. What is worth doing is defining it in writing (for example, "the same business day" or "before 12:00 the next day") and making sure the receiving agent knows it before accepting the handoff. If the customer is already waiting for a response, the ideal thing is to let them know as soon as the handoff is received, even if it's just to say their case is now in someone else's hands.
What do I do if the agent who passed me the conversation didn't leave the reason for contact?+
First, review the full history: many times the reason can be inferred from the first messages. If it doesn't appear, write to the agent who handed it off and ask for the data. If they don't respond within a reasonable time (2 business hours is a typical reference) and the customer is waiting, escalate to a supervisor with the detail of what was asked and what is missing. Don't contact the customer without having the context, because you'll have to ask them to repeat something and that creates friction.
Does the customer have to know that the agent changed?+
It depends on each team's policy. Some choose to notify explicitly ("I'm transferring you to my colleague X who will take care of your case") and others prefer that the new agent simply shows they know the case without mentioning the change. What matters is that the decision is made in writing and always followed the same way. If the customer notices the change and no one explained it, they may interpret it as being given the runaround.
Can I make a handoff without the receiving agent confirming they read it?+
Technically you can, but it's not recommended. The receiving agent's confirmation is the only guarantee that the handoff didn't fall into a void. If the receiving agent doesn't confirm, the customer may be left waiting with no one attending to them. If your team uses a tool that doesn't have read confirmation, set a rule that the receiving agent must reply with a "received, I'll review it" within a maximum time.
What happens if the customer writes before the new agent makes the first contact?+
The ideal thing is to have a defined canned response for that case, for example: "Hi, I'm writing because your inquiry about X ended up in my hands, I'm reviewing it and will confirm shortly." That shows the customer their case is in someone's hands and sets an expectation framework. If the customer is upset about the delay or asks to speak with a manager, escalate with the full context.
Answer WhatsApp with AI
Try Wando free. No credit card required.