Project 08 / Demonstration build
A support inbox that answers what it knows and hands off what it doesn't
Customer questions are answered from a knowledge base in seconds, emergencies bypass the AI entirely, and anything unknown goes to a person whose answer becomes the next rule.
Category: Customer support · Designed outcomes, not measured client results.
Who this is for
Any business with an inbox or phone number that gets the same twenty questions plus a long tail of one-offs: home services, short-term rental hosts, clinics, small SaaS support.
The problem
In my own words
“Customers email the same questions all day. Hours, service area, whether we work on their brand, what a service call costs. Someone has to answer each one, and when they are on a job the customer waits an hour. A chatbot was tried and it made up a price the business does not charge.”
- Customer emails a question
- Answered from the knowledge base, or handed to a person
- The person's answer becomes a rule, so the next customer is answered instantly
Designed outcome
Routine questions get a correct answer in seconds. Emergencies and unknowns get a human. The system never makes an answer up.
What the workflow does
- Customer emails arrive in the CRM's inbox and leave the CRM through a webhook. The conversation is logged as pending a human reply before anything else happens.
- A keyword check runs first. No heat, no cooling, gas, smoke, a leak: the customer gets an immediate acknowledgement, the owner gets an alert, and no AI step touches the message.
- Everything else is classified into a category. The matching rules are pulled from a knowledge base held in Zapier Tables, in two tiers: global rules that apply to every customer, and the record for this customer.
- Claude answers using only the retrieved rules and that customer's record. If the answer is not in that context, it escalates rather than guessing.
- Escalations and step failures land in the same place. The customer is told a person will reply shortly, and the question appears on a queue page.
- The owner types an answer there. It goes to the customer, and if they mark it reusable it is stripped of anything customer-specific, rewritten as a general rule, and added to the knowledge base. The next customer who asks is answered from it.
How the two lookup tiers work
Global rules are looked up by category, not by keyword, so a rule written once covers every phrasing of the question. Customer data is looked up by phone number, and only that customer's row is ever passed to the model. A number that is not on file gets the global tier only, and any question that needs a record, such as when an appointment is scheduled, escalates rather than being answered from someone else's row.
Refusing is the feature
The model is instructed to answer only from what it was given, and to escalate whenever it is not certain. An escalation costs the business two minutes. A wrong answer costs a customer. The parsing step that reads the model's response resolves every failure to an escalation as well, so a malformed response or an empty answer becomes a handoff rather than a broken reply.
Questions that ask for a discount, a commitment, or a price that is not in the rules escalate by design, as does anything describing a safety problem.
Handover boundary
New rules go live immediately but unreviewed, and the owner can deactivate one in a click. Keeping them inactive until a person reviews them is safer for a business answering legal or medical questions, and is a single setting.
The knowledge base is a table the owner edits directly. Nothing about maintaining the answers requires coming back to me.
Failure handling
When it breaks
A customer asks a plausible question the knowledge base does not cover.
The model returns an escalation rather than a guess. The customer gets a holding message and the question appears on the owner's queue page.
The AI step fails on a bad key, a timeout, or a provider outage.
A second automation catches the error, sends the holding message, and alerts the owner. The conversation row is created as pending before any work starts, so a dead step still leaves a record saying a person owes a reply.
An emergency is phrased as a routine question, such as asking the rate for a gas smell call.
A keyword check runs before the model, so the message takes the emergency path. No AI step is involved.