Customer enquiries
Answer the customer with what the system actually knows.
How an agentic application answers customer enquiries from live records, availability and account state instead of from a generic knowledge base, and where a person still has to decide.
Direct answer
Can software actually do this?
Most customer questions are about their situation, not about your policies: what is available, when it arrives, what they owe, what was agreed. An agentic application answers those by reading live records under the customer own permissions, rather than retrieving a document that describes how things usually work. Anything that commits the business remains a proposal for a person.
How it gets asked
The request, in the words people already use.
These are not prompts to be learned. They are the sentences a manager says to a colleague, which is the standard an agentic application should meet.
- “Do you have a unit like the one I have now, at the Riverside site?”
- “When is my order arriving, and why has it moved?”
- “What am I paying for, and what would it cost to change it?”
- “Can I cancel, and what happens to my deposit?”
- “I sent an email last week and nobody has replied. What is happening?”
Where this comes up
The current situation
The chatbot knows the policy. The customer is asking about their account.
A retrieval chatbot trained on your website can explain the notice period. It cannot say whether this customer is inside it. So the conversation ends with a promise that someone will check, which is exactly the work the chatbot was bought to remove. The information needed is in the operational systems, behind a permission boundary that generic tools were never designed to respect.
- Simple account questions still consume staff time.
- Customers repeat the question through a second channel, doubling the work.
- Answers vary depending on who happens to reply.
- Availability and pricing questions get answered from memory, then corrected.
- The support inbox hides operational problems inside individual threads.
What the answer depends on
The application has to read all of this, not one system.
The reason this work stays manual is rarely difficulty. It is that the answer lives in several places and only a person currently holds them together.
Verified identity
Who the customer is, proven by the channel or an authentication step, before anything specific to their account is read.
Their account state
Agreements, orders, bookings, balances and open work belonging to that customer and nobody else.
Live operational data
Availability, stock, capacity, schedules and lead times as they are now, not as a page described them last quarter.
Policy and terms
Notice periods, charges, guarantees and the rules that decide what is actually possible.
Conversation history
What this customer has already asked and been told, so the answer continues the conversation.
What the application does
The job, step by step.
Each step is either ordinary application code or a bounded piece of reasoning. Knowing which is which is the difference between a system you can operate and a demonstration.
Establish identity first
Nothing account-specific is read until the customer is identified to the standard the business requires for that channel.
Classify what is being asked
A general question, an account question, a request to change something, or a complaint. These have different answers and different authority.
Read only that customer data
Scope is applied by the application. The agent receives context for one customer and cannot reach beyond it.
Check live state, not documentation
Availability, dates and balances come from the operational systems at the moment of asking.
Answer with the specifics
The reply states the actual dates, amounts and options for this customer, and says where the figure came from.
Separate answering from committing
Explaining a cancellation charge is an answer. Cancelling is an action, and it follows the authority the business has set for it.
Hand over cleanly
When the answer is not available, or the question is a complaint, the conversation moves to a person with the context already assembled.
Record what was said
The exchange is written to the customer record so the next person, or the next conversation, continues from the same place.
Worked example
What a useful answer actually looks like.
A customer asks: I need something bigger than my current unit, at Riverside, from the start of next month. What can I do and what will it cost?
An invented exchange, written to show which parts of an answer come from live systems and which parts a person still has to decide.
| Part of the answer | What the application does | Where it comes from |
|---|---|---|
| Who is asking | Confirms the customer and the single unit on their account before reading anything. | Authenticated portal session |
| What is available | Two larger unit types free at Riverside from 1 October, one from 14 October. | Live unit availability, not a website page |
| What it costs | Quotes the current rate for each type, the pro-rata adjustment for the move and the deposit difference. | Pricing rules in application code |
| What their agreement allows | Confirms an in-site move needs seven days notice, which this request satisfies. | Agreement terms and the record start date |
| What is unresolved | Their account has an £18 short payment from September that must be cleared before a move is processed. | Ledger |
| What happens next | Offers to hold a unit for 48 hours and prepares the move request. The reservation and the move are actioned by the site team. | Proposal only, routed for action |
The customer gets a real answer in one exchange instead of a promise to check. The business keeps the decisions that involve money, capacity and a contract change.
Stays in ordinary software
What must never depend on a model.
- Identity and authentication before any account data is read.
- Pricing, pro-rata calculations, deposits and charges.
- Availability, capacity and whether a unit or slot can genuinely be held.
- Notice periods, contractual terms and what the customer is entitled to.
- The record of what the customer was told.
Where reasoning earns its place
What genuinely needs judgement.
- Understanding a question that arrives in the customer own words.
- Working out which of several systems actually holds the answer.
- Noticing that an unrelated account issue blocks what the customer wants.
- Explaining the options clearly instead of quoting policy text.
- Recognising a complaint and routing it to a person early.
Control boundary
What keeps this safe to run.
Autonomy is not a setting. It is the sum of the scope, the tools and the approvals the application has been designed to enforce.
Authentication happens in the application. A customer claiming to be someone in a message is not evidence.
The context supplied to the agent is scoped so that another customer data cannot be reached at all.
Reservations, cancellations, refunds and contract changes follow the authority the business already assigns.
A person can take over at any point with the full conversation and context, not a transcript alone.
Customer text is data, never instruction. Tools are typed and authorised independently of anything a message says.
Deliberate limits
What it does not do.
- It does not read or reveal another customer records, ever.
- It does not agree discounts, waive charges or vary the terms.
- It does not confirm a booking, cancellation or refund on its own in an early release.
- It does not guess at availability or a price when the system is unavailable.
- It does not argue with a complaint. It routes it.
How you know it works
The evidence to require.
- Answer accuracy is sampled against what a trained colleague would have said.
- Every escalation is reviewed for whether it was handled correctly.
- Attempts to reach other customer data are tested deliberately and must fail.
- Prompt-injection attempts are part of the test set, not an afterthought.
- Resolution rate and repeat-contact rate are measured against the previous baseline.
A sensible first release
Narrow enough to trust, complete enough to be useful.
The first version should be able to fail without costing anything, while still producing an answer somebody would miss if it disappeared.
One authenticated channel, one narrow question set, read-only answers.
A clear, always-available route to a person.
Answers cite their source so support can verify quickly.
A review of every conversation for the first weeks, then sampling.
Actions such as holds or changes added one at a time, each with its own authority.
Common questions
Questions about customer enquiries.
The questions that should be settled before anyone builds this.
How is this different from the chatbot we already have?
Most website chatbots retrieve documents and describe general policy. This reads the operational systems for the identified customer and answers about their account, their availability and their dates. The engineering difference is identity, scope and typed tools, which is also why it takes more than a script tag to deploy responsibly.
Is it safe to let customers reach our systems this way?
It is safe when the application, not the model, enforces identity and scope. The agent receives context for one authenticated customer and holds tools that can only act within that scope. Treat every incoming message as untrusted data, never as instructions, and test that assumption deliberately before release.
What happens when it does not know the answer?
It says so and hands over to a person with the context already assembled. That is a good outcome, not a failure. A system that guesses at a price or a date to avoid an escalation costs far more than one that escalates a little too often in its first months.
Can it take the booking as well as answer the question?
Eventually, and one action at a time. Answering, holding and committing are different levels of authority. A reasonable path is to answer first, then allow a reversible hold, then allow the full booking once the evidence supports it. Refunds and contract changes usually stay with a person for longer.
Related use cases
How Codemind builds it
Start with the job
Bring the request, the systems and the person who does it today.
You do not need a specification. We will separate what belongs in ordinary software from what genuinely needs reasoning, and describe a first release that can prove itself.