Audit checklist for conversations referred to an external area: what was sent, what came back and how long it took

What this checklist is for

When a conversation leaves the support team and moves to an external area (a supplier, an accounting firm, an outsourced workshop, a business partner, another company's technical service), the conversation is no longer under direct control. The customer keeps writing on WhatsApp, but the person replying is no longer your team. That gap is where complaints get lost: nobody knows what was sent, nobody knows what came back, and nobody measures how long it took. This audit does not evaluate the quality of the external area's work. It evaluates whether your operation has a record of what it forwarded and whether it can prove what happened afterward.

It runs on a sample, not on the entire history. Twenty or thirty forwarded conversations are enough to see the pattern. If the pattern is broken, there is no need to audit further: first you fix the circuit and then you measure again.

How to build the sample

1. 1Choose a closed time window (for example, the last 30 days). Do not mix months.
2. 2Filter the conversations with the external area label or with the forwarding label.
3. 3Discard the ones that are still open and in progress: they cannot be audited until they come back or are closed.
4. 4If you have several external areas, separate the sample by area. A general average hides the area that is failing.
5. 5Note how many forwarded conversations there were in the window and how many entered the sample. If the sample is less than 20% of the total forwarded, expand it: with low volume the percentage lies.

Stage 1: what was sent

Here you audit the outgoing message. The most common problem is not that it was not forwarded, but that it was forwarded without leaving a trace of what was requested. If the external area receives a forward of the conversation without an explicit request, the reply that comes back is usually incomplete and you have to ask again. This happens a lot in food service when something is forwarded to an ingredient supplier: if the message says "I'm sending you the customer's chat" instead of "I need to confirm whether there is stock of X for Thursday," the reply comes back half-finished and the customer waits twice as long.

• The handoff message has a concrete, verifiable request (a data point, a quote, a date, a confirmation), not a "I'll forward you the chat".
• It is identified who made the handoff and when. Without an author and a time, there is no way to follow up later.
• The channel through which it was sent is recorded: WhatsApp, email, an internal group, or a system of the external area.
• If the client was notified of the handoff, the notice exists in the same conversation and states what will happen and in what approximate timeframe.
• The external area has an identifier to respond to: conversation number, order number, or client name. If it doesn't have one, the response comes back without being able to be matched.

Stage 2: what came back

Here the return message is audited. The typical problem is that a partial response comes back: the external area answers half of the request and the support team considers it complete because the client is already waiting. That partial response becomes a second back-and-forth that nobody records. In real estate agencies this happens often with property verification: availability and conditions are requested, only availability comes back, and the team replies to the client without the conditions.

• The response that came back covers all the points of the original request. If you asked for three data points and two came back, the handoff is not closed.
• The response is recorded in the same client conversation, not only in the internal channel through which it was handed off.
• It is recorded who from the external area responded, so it can be escalated if it fails again.
• If the response includes a commitment (a date, a price, a visit), that commitment was written somewhere the support team can consult.
• If the external area responded to the client directly, there is a record of that response in the conversation.

Stage 3: in how much time

Here the clock is measured. There are two different times and it is best not to mix them: the time it took the external area to respond, and the time it took your team to forward that response to the client. The second is the one the client perceives and the one that is usually out of control. In a medical office, for example, the lab can respond in two hours and the client's appointment is confirmed only the next day because nobody looked at the message in time.

• You recorded the departure time of the request and the return time of the response. Without both times there is no measurement.
• You measured the external area's time and the internal time separately.
• You compared against the timeframe you promised the client, not against an abstract ideal.
• You flagged the handoffs that exceeded the promised timeframe and noted how many they were out of the total.
• If the client wrote again while waiting, that counts as a sign of delay: it was recorded in the conversation.

What to do when something fails

The audit result is not a number: it is a list of failures grouped by stage. Each type of failure has a different fix and they are not all fixed together. Sort them by how many conversations they affect, not by how serious they sound.

• If the output fails (vague orders): create a handoff template with the required fields. Without that, each person hands off however they want.
• If identification fails: agree on a unique identifier with the external area and always use it. It is a process agreement, not a system feature.
• If customer notification fails: add the notification as a required step of the handoff. If the customer is not notified, they write anyway and the team responds anyway, and the handoff becomes invisible.
• If the partial response fails: define that a handoff is not closed until all requested points come back. The person who handed it off is responsible for monitoring it.
• If the external area's time fails: first measure for two or three more weeks before complaining. An isolated spike is not a pattern. If the pattern holds, then there is a conversation with the external area.
• If the internal time fails: the problem is not the external area, it is your team. Check who receives the response and whether that person has the shift assigned to forward it.
• If the closure fails: add a result tag (resolved, no response, handed off again). Without a tag, no report is possible.

How to know if service improved after fixing

The audit is run once to find the failures and then repeated with the same sample and the same time window. Comparing against the previous run is the only thing that tells you whether the circuit improved. Comparing against an ideal is useless because you have nothing to compare it with.

• Same number of conversations audited, same window duration, same filter criteria.
• One number per stage, not a general average.
• If one stage improved and another worsened, note both: you may have moved the bottleneck, not resolved it.
• Save the date of each run. An audit without a date cannot be compared with anything.

The three most repeated mistakes

• Audit only the referrals that went well. If the sample is made up of closed and tidy conversations, the audit measures nothing.
• Measure total time instead of separating the external area's time from the internal time. When they are mixed, the support team blames the external area and the external area blames the team.
• Do not log the response in the customer's conversation. If the response lives only in an internal group, the day someone asks what happened with that customer there is nothing to show.

Difficult questions this audit does not answer

There are things the checklist cannot tell you, and it is worth knowing them before promising results. If the external area works well but the customer still complains, the problem is the agreement, not the delay. If you refer because your team does not know how to respond, no audit will fix it.

• It does not say whether the external area charges too much or too little: that is another audit.
• It does not say whether the customer was satisfied: it only says whether the conversation was closed.
• It does not say whether referring was the right decision: it only says whether the process worked.
• It does not say whether it is worth continuing to refer to that area: that is decided with the business, not with the sample.

Referrals that should not be audited the same way

Some referrals do not follow the normal process, and including them in the sample distorts the result. It is better to remove them and count them separately.

• Urgent referrals outside business hours: the promised deadline does not apply the same way.
• Referrals the customer explicitly requested to another area: notifying the customer is not necessary.
• Repeated referrals of the same case: they count as one, not as three.
• Referrals that came back resolved on the first attempt and without intervention from the team: they serve as a reference, not as a sample.