A guide to WhatsApp support
How to stop losing clients to slow WhatsApp replies?
Reduce delay with one inbox, debounce to group messages, eligibility rules and human takeover; Bia organizes and records the conversation, but it does not promise an instant reply or continuous provider availability.
A client asking about a treatment price, time or condition cannot see the queue, provider or clinic dashboard. They only notice whether someone understood the message and answered safely. Bia brings the real WhatsApp conversation together, waits for a short burst of messages before calling AI, checks whether a reply can still be sent and lets staff take over when judgment is needed. This guide turns those existing behaviors into an operating routine. It does not invent an SLA, guarantee provider availability or turn delay into a conversion number without data.
- One inbox for conversations, media, contacts and delivery state
- Per-conversation debounce that groups messages before AI replies
- Redis/BullMQ queue with an in-memory fallback when Redis is unavailable
- Open-conversation, opt-out, block and AI-mode gates before sending
- Audited human takeover and explicit hand-back to AI
- Visible send and failure states without an instant-reply promise
1. Measure the wait a client actually feels
Start by separating three moments: the message reaches WhatsApp, the conversation enters the inbox and a reply is accepted by the provider. They can happen at different times. The screen shows the latest message time and refreshes through polling and real-time events, but that clock is not an uptime or service promise. Before comparing weeks, choose the interval, time zone and definition of a first reply.
A price question, an appointment confirmation and a complaint do not carry the same risk. The AI receptionist can handle repetitive messages, while the code recognizes requests for human care and creates a persistent alert when someone is needed. An acceptable delay is a clinic operating rule, not a marketing sentence copied from another system.
Build a baseline from real chats: when the message arrived, when AI replied, when staff took over and when the conversation closed. Do not count a team member being online as a delivered reply. The product keeps message history and states; it does not supply a universal satisfaction percentage or prove that a client read a message.
- Define first reply, period, time zone and denominator.
- Separate provider delay from human decision delay.
- Use the clinic's own data before choosing a target.
2. Make the inbox the conversation's source of truth
The inbox lists up to fifty conversations ordered by the latest message and shows name, phone, preview, unread count and current AI mode. Opening a chat loads recent messages, clears the unread counter and keeps the selection while updates arrive. That stops reception from searching for the same client on a personal phone, spreadsheet and another browser tab.
Text, audio, image, video, document, location, reaction and contact messages have their own rendering. The history distinguishes client, AI, staff and owner-phone messages, and shows delivery states. A file that cannot load yet appears as a localized error state; it should not be replaced with an invented answer just to make the list look complete.
The inbox is authenticated and shows real conversations when WhatsApp is connected. In demo mode it is disabled, and an account without chats shows an empty state. That distinction matters: do not confuse a test screen with a commercial queue or promise that a public page will triage clients without an authorized connection.
- Open the conversation in the inbox before replying elsewhere.
- Use preview, unread, media and delivery to rebuild context.
- Demo mode without WhatsApp is not a client queue.
3. Let debounce group messages from the same person
Clients often send several short messages: treatment name, photo, time and question. The engine does not fire an isolated reply for every bubble. After a message arrives, `scheduleAiReply` reads the debounce setting and schedules processing; the default is thirty seconds and the configurable ceiling is three hundred seconds. A new message in the same conversation removes the old job and restarts the window.
In production, the `nl-ai-reply` queue uses BullMQ over Redis when the connection is available. Its worker processes up to five jobs in parallel and jobs use a deterministic conversation identifier. If Redis is unavailable, the service logs a warning and uses an in-memory timer. That fallback supports development and controlled continuity, but it is not a durability promise after a process restart.
Choose a window the clinic can actually monitor. A short debounce can answer before the client finishes explaining; a long one can feel like silence. Compare the setting with opening hours, message volume and takeover capacity. Do not call a routine instant when it deliberately waits for context.
- New messages restart the debounce for that conversation.
- The default is 30 seconds; the code ceiling is 300 seconds.
- Redis and the in-memory fallback have different guarantees.
4. Configure AI from a source staff can review
The reply comes from the receptionist's published configuration and recent conversation history. The clinic can test a version, publish after review, pause it and return to an earlier configuration. Language, catalog, scheduling rules and safety instructions become agent context; when a fact is not configured, the reply should ask for confirmation instead of filling the gap with a price or availability.
The agent can reply, stay silent, end a conversation or request human care. When a scheduling tool fails or an update is not confirmed, the flow uses a fallback and leaves the decision to the responsible person. Complaints and adverse signals also create a persistent alert. Speed should not be purchased with an unchecked clinical or commercial promise.
Review what AI knows before diagnosing a timing problem. Active catalog, policies, time zone and connected instance must match today's operation. Publishing a new version does not make the provider faster, and a longer instruction does not replace a send gate. The best configuration lets staff recognize a limit and take over without starting again.
- Publish only a configuration reviewed by the clinic.
- Missing data should trigger confirmation, not an invented price.
- Fallback and handoff preserve context for staff.
5. Check the gates before a reply can leave
The worker makes an initial check: the conversation must exist, be open and have AI active; the client must exist and cannot have opted out or been hard-blocked. Immediately before each bubble, `finalSendEligibility` queries fresh state, the suppression list and the same criteria again. If staff took over while AI was preparing text, sending is blocked with `human_takeover`.
The platform gate can also stop a reply because a clinic is suspended, a kill switch is active or a budget limit is reached. A missing instance, disconnected provider or health failure should not be hidden behind an optimistic inbox message. The safe path records the state, alerts staff and does not blindly retry an ambiguous send.
These checks can seem slower than a direct send, but they protect the client and clinic. Opt-out, block and a closed conversation outrank a speed target. The same discipline applies to campaigns: marketing automation uses queues, time windows and limits instead of turning the inbox into a bulk-sending tool.
- An open conversation and active AI are required for each reply.
- Opt-out, block and suppression prevent sending.
- A prepared reply can be discarded when state changes.
6. Take over when the situation needs a person
Staff do not have to wait for AI to finish. The takeover control changes the conversation to `paused_takeover`, records who assumed it, writes an audit entry and emits a start event. The list shows that AI is paused and, when available, who is handling the chat. Another person should not unknowingly compete for the same conversation: the server applies the ownership link and reports an existing takeover.
Handoff can also originate with the agent. A complaint, adverse reaction, sensitive question or unfinished task creates a human alert linked to the conversation. Reception opens the history, reads the reason and replies in context. At that moment, the useful speed is reducing repetition for the client, not keeping a bot talking while someone must decide.
Takeover does not erase messages or close the conversation. It pauses AI while preserving history, media, contact and delivery state. The responsible person can write, record the decision and hand the chat back when it is ready for automation. If the clinic does not want AI to resume, it can leave the conversation paused and treat it as human work.
- Takeover pauses AI and identifies the responsible person.
- Handoff creates a persistent alert without deleting history.
- Staff should not reply over someone who already took over.
7. Reply and hand back without duplicating messages
When staff use the inbox composer, the server sends text tied to the conversation and tenant. It reserves the send before contacting WhatsApp, uses `clientMessageId` when supplied and an intent key to prevent two inserts when the same action repeats. If the provider fails or the receipt becomes ambiguous, the message receives its own state and the system does not blindly send a second copy.
A human reply also moves the conversation to `paused_takeover` automatically, so AI cannot write over staff. The screen placeholder warns that replying pauses AI, and the hand-back control requires an explicit action. After hand-back, a new inbound message can schedule debounce again; earlier history remains context rather than becoming a new conversation.
Write the next step using what was actually confirmed: a catalog price, a saved time or an instruction for the responsible person to return. Do not use a fast reply to promise stock, refunds, clinical outcomes or a slot that did not pass the server. Speed without idempotency, eligibility and authorization turns waiting into rework and risk.
- Reservation and the intent key protect against duplicate sends.
- A staff reply pauses AI automatically.
- Handing back is explicit and keeps the history.
8. Review states, failures and limits every week
An operating routine ends by reading states, not by clicking send. Review open, paused, unread and human-alert conversations. For each reply, distinguish pending, sent, delivered, read, failed and unknown. A refresh failure can leave the screen showing the last known data; it must not be treated as an empty queue or permission to repeat a message.
The queue exposes mode, active, waiting, delayed and failed job metrics. Use them to investigate unavailable Redis, an unstable provider, an excessive debounce or a configuration that produces too many handoffs. The system audits takeover, hand-back and staff sends, but it does not calculate the value of each recovered sale or prove that a particular delay lost a client.
End the week with a sample of conversations read from start to finish. Note when a reply was adequate, when data was missing and when staff had to take over. If the clinic needs an SLA, team routing, commercial read confirmation or guaranteed provider availability, record it as a product opportunity. For now Bia organizes the reply and fallback; the operation verifies the result.
- An unknown state calls for investigation, not automatic resend.
- Queue metrics show technical health, not recovered revenue.
- SLA and provider availability are not current promises.
What this guide does — and does not promise
It describes the existing inbox, debounce, queue, gates, takeover and sending flows. It does not promise instant reply, an always-available provider, an SLA, recovered sales or delivery guaranteed by WhatsApp.
- Replies depend on debounce, published configuration, eligibility, queue, platform and provider; they are not guaranteed instant replies.
- Redis can run BullMQ; when unavailable, the process uses an in-memory fallback without durability after restart.
- Takeover pauses AI and hand-back is explicit; no automatic team resolves every conversation without supervision.
- An unknown send state does not prove delivery or authorize a resend without confirmation.
- This page does not offer an SLA, universal WhatsApp availability, conversion percentage or a guarantee of no lost clients.
Frequently asked questions
Questions about slow replies and WhatsApp support
Does Bia reply instantly?
There is no instant-reply guarantee. The system uses debounce, a queue, eligibility gates, AI configuration and a connected provider; the default debounce is 30 seconds and can reach 300.
What happens when a client sends several messages?
New messages in the same conversation remove the pending job and restart debounce, so AI receives more context before replying. That does not mean every message will receive a reply.
Can staff take over a conversation?
Yes. Takeover changes the conversation to `paused_takeover`, records the responsible person and creates an audit entry. Staff can reply in the inbox and hand it back to AI explicitly.
Does replying from the inbox keep AI quiet?
Yes. A staff message automatically pauses AI in that conversation, preventing two replies at once. History and delivery states remain visible.
Does Bia guarantee message delivery?
No. The system shows send states and can record an ambiguous receipt or failure. Opt-out, block, takeover, provider and platform gates can prevent sending.
Test support with conversations from your real routine
Create an account, connect the channel and review the configuration before publishing the receptionist. Start with a test conversation and let staff take over whenever context requires it.
Create my account