Write the Fallback First: What Your Bot Does When It Does Not Know

I work at NxFlowAI and build automations for owner-run shops and clinics. This is a practitioner note, not a pitch.

When I scope a small-business assistant, the first thing I ask is not "what should it answer?" but "what does it do when it cannot answer?" The fallback is where trust is won or lost, and it is the part most demos skip.

Why fallback comes first

Owners judge an assistant by its worst reply. One confident wrong answer about a delivery date outweighs fifty correct hours. If you design the fallback first, every other behaviour has a safe floor.

The fallback has three jobs

1. Say something honest. "I will check with the team and come back to you" beats a guess.
2. Hand off with context. The human should see the original message, the detected intent, and what the bot already said.
3. Keep the customer informed. Tell them when a person is likely to reply, using the owner's real working hours.

A small decision table

I keep this in a sheet before touching any code:

intent            confidence   action
hours/location    any          auto-reply from approved text
order status      high         auto-reply from order lookup
order status      low          ask for order number, then retry once
price / discount  any          draft + owner approval
complaint         any          immediate handoff + holding reply
unknown           any          holding reply + handoff

The rule behind it is simple: the cost of a wrong answer decides how much autonomy the bot gets, not how clever the model is.

Details that bite in production

• Out-of-hours handoffs. If nobody is online, the holding message must say so. A promise of "a reply shortly" at 2 am is a broken promise.
• Loops. Cap clarification attempts. After one failed retry, escalate instead of asking again.
• Language mixing. Customers switch between languages mid-sentence. If detection fails, treat it as low confidence rather than guessing.
• Silent failures. If the handoff notification fails, you have a customer waiting in an unmonitored queue. Alert on that.

Testing the fallback

Collect real messages that the bot should not answer: angry ones, vague ones, off-topic ones. Run them after every change and check that each one lands in the handoff with context attached.

Where this fits

The fallback table is the output of the workflow mapping step, which is why we start there. If you are scoping something similar, auditing the workflow before adding AI is a useful first pass: it forces you to list who owns each exception.

What does your bot do when it is out of its depth? I would like to hear patterns that worked for you.