A customer question belongs to a bot only when its answer is already fixed by a record field or by a rule the software itself holds; a judgement stays with a person. The tier follows from how the records are split and from where that rule lives. In Pilatesco a rule decides whether a cancelled credit returns; in the earlier arrangement that answer came from whoever replied that day.
The distinction matters commercially, because the two ways of failing are not alike. Where the record is missing, anything placed in front of it stays silent; there is nothing to read. Where the rule is missing, silence is not what you get. There is still a source available, the history of past conversations, and what comes out of it is not the policy of the business but the way one person handled the case that day.
That makes this a diagnosis rather than a product choice. Sort the questions you answer most often into tiers and you can see which of them already has an answer waiting to be read, and which one needs work in the system first. The sections below use four jobs from our portfolio as evidence. None of the four has a bot in it; each of them shows where the answer to a customer question actually sits.
Is the answer a record, a rule or a judgement
The topic of a question decides very little. A price question does not always belong to a person, and a status question does not always belong to a machine. What decides is where the answer comes from: a field in a record, a rule the business has written down, or the judgement of a person.
We have written before that a step whose output is read from a record can be handed to the buyer, while a step that turns on a site visit or a signature hands over only the request; that test stands here unchanged. We also described why one product can carry a gated path and an ungated path side by side in the article on human oversight.
What this article adds is the tier between those two. Some answers come from neither a field nor a signature. They come from a rule the business made for itself, and that rule sits either in the software or in a person. Where it sits decides whether a bot can read it.
Three tests separate the tiers. Is the field that holds the answer filled? Is the rule that produces it defined in the system? Does the answer need a signature behind it? A question that answers yes to either of the first two can be read; a question that answers yes to the third cannot.
A bot has to tie the question to a record before it can answer
When your customer writes “when is my service coming”, there is no answer on the table yet. There is a question. Where the answer will be read from depends on the record the question gets tied to, and that tie is made before any reading happens.
On Diotek’s site the two requests that come in are tied to two different things: a survey appointment centres on the space, a service request centres on the installed device. Two status questions worded the same way can therefore draw on different sources, and which one applies is not visible in the wording. It becomes visible in the record the question was tied to. We wrote about why a survey and a repair never share a form in the article on separating appointments and service requests; what matters here is only what each request attaches to.
AlgoKlima’s service management keeps warranty, maintenance and fault records under the device rather than on the customer card. Where one address holds several devices, the customer card on its own does not answer “when was this unit last serviced”. The question is tied to a device first, and the record is read second. This is not a property of a bot; it follows from the data model, and the order stays the same whatever is placed in front of the record. We described how history travels with the device in the article on offline field apps; the point here is only that the tie runs through the device. AlgoKlima is our own product: we run it, and we are still building on it.
How the tie closes depends on what the record hangs off. If your customer says which record they mean, the question ties in one step. If they do not, one route remains: the system pulls the options from the records attached to that customer and asks. That second route only exists if those records hang off the customer. Where a device record is not attached to a customer, there is no list to pull.
A question that cannot be tied has no answer, only a question. When your customer names neither the device nor the appointment, the field to read is undetermined. The output with the right source there is not an answer but the question that completes the tie: which device, which date. A bot placed in front of a record that skips that step has picked one of the records itself and will not tell you which. The answer looks right and belongs to the wrong device.
The step is invisible in small books of business. A customer with one device and one open request ties the question by default, because there is only one candidate. Binding becomes work when several devices or several open requests sit under the same customer card, and it becomes the thing that decides whether an answer is correct as the book grows.
Is the rule in the software or in someone’s head
In Pilatesco’s booking software, the answer to “I cancelled, did my credit come back” is not read from a single field. It comes out of two things together: the package balance sitting on the customer record, and the rule that treats a cancellation, a no-show and an attended class differently. A reservation written into the calendar takes one credit off the package, and which case returns the credit is set in the rule rather than settled in conversation. The balance sits on the customer record instead of a separate ledger, so reading it does not require asking anyone.
One short test separates this tier from the record tier: is the field filled and the answer still missing? In Pilatesco’s earlier arrangement the reservation was written in the calendar and the cancellation had been made, so the fields were filled. The answer to “did my credit come back” was still in neither the calendar nor the balance. The remaining credits were kept in a ledger outside the calendar, and what a cancellation did to them lived in message threads. The source of the answer was not a field. It was how the person replying that day applied the rule. Writing the rule into the system moved the source from a person to a record.
This is where the article carries its weight. While a rule is not in the system, the only source a bot can be given is the history of past messages, and messages carry replies rather than rules. What comes out of them is not your policy but one person’s handling of the case on one day. A missing record produces silence. A missing rule produces an answer with the wrong source. The second is harder to catch, because from the outside the system looks like it is working: the question was answered, and where the answer came from is not on the screen.
AlgoKlima’s “is my unit still under warranty” does not fall into this tier. The warranty record sits under the device, so once the question is tied to a device the answer is read straight from a field. As a sentence it is the same kind of status question as “I cancelled, did my credit come back”. The tier is different. What separates them is the place the answer comes from.
There is a practical way to find out where a rule lives. Instead of asking the person who applies it, look at the screen where it gets applied. When the cancel button is pressed, does the package balance settle in the system, or does someone have to correct the balance by hand? If a hand correction is needed, the rule is not in the system; it is in the person making the correction. That diagnosis comes before any decision about a bot and is worth making whether or not a bot follows.
A rule has limits of its own. “Can you give my credit back just this once” is a request to step outside the cases the rule defines; a written rule does not answer it, and the question drops to the next tier. The second limit is about upkeep. If a rule changes often and nobody carries the change into the system, the written rule falls behind the one in the ledger and the source quietly returns to a person. Writing a rule is not a one-off job; a rule without an owner goes stale.
Where a question needs a judgement, a bot opens the right request instead of answering
On Diotek’s site no quote is given before the space has been seen, because the capacity of a unit depends on the space. “Which unit fits this room, and what will it cost” is answered neither by a field nor by a rule. It is settled at the survey. That is where the gate stands: the moment the source of an answer turns from a record or a rule into a judgement, reading stops.
What gets produced after the gate is the real subject. “We will call you back” is not an output; it is an output postponed. On Diotek’s site a visitor asks for a date for the space before choosing any unit, and that request is recorded as a survey appointment request; it reaches operations in its own flow without mixing into the post-installation service queue. A bot placed in front of a flow like that does not produce an answer. It opens that record. Because request entry is not tied to the phone line, a request that arrives while the line is busy or outside office hours is still written down.
What the request record carries is equally definite. It carries the type it was opened under, the space or device it concerns, and the time the request arrived. Without those three it is a message, and a message waits for a person to read it in operations. The value of a bot at the gate is not in answering; it is in handing over a complete piece of work to the person who takes it.
We described what remains once an output that needs a signature is handed to a screen in the article on pre-sale self-service steps. The difference here is that a bot does not produce that output at all; the one thing it does is open the request.
In Tahlil.com’s physician panel the preliminary reading goes to the physician, not to the patient. A model prepares a draft, the physician writes and approves the interpretation in the panel, and the final version of the text the patient receives comes from the physician. At the decision tier a bot’s output goes to whoever signs. We wrote about where the approval gate sits in the flow and why the notification is triggered by approval in the article on human oversight; the only point here is who the draft goes to.
The question of a wrong answer splits along the same tiers. At the record tier a wrong answer is a wrong record: the bot showed what the record held, and the record is what gets corrected. At the rule tier it is a rule written incompletely or written wrong; correct the rule and the answer to the same question changes with it. At the decision tier the bot should not have answered at all, and the answer belongs to the person who closes the request. In Tahlil.com every interpretation that reaches a patient stays the responsibility of the physician who approved it. Knowing the tier tells you where to look when something goes wrong.
The gate does not stop the whole question. Part of a question that carries a judgement can still be read from a record: “when is my survey appointment” drops back to the record tier once the request has been opened. What stops at the gate is the part carrying the judgement, not the question itself.
Where each question gets answered
The table below adds no new facts. It puts the mechanisms of the earlier sections side by side through the question types of four jobs. Read the third column conditionally: none of the four has a bot in it, and the column says what a bot could read if one were placed in front of that source. No row describes a product; each row says where the answer in that job actually sits.
| The customer’s question | Where the answer comes from, and its tier | What a bot placed in front could do | What stays with a person |
|---|---|---|---|
| When was this unit last serviced, and is it under warranty | Record: warranty, maintenance and fault records sit under the device (AlgoKlima) | Ties the question to the device record first, then reads it; asks which device is meant where one address holds several | The technician opens the record in the field; with no record opened there is nothing to read |
| I cancelled, did my class credit come back | Rule and record together: the package balance on the customer record, and the rule separating cancellation, no-show and attendance (Pilatesco) | Reads the balance where the rule is defined in the system; where it is not, there is no source to read | Writes the rule once; turns a request to step outside it into a decision |
| Which unit fits this room, and what will it cost | Judgement (the space): unit capacity depends on the space, and no quote is given before the site is seen (Diotek) | Does not answer; opens a survey appointment request that lands in its own flow rather than the service queue | Sees the space, sets the capacity, gives the quote |
| What does this test value mean for me | Judgement (a signature): the last word on an interpretation reaching a patient stays with the physician (Tahlil.com) | Does not answer the patient; drops the preliminary reading as a draft into the physician panel | The physician edits and approves the draft in the panel; the final version reaching the patient comes from the physician |
The first two rows read alike as sentences and land in different tiers. Length, politeness and topic do not make that difference; where the answer sits does. The last two rows share a tier for different reasons: in one the judgement is made at the site, in the other at the signature.
Before adding a bot, is the source of the answer ready
A bot does not produce an answer; it reads a source that already exists. The order cannot be reversed: the source first, the reader second.
In Pilatesco the work that had to happen before any bot could exist was moving the rule into the software. The remaining credits moved from a ledger onto the customer record, and what a cancellation does moved from message threads into a rule. What was decided while writing that rule was what a cancellation, a no-show and an attended class each do to the balance; defining those three cases separately was the work. Until that was done, nothing placed in front could read “did my credit come back”, because there was nowhere to read it from.
In Diotek the work was splitting request types into separate records; survey appointments and service requests were built as two separate flows from the start. At the decision tier, the type of request a bot would open exists only if those types sit apart in the record. Without a type what remains is free text, and free text gets sorted out by phone in operations anyway. The type of a request record decides which queue it falls into and who sees it; a record without a type belongs to nobody.
A third case is more basic: the question has no counterpart in the records at all. We set that diagnosis out in four patterns in the article on where an unanswered customer question goes; the only thing added here is what the diagnosis does to a bot. A question with no counterpart leaves a bot silent, and silence does not look like a fault, which is why nobody goes and looks at where the record is kept.
When a bot cannot answer, the gap is in one of three places and each has a different fix. Where the question has no counterpart in the records, the record model is what gets fixed. Where the rule lives in a ledger or in message threads, the rule has to be written. Where the question carries a judgement, the request type the bot would open has to be defined. In all three the thing being fixed is the source, not the bot.
Order matters too. A rule written before the record model is fixed hangs in the air, because it has no field to read. A record opened before request types are defined falls into no queue and enters nobody’s work; where the approval gate and the request type belong in the flow is a question our AI consulting works through alongside the records themselves. The field that holds the answer comes first, then the rule that interprets that field, and last the request type for questions carrying a judgement. That order is set by the records.
Even with the source ready, a bot may not be what you need. Where the source of an answer is a field, a chat surface is not the only way to show that field to a customer; a bot is one of several ways of reading a source. Not every question with a source needs a bot, and no question without one is solved by adding a bot.
Take the questions you answer most often and ask where each answer actually lives: in a field, in a written rule, or in someone’s head. Our CRM work is where the structures that tie a request to a customer, an installed device or a rule get put in place.
