What should an AI voice intake refuse to promise?
Format: Article.
An AI voice intake should not make a promise it cannot verify or lacks permission to make. Both checks must pass. This applies to prices, arrival times, refunds, service coverage, and technical advice. It can still record what the caller wants and show staff which decision needs their review.
Make the limit clear. “Do not make promises” still leaves room for lines like “we can take care of that.” The table below pairs each risky promise with wording your team can review and approve. It also shows when to involve staff. This is a proposed design, not a verified Core Agentic calling feature.
Put the boundary in business terms
Begin with the promises your company makes today. Who may quote a price? Who may commit a crew? Who may waive a fee? Which facts must they check first? Use those answers to define the intake's scope.
NIST's AI RMF Playbook is a guide for teams that choose to use it. It covers Govern, Map, Measure, and Manage.[5] The table here is not a NIST rule or a legal standard. Use it to turn your own approval policy into clear lines the intake may say and tests it must pass.
Do not give the intake a broad instruction to satisfy the caller at all costs. The safer goal is a clear, accurate next step. A polite refusal with a useful handoff is better than a reassuring statement the company cannot honor.
A promise boundary table
| Requested promise | What must stay with authorized staff | Proposed alternative wording | Escalation trigger |
|---|---|---|---|
| Binding price | Scope, current rates, exceptions, and approval | I can pass your pricing question to the team. No price is confirmed here. | Caller needs a binding quote or disputes a prior amount. |
| Crew arrival | Capacity, travel, job readiness, and dispatch decision | I can note your preferred time. An arrival time is not confirmed. | Caller relies on a specific arrival or reports a missed commitment. |
| Refund or fee waiver | Policy review and financial authority | I can record the request for review. I cannot approve the refund. | Disputed charge or request outside the standard policy. |
| Technical diagnosis | Qualified inspection and professional judgment | I can capture what you observed for qualified staff. | Caller asks what is wrong or whether equipment is safe. |
| Service coverage | Current branch rules and capacity | The team needs to confirm whether it can take this request. | Address or service falls outside verified scope. |
| Guaranteed callback time | Staff coverage and approved response commitment | I can request a callback, but cannot confirm a time. | Caller requires an immediate response. |
Review each line with the staff who would get the case. Careful wording is not much help if no one owns the next step. Name the reviewer in the handoff. Keep the case open until that person has made the required decision.
Watch the soft promises too
An intake can cross the line without saying “guaranteed.” “That should be covered,” “you are all set,” and “we will get someone out” can create expectations. Decide which phrases are disallowed in the scoped workflow, and test them with indirect pressure from callers.
Also test requests that refer to past dealings. “You waived it last time” is a caller statement, not current approval. The intake may preserve that context for staff. It should not turn it into a rule for the next transaction.
Keep acknowledgments narrow. “I understand you want the fee reviewed” acknowledges the request. “I understand the fee was wrong” adopts a conclusion the intake has not established.
Rehearse a caller who wants certainty
In this hypothetical proposed design, a caller asks, “If I give you the address, can you promise someone will be there tomorrow?” The intake replies, “I can record your request for tomorrow. The service team must confirm availability before any visit is booked.”
The caller pushes: “Just tell me it is likely.” The intake should not guess the odds. It should say that it lacks the facts to give an estimate. Then it should offer the approved way to reach a person.
The review card reads: “Caller requests tomorrow and needs a firm answer before proceeding. No arrival or availability commitment made. Service coordinator to review.” If the caller declines that next step, the record should show the declined option rather than a booked job.
Prove the boundary in the final record
Test both speech and stored notes. A careful answer is not enough if the customer record says “confirmed for tomorrow.” Check the fields, notes, and draft messages staff may reuse. None should promise more than the intake was allowed to say.
Decide what happens when a policy is missing or out of date. The intake should not fill the gap from memory or a broad website claim. Leave the decision with the person in charge. Have qualified staff review sensitive, safety, and legal questions before use.
Book a Demo with Core Agentic to discuss a custom intake design with explicit promise limits and useful human handoffs.
Sources
- NIST: NIST AI RMF Playbook | NIST.
These sources describe the named provider or framework. They do not establish a Core Agentic integration, customer result or certification.