Vora
Find a recurring job the buyer can show you
Ask the owner to walk through a recent after-hours enquiry using redacted or synthetic details. Where did the caller leave a message? Who listened to it? What did staff need before calling back? Did the request ever reach the right person?
You are looking for a process with an identifiable start, an observable finish and someone who cares about the gap between them. In this example, the start is an incoming call. The finish is a usable callback request in the office queue.
The buyer should also be able to explain why the work matters. Perhaps staff spend the morning replaying messages to find phone numbers. Perhaps requests for a different service area reach the wrong person. These are hypotheses to inspect with the business. They aren't evidence that an AI service will produce more revenue.
If the owner cannot show the current process, discovery is the next paid or unpaid activity to agree on. Building a demo before understanding where the record must go leaves you guessing about the deliverable.
Keep the first conversation narrow enough to finish with a decision: is this one workflow worth investigating, and can the business provide the access and staff time needed to test it?
Write the offer around a saved result
A useful first offer can fit into a short description: after-hours callers can leave a structured callback request; the office receives it in its agreed queue; the caller hears that staff will confirm the next step.
The exact wording depends on the business. A company that promises a callback by a certain time needs a person and process capable of meeting that promise. The agent should not invent a response deadline because it sounds helpful.
Use a small acceptance table before choosing a platform. The example below assumes one business, one intake queue and staff review before any appointment confirmation. It is a proposed service definition, not a tested deployment.
| Part of the offer | Expected result | Where the client checks it | Boundary to agree |
|---|---|---|---|
| Contact details | Final name and callback number appear in the request | Office intake queue | How the agent handles a missing or unclear number |
| Reason for calling | A short description staff can use | Same request | Which services the agent may discuss |
| Service location | Caller-provided location is recorded accurately | Same request | Whether the business checks coverage during the call or later |
| Caller confirmation | Caller hears that a request was sent for staff review | Controlled call recording | No appointment or price promise |
| Failed submission | Staff receive the agreed exception notice | Staff exception queue | Who responds and what the caller hears |
| Corrections | Final corrected details replace the earlier details | Reopened saved request | How duplicates and partial records are handled |
This gives the owner something concrete to approve. It also gives you a way to decide whether a requested addition belongs in the offer.
After the client asks for automatic booking, the deliverable changes. You now need availability rules, accepted booking results and an honest response when the calendar is unavailable. That is a separate design and pricing decision.
Check whether you can support the dependencies
List the services the workflow depends on: the phone route, model or agent runtime, the destination queue, credentials and any notification channel. Follow one request through them.
For each dependency, find out what access you need to diagnose a failure. Can you inspect the attempted write? Can the client's staff open the saved request? Who can restore an expired connection? Which party receives a provider alert?
A low subscription cost won't help much if you cannot see why records stopped arriving. When reviewing a product such as Vora's platform, ask for evidence about the specific workflow, access and recovery behavior you intend to sell. A platform overview can begin that review; the acceptance cases still need to run against your selected setup.
Be honest about the support hours you can provide. If you work alone, promising immediate assistance every night creates an obligation that the demo hasn't solved. Choose a service boundary and fallback the business can operate when you are unavailable.
NIST's AI Risk Management Framework Core includes documenting application scope and human oversight. Those are useful questions for a first offer: what can this service do, and who handles the work beyond its limits?
Where the first offer needs deeper checking
Use the question that remains unresolved to choose the next check. You do not need to read every guide before talking to a buyer.
| Question about your first service | Guidance to use |
|---|---|
| Does the business have approved material for the agent? | knowledge-readiness review |
| What should happen when a caller asks beyond the offer? | fallback and handoff method |
| Can the agent safely answer a changing price or availability question? | current-facts review |
| What if two approved-looking documents disagree? | source-authority register |
| Will the pilot replace an existing workflow? | migration checklist |
| Can a retried request create duplicate work? | webhook retry and idempotency guide |
| Who restores a connection and resolves interrupted requests? | OAuth recovery guide |
| How will the service end without leaving access or costs behind? | offboarding checklist |
Make the demonstration prove the delivery
Use synthetic customer details and the actual route planned for the service. Call the agent, correct your callback number halfway through, then open the office queue with the buyer. Find the request together.
Check the final number, reason for calling and any location detail. Reopen the record to check that it persisted. Ask the staff member who will receive these requests whether they have enough information to continue.
Then make the destination unavailable in a controlled test environment. Listen to the agent's response and inspect the exception path. A reassuring spoken answer creates a problem if nobody receives the request.
Vora's voice agent testing guide follows this inspection method in more detail. Use the same distinction in your own demonstration: a conversation can sound complete while the business still has no usable result.
Save the version, expected result and observed result for each case. If you fix something during the demonstration, repeat the failed case. The corrected version becomes the candidate for acceptance; an earlier successful call doesn't validate the edit.
You may discover that the client's queue has its own awkward behavior. Staff might leave requests unread because they arrive in a folder nobody checks. Discuss that before increasing the agent's responsibilities.
Price the work you will keep doing
The setup work includes understanding the process, configuring the service, testing it and handing it over. Recurring work includes reviewing failures, keeping agreed business information current and supporting the client.
Write these separately in your quote. Add the usage allowance or billing rule, support hours, included changes and the process for approving additional work. The buyer should be able to tell what a quiet month and a busy month would cost.
Use your expected delivery costs to check the price, then revise the estimate with observed work. The service-cost guide has a worked example showing setup, usage and support as separate parts of a quote. Its figures are hypothetical; use your own costs when preparing a proposal.
Allow time for the first client's learning curve. You may need to improve your checklist, source approval process or failure report. Decide which of those costs you will absorb as the agency's own work. Passing every first-time mistake to the client as an extra charge makes the original offer difficult to trust.
If the request expands beyond the agreed service, review scope-change guide before adding it. A second language or booking integration can alter testing and ongoing support even when the visible change looks small.
Use a paid pilot when the buying question is unresolved
Sometimes the owner understands the offer but needs evidence about whether staff will use the requests. A bounded pilot can answer that question.
Agree on the pilot period, fee, workflow and review meeting before starting. Define the evidence that would support a recurring service. For the landscaping company, useful evidence could include the number of eligible calls, usable requests, submission failures and staff time spent correcting records.
Do not promise a particular return from a short pilot. The number of callers, staff follow-up and whether those callers buy all affect the result. If the pilot captures only a handful of enquiries, the commercial question may remain open.
The paid-pilot guide covers the decision sheet and the difference between technical acceptance and a buying decision. Keep those separate in the proposal. A working intake route can still be a service the client doesn't need enough to purchase.
Hand over a service the client can operate
Ask the staff member to handle a test request without your help. They should be able to find the record, understand its status and know what to do if a detail is missing.
Give the client a short operating guide with the supported workflow, approved information source, support contact and exception path. Record who owns each account and connection. Include how to suspend the service and what happens to outstanding requests when it stops.
The guide should describe the current service. Future integrations and possible features belong in a separate discussion so they do not become accidental commitments.
Before accepting the handover, check the practical conditions:
- The business has approved the supported services and caller-facing promises.
- Controlled requests reach the destination staff will use, with final corrected details.
- The exception path reaches an identified person or queue.
- Staff can operate the request and exception paths without the agency sitting beside them.
- The quote defines usage, support and included changes.
- Access ownership and the suspension procedure are recorded.
- An owner has accepted the evidence and any remaining limitations.
Leave unchecked items visible. A calendar entry for a handover meeting does not mean the service has passed acceptance.
Decide when the second offer is justified
After the first service runs, review the work you actually delivered. Compare support time with the estimate. Read the exceptions. Check whether staff use the records and whether the client still wants the same result.
Some lessons improve the existing offer: a clearer intake field, better information approval or an easier staff guide. Others suggest a different service. Automatic booking, for example, needs its own supported states and recovery rules.
Before offering that addition, write its acceptance condition and cost its support. Keep the existing intake service available while the new behavior is being evaluated.
For your next sales conversation, bring the one-page offer and the acceptance table. Ask the buyer to choose the queue where the result must appear and the person who will inspect it with you.