What to do when the messaging system fails: contingency plan for the team
When the messaging inbox stops working, the problem is not just technical: it is operational. Messages keep coming in —or they should— and the team does not know whether the silence is because there are no customers or because the system is down. This protocol sets out what to check first, which alternative channel to activate and who to notify, without depending on a specific tool.
First: tell an outage apart from normal silence
Most false positives come from confusing an outage with a moment of low demand. Before escalating, compare current activity against the business's own baseline. You do not need a dashboard: it is enough to know how many messages come in during a typical hour at that same time of day.
| Signal you see | What it may mean | What to do in the next 5 minutes |
|---|---|---|
| Zero new messages in the inbox during a time slot that normally has activity | Channel or provider outage | Check the channel status and try sending a test message from an external number |
| Messages come in but cannot be answered | Write or session failure | Try replying from another agent and from another device |
| AI suggestions do not appear but messages do | Partial failure of the suggestions module | Reply manually: the conversation is not blocked |
| Messages come in with a delay of several minutes | Channel latency, not an outage | Note the time and continue; if it exceeds 15 minutes, escalate |
| The history looks incomplete or out of order | Partial synchronization | Do not delete anything; take a screenshot and notify before retrying |
| A single agent sees nothing, the rest do | Session problem for that user | Have them log out and log back in; if it persists, escalate |
| No one can log in to the platform | General provider outage | Activate the alternative channel now, without waiting for a diagnosis |
| The customer says they received a duplicate message | Automatic retry or double send | Do not resend; log the case and notify the person responsible |
The alternative channel: define it beforehand, not during the outage
The most common mistake is improvising the alternative channel at the moment of the outage. If the business only serves customers through WhatsApp, when WhatsApp fails there is no plan B. The alternative channel has to be defined, communicated to the team and tested at least once a quarter. It does not matter which one it is: what matters is that it exists and that everyone knows where it is.
| Alternative channel | When to use it | What needs to be ready in advance | Risk if it is not prepared |
|---|---|---|---|
| Landline or on-call mobile phone | Total inbox outage | Published number and a person responsible assigned per time slot | Customers do not know another number exists |
| Customer service email | Long outages or inquiries that require attachments | Monitored inbox and automatic reply configured | Emails pile up without anyone seeing them |
| Instagram or Messenger | If the business already has those channels active | Profile with team access and notifications enabled | Conversations get duplicated across channels |
| Web form | Extended outages or outside business hours | Form that notifies the person responsible by email | Submissions land in an inbox no one checks |
| Notice in the store or on the website | Outage that affects many customers | Text drafted and ready to publish | Customers keep writing to the down channel |
Who to notify and in what order
The notice must follow a fixed order so that two people don't overlap doing the same thing and no one is left uninformed. The rule is simple: first the person who handles it, then the person who coordinates, then the person who resolves it, and finally the client. If the order is reversed, the client finds out before the team does and the outage turns into a crisis.
- 1The agent who detects the failure notifies the on-duty coordinator through whatever internal channel they have (internal messaging group, call, whatever they use). They don't wait until the end of the shift.
- 2The coordinator confirms whether it's a general failure or one affecting a single user, and decides whether to activate the alternative channel.
- 3If it's general, the coordinator notifies the technical lead or the provider, with the exact time, what is being seen and since when.
- 4The technical lead communicates an estimated status: not a guaranteed timeline, but whether it's in diagnosis, in repair, or no information.
- 5Only once the alternative channel is active do they notify the clients who wrote during the outage, one by one or with a general message if the channel allows it.
- 6When the outage is closed, the coordinator records what happened, how long it lasted and how many messages were left unanswered.
Don't promise resolution times to the client or the team. Times depend on the provider and the channel. What you can promise is that someone is working on it and that messages will be answered when the channel comes back.
Decision matrix: do I escalate or wait?
Not every failure deserves the same reaction. This matrix sorts by duration and impact. Duration is measured from the first message that couldn't be answered or from the first visible symptom, not from when someone noticed it.
| Duration of the failure | Impact on service | Action | Who decides |
|---|---|---|---|
| Less than 5 minutes | Low: few unanswered messages | Record and monitor. Do not activate the alternative channel. | The agent |
| Between 5 and 15 minutes | Medium: queries pile up | Notify the coordinator. Prepare the alternative channel without activating it. | The coordinator |
| Between 15 and 60 minutes | High: there are clients waiting | Activate the alternative channel and notify the clients who wrote. | The coordinator |
| More than 60 minutes | Critical: sales or appointments are lost | Alternative channel active, notice to the provider and public communication if applicable. | The lead |
| Intermittent failure during the day | Medium but sustained | Record each episode with time. Escalate to the provider with the full pattern. | The coordinator |
| Failure affecting only one agent | Low for the team, high for that agent | Resolve session or device. If not resolved within 15 minutes, escalate. | The agent |
What to record during the outage (and why it matters later)
Recording during the outage is what later allows you to claim from the provider, explain to a client why they weren't answered, or adjust the protocol. Without a record, the outage becomes an anecdote and happens the same way again next time.
- Exact time of the first symptom and time it was detected (they are not the same).
- What was visible: blank screen, error, messages not arriving, replies not going out.
- How many agents were affected and how many customers were left without a response.
- Which alternative channel was activated and at what time.
- Who was notified and at what time.
- Time of restoration and whether there were lost or duplicated messages.
- Screenshots: they are the simplest proof and the one most often forgotten.
Checklist to tick off before the next outage
This checklist is completed calmly, on a normal day, not during the outage. If any box is left unchecked, the plan has a hole.
- There is a defined alternative channel and the team knows which one it is.
- There is a person responsible per time slot to monitor that channel.
- There is an internal group or channel where the outage is reported.
- It is clear who notifies the provider and with what data.
- There is a drafted message to communicate the outage to customers.
- It is known how to export or log the conversations that were left unanswered.
- Someone reviews, after each outage, whether the protocol worked.
- The protocol was tested at least once in the last quarter.
Frequent mistakes that make the outage worse
- Restarting everything without logging what was visible: evidence and diagnosis are lost.
- Activating the alternative channel without notifying the team: two people answer the same thing through different channels.
- Promising the customer a resolution time that does not depend on the business.
- Continuing to reply through the downed channel without knowing whether messages are going out.
- Not notifying the provider until the next day: context and the time of the first symptom are lost.
- Considering the outage closed without checking whether there were conversations left unanswered.
- Not writing anything down because 'it was just a little while': short repeated failures are the hardest pattern to diagnose.
How this connects to the tool you use
This protocol works with any messaging inbox, including Wando's, which uses Meta's official WhatsApp API. The advantage of a tool with AI suggestions approved by the team is that, when the channel comes back, accumulated conversations can be resumed with context: the AI proposes and the agent approves. But no tool replaces having the alternative channel defined and the team trained. Contingency is a process, not a feature.
Frequently asked questions
Answers to the most common questions about the contingency plan.
Failures that aren't yours: distinguish provider, channel and device
Not every failure is resolved the same way. Before escalating, identify which layer the problem is in: whether it's the inbox provider, the channel (WhatsApp, Instagram, Messenger) or your own equipment. The response changes depending on which one it is.
| Layer where it fails | How it's recognized | Who resolves it | What the team can do in the meantime |
|---|---|---|---|
| Inbox provider | No one can get in, neither from the phone nor from the computer | The provider | Activate an alternative channel and log everything |
| Channel (WhatsApp, Instagram, Messenger) | The inbox works but messages don't come in or go out | Meta | Wait and communicate; there's no local action possible |
| Device or session of one agent | Only that person can't see or can't reply | The agent themselves or the coordinator | Log out, try another device |
| Network or internet at the location | It only fails at one location, the rest works | The business | Try with mobile data before escalating |
What to say to the customer who wrote during the outage
The recovery message isn't a long apology: it's a short, concrete notice without technical excuses. It has to acknowledge the delay, not promise compensations you haven't decided on, and bring the conversation back to the official channel.
| Situation | What to include in the message | What NOT to include |
|---|---|---|
| Simple inquiry without a reply | Brief apology + answer to the original inquiry | Technical details about the provider |
| Appointment or order that was lost | Apology + options to reschedule | Promise of an unauthorized discount |
| Customer who wrote through the alternative channel | Thank them + ask them to continue through the official channel | Ask them to repeat everything from scratch |
| Customer who complained publicly | Brief public reply + private contact | Discuss the reason for the outage in public |
How to measure whether the protocol worked
- Time between the first symptom and the first internal alert.
- Time between the alert and the activation of the alternative channel.
- Number of conversations recovered versus those that went unanswered.
- Number of customers who complained through a second channel before the official alert.
Frequently asked questions
How long should an outage last before activating the alternative channel?+
There is no universal number. The reference on this page is to activate it when the outage exceeds 15 minutes or when there are customers waiting for a reply. Each business adjusts the threshold based on its volume and its tolerance.
Who do I notify first when messaging fails?+
First the shift coordinator, then the technical lead or the provider, and only once the alternative channel is active, the customers. If the order is reversed, the customer finds out before the team.
Which alternative channel should I have ready?+
One or two at most: an on-call phone, a support email, Instagram or Messenger if they are already active, or a web form. The important thing is that it is defined before the outage and that someone monitors it.
How do I know if it is an outage or simply no messages?+
By comparing against the business's own baseline: if messages normally come in at that same time and none arrive, that is a signal. Sending a test message from an external number also helps.
What data should I record during the outage?+
Time of the first symptom, time it was detected, what was visible, how many agents and customers were affected, which alternative channel was activated, who was notified and the restoration time. Screenshots are the simplest proof.
Can I promise the customer a resolution time?+
It is not advisable. Resolution times depend on the provider and the channel. What you can communicate is that the team is aware and that messages will be answered when the channel is back.
How often should the contingency plan be tested?+
One test per quarter is a reasonable reference. The test consists of reviewing the checklist in a calm moment and confirming that the alternative channel is still active and that the team knows how to use it.
What if the outage happens outside business hours?+
The protocol is activated the same way, but the alternative channel can be just an automatic message saying that replies will resume when you open. The important thing is that the customer gets a signal that the business exists and will answer.
How many people need to know the protocol?+
Everyone who handles customer service, even occasionally. A protocol that only the coordinator knows falls apart when the coordinator is not there.
Is it worth having a second messaging provider as a backup?+
It sounds good in theory, but keeping two inboxes active doubles the work and confuses customers. It is more realistic to have a simple alternative channel (phone, email) than a second full system.
What do I do if the customer insists on a reply through the down channel?+
Explain once that the channel is having problems and offer the alternative. If they insist, reply when the channel is back and log the case. Do not promise that the message will go through if you cannot confirm it.
Answer WhatsApp with AI
Try Wando free. No credit card required.