Greeting and First Response Audit Checklist: What to Review in the First 30 Seconds

The greeting and the first response are the part of the conversation that gets audited the least and noticed the most. A business can have a good catalog, good templates, and good follow-up, but if the first message is slow, arrives at night, or starts without saying who is speaking, the customer has already formed an impression. This page is a checklist to review that window: the first 30 seconds of every conversation. It is not an article to read straight through: it is material to print, copy into a spreadsheet, or check off on screen while reviewing real conversations.

It is designed for the person who answers, for the person who supervises the inbox, and for the person who has to decide whether the team is responding well or just responding. It can be applied to any WhatsApp Business tool, including Meta's official API, because what is audited is the conversation, not the software. The only part where Wando appears is at the end, as an example of where this data lives if you already use an inbox with AI suggestions.

What counts as "first 30 seconds"

The window is not literal. For this audit, "first 30 seconds" means: from the moment the customer's first message comes in until the business gives a response that the customer can read and use. An automatic response that only says "we received your message" does not count if no one follows up afterward. The first useful response counts: the one that greets, says who is speaking, and leaves the customer with a clear next step or with the conversation effectively taken over by a person.

That slice is what matters because it is what the customer perceives. If the business's first message is an empty confirmation and the real response arrives two hours later, for the customer the first response took two hours. The audit has to record that gap, not hide it.

Stage 1: the greeting (what it says and how it says it)

The greeting is the business's first line. It is audited by content, not by friendliness. A correct greeting serves three functions: it identifies the business, acknowledges what the customer wrote, and opens the next step. A greeting that only says "Hi, how can we help you?" when the customer has already written their inquiry is ignoring the message and forcing them to repeat it.

• Does the greeting name the business or the team? The customer needs to know who they are talking to without having to look it up.
• Does it pick up what the customer wrote? If they asked about a product, an appointment or a price, the greeting has to mention it.
• Is it in the customer's language and register? If they wrote in Rioplatense Spanish, do not reply in a neutral corporate tone or in another language.
• Does it avoid the generic template message with no personalization? A repeated "Hi, thanks for writing to us" across the 20 conversations in the sample is a warning sign.
• Does it include the customer's name when available? If the contact has a name on file, use it; if not, do not make one up.
• Does it make clear who is next? If it is a person, a name or a role; if it is an automated step, say so without disguising it.

How to know it is OK: read the greeting without seeing the rest of the conversation. If you can tell what the customer wants and what will happen next, the greeting works. If not, it fails.

Stage 2: the time until the first useful reply

There is no universal number here. The acceptable time depends on the industry and the time of day, and it is not appropriate to invent a standard. What you can do is measure the business's actual time and compare it with what the business itself promises. If the website says "we reply in minutes" and the sample shows hours, the problem is the promise, not the number.

To measure properly you have to use the moment the message came in, not the moment it was saved to the database. If you are looking at an in-house tool or an export, make sure to take the timestamp of the customer's message. In systems that imported history, the row's insertion date is no good: it can show that everything arrived on the same day and at the same time. It is a technical detail, but it completely changes the result of the audit.

• Did the first useful reply arrive within the hours the business says it is open?
• Is the time measured from the customer's message or from when someone opened the conversation? It has to be from the customer's message.
• Is there a difference between the time during business hours and the time outside business hours? If there is not, there is probably no out-of-hours auto-reply.
• Is the time even across agents or is there one who concentrates the delays?
• Do the delays happen every day or are they concentrated on one day and one time slot?

Stage 3: out of hours and messages that come in when no one is there

A significant portion of messages comes in when the business is closed. That's not a problem on its own: the problem is that the customer doesn't know what to expect. The audit has to separate two things: whether there is an out-of-hours response, and whether that response says when the real reply will arrive.

• Is an out-of-hours auto-reply configured?
• Does that auto-reply state the hours when the business is open again?
• Does it say what the customer can do in the meantime (leave their details, choose a time, view a catalog)?
• Does the schedule it states match the actual business hours? A mismatch here generates avoidable complaints.
• Are holidays and special days accounted for, or does the auto-reply still say "tomorrow" on a Sunday?
• Is the conversation flagged as pending so someone picks it up when they open, or does it get lost among the others?

How to know it's OK: take a message that came in on a Sunday night and follow it until someone replied. If you can reconstruct the path without guessing, the setup is fine.

Stage 4: the handoff from the first response to the real conversation

The first response can be automatic or human, but at some point the conversation has to move to a person (or to a flow that resolves it). What's audited is whether that handoff preserves the information or loses it. The most common case: the customer already said what they wanted in the first message, the first response doesn't pick it up, and the person who takes the conversation asks the same thing again. The customer repeats themselves, and that's where the friction starts.

• Do the customer's name, the reason and the product or service mentioned travel through to whoever handles it?
• Can whoever handles it see the full history or only the last message?
• Is there an assigned owner, or does the conversation sit in a shared inbox with no owner?
• Is it recorded somewhere that the conversation already had a first response, so it isn't answered twice?
• If the customer writes again before anyone replies, does the system treat it as the same case or as a new one?
• If the person who was going to reply isn't there, is there a replacement, or does the conversation sit waiting?

How to know it's OK: read only the business's second response. If it doesn't repeat any question the customer already answered, the handoff preserves the information.

Audit table: stage, what's reviewed and signal that it's OK

How to log findings (and why 'it's fine' is not enough)

An audit without a log is forgotten in a week. The minimum log per conversation is: conversation identifier, date and time of the customer's first message, date and time of the first useful response, whether it was within or outside business hours, who responded, whether questions were repeated and whether the customer wrote again before receiving a response. With those columns you can calculate percentages and compare week against week.

• Conversation identifier (the customer's name is not needed to audit).
• Date and time of the customer's first message.
• Date and time of the first useful response.
• Within or outside business hours.
• Agent or owner who responded.
• Did the customer repeat information they had already given? Yes / No.
• Did the customer write again before receiving a response? Yes / No.
• Reason for the contact, if it can be classified.

20 conversations are enough to have percentages that move. If 30% of the sample repeated information, there is a handover problem. If 50% wrote again before receiving a response, there is a time problem. If all the responses outside business hours arrived at the same minute the next day, they are probably all piling up for the same person.

What to do when something fails

Not all problems are fixed the same way. Before touching anything, it is worth classifying the finding: is it a configuration, people or volume problem? The three have different solutions and confusing them wastes time.

• If the greeting is generic in every conversation: it is configuration. The greeting needs to be rewritten so it references the inquiry, not so it greets better.
• If the greeting is good in some and bad in others: it is people. A minimum standard needs to be agreed on and reviewed in the next audit, not the template rewritten.
• If the time is high during business hours: first check how many simultaneous conversations there are per person. It may be volume, not slowness.
• If the time is high only outside business hours: it is configuration of the auto-reply and of the moment someone picks up the inbox at opening.
• If the customer repeats information: it is handover. You need to review what fields travel from the first message to whoever handles it.
• If nobody knows who has the conversation: it is assignment. Before adding people, define owners per conversation.
• If the problem repeats in the same time slot every week: it is not an isolated case, it is a shift that is not covered.

Resolution times vary by case and by tool. A configuration change can show up in the next audit; a shift coverage change can take weeks. If after two consecutive audits the same finding remains unchanged and there is no clear identifiable cause, it is worth escalating: it may be a problem with the tool, the WhatsApp integration, or an account limit with Meta, and that can no longer be fixed by adjusting texts.

Common mistakes when auditing the greeting

• Auditing by choosing the conversations that went well. The sample must be random within the week, not the ones the team remembers.
• Measuring the time from when someone opened the conversation instead of from the customer's message. The result always looks better than it was.
• Counting an automatic acknowledgment that resolves nothing as a response.
• Looking only at the average. A low average can hide an entire shift with no response.
• Not separating business hours from after hours. They are two different problems with two different solutions.
• Confusing friendliness with effectiveness. A warm greeting that does not pick up the inquiry is still a greeting that makes the customer repeat themselves.
• Auditing only once. Without repetition there is no way to know if something improved.

Suggested frequency and what to compare

An audit of 20 conversations can be done in less than an hour if the record is set up. The reasonable approach is to do it once a week for a month, and then move to once a month if the numbers hold. What is compared is not the audit against the ideal, but the week against the previous week: same indicators, same number of conversations, same hours covered.

• Week 1: baseline audit. Only measure, without changing anything.
• Week 2: apply one change at a time. If greeting, schedule, and assignment are changed together, you do not know what worked.
• Week 3: repeat the measurement with the same number of conversations.
• Week 4: compare and decide what stays and what is reverted.
• Afterward: a monthly maintenance audit, with the full table.

If the business uses an inbox with AI suggestions, such as Wando, several of these indicators are already available without building the spreadsheet: the inbox shows conversations with their history, tags allow counting reasons, and message and campaign statistics give the volume by time slot. The AI suggests replies and the team approves them, so the greeting remains a business decision, not the system's. That is what is audited: the decision, not the tool.