Website chat is down, but WhatsApp still works. What happens to the leads?
A webchat outage is more than a technical issue when customers use the widget to request quotations or appointments. The operations question is whether the messages were actually stored or whether visitors tried to send inquiries that never reached an inbox. Recovery depends on that distinction, not just on a green status indicator.
Do not assume every visitor moved to WhatsApp, or that an unrecorded conversation can be reconstructed later.
Separate three groups during the outage
There are conversations with an existing record, attempted submissions that may have failed, and visitors who left no contact details. The first group can be reviewed and resumed. The second requires evidence from website logs or available events before being counted as received inquiries. The third must not be turned into imaginary leads.
Record the start time, affected pages, last confirmed message, and whether a contact form or alternative channel remained available. Never tell a customer “we received your request” unless you have evidence of receipt.
Offer a fallback without promising automatic transfer
If WhatsApp is working, place a clear notice on the affected page or another visible part of the website explaining that chat is temporarily unavailable and inviting visitors to start a new WhatsApp conversation. Do not claim the previous chat history will follow automatically unless that exact behavior has been tested.
When a customer arrives through the fallback, collect only what is needed to resume the task: the service they wanted, what they attempted to submit, and an existing order reference if available. If you have a reliable earlier record, verify identity before using it. Similar names are not sufficient grounds to merge records.
What counts as recovery?
A restored widget is not enough. Test a new outbound inquiry, confirm that it reaches the correct inbox with the right timestamp, and check that a team member can take ownership. Then review conversations that were open during the outage and identify those needing human follow-up.
Atlassian's incident communication playbook recommends keeping an incident timeline, assigning a communications owner, and reviewing gaps between customer updates. It is general operational guidance, not a technical guarantee that missing webchat messages can be recovered.
Measure the real impact
Track how long message submission was unavailable, how many confirmed conversations stalled, how many were continued through another channel, and the time to the first useful response after recovery. If failed submission attempts were not measured, mark the count as unknown rather than inventing a lost-lead estimate.
Illustrative scenario: A services company loses website chat for two hours while WhatsApp remains available. The team publishes a fallback notice, reviews confirmed records, and tests delivery of a new chat after the fix. It does not follow up with anonymous visitors or claim that unsaved messages were restored.
What Mr. AI does and does not establish
The current Mr. AI product information confirms support for WhatsApp, Messenger and website chat, along with knowledge-based replies, follow-up and conversation summaries. It does not establish automatic failover or guaranteed recovery of every missing message. Test the behavior of your own channel configuration before depending on it.
For the related issue of losing context across channels, read the Conversation Context guide. The next useful step is a controlled outage drill in a test environment, documenting where confirmed records end and assumptions begin.
