A requirements document that asks whether a supplier supports something will be answered yes by everyone, including the suppliers that cannot. The version that works asks for the artifact that would prove it, and treats a missing artifact as an answer.
- Pair every line with a proof Each requirement should name the artifact, recording or clause that would demonstrate it, so a yes has something attached.
- Scope before questions Call directions, volumes, languages, hours and systems go first, because the quality of every answer depends on them.
- Separate shown from planned Ask suppliers to mark each capability as available today, configurable, or on the roadmap, and score the three differently.
That single change does most of the work. It converts a document that collects claims into one that collects evidence, and it shifts the burden of demonstration from your evaluation team onto the supplier, which is where a procurement process is supposed to put it.
The second job of the document is to be answerable. Suppliers give vague responses to vague scope, so the requirements have to describe your calls, your systems, your hours and your operators specifically enough that a serious supplier can price the work and an unserious one cannot hide.
What the Document Must Establish Before It Asks for Anything
Suppliers cannot answer usefully against an undescribed operation. The opening section is not a formality; it is what makes every later response comparable and what makes a missing capability visible.
- Call directions in scope, and for each one the telephony route you intend to use.
- Volume: calls per day, the shape of the peak, and how many calls can be in progress at once.
- The call reasons the agent must handle, with the outcome each one is expected to reach.
- Languages, and which of them must be handled in the same call rather than on a separate line.
- The systems the agent must read from or write to, and which of those are internal.
- Who will operate it day to day, and what their technical background is.
The last line is the one buyers leave out and then regret. A platform that assumes developers and a platform that assumes an operations team are different products, and the difference does not appear anywhere in a feature response.
Where the scope contains a hard constraint that only certain suppliers can meet, state it as a mandatory requirement at the top rather than as one line among fifty. That decision is examined in choosing between assembling a voice agent and adopting a platform.
Asking for Evidence Instead of Assertion
Every requirement in the document should carry a second column naming what would demonstrate it. The column costs little to write and changes what comes back entirely.
The strongest evidence for anything about conversation. Ask for a recording of the described behavior, not a description of it.
An exported transcript, call summary or log showing the fields that actually exist, rather than a screenshot of a dashboard.
An attestation report, a subprocessor list, a data retention setting shown in the product, or a written procedure.
Where behavior cannot be demonstrated in a few weeks, the evidence is a commitment you can enforce afterwards.
Rank those four deliberately. A recording beats a report for anything a caller would experience, and a clause beats both for anything about reliability, support or what happens over a period longer than an evaluation.
Set one rule and hold it: an unevidenced yes scores the same as a no. Announcing that rule in the document itself improves the quality of responses more than any individual question does.
Requirement Areas and the Proof to Demand
The areas below are where assertions and reality diverge most often. Each row pairs the claim a response will usually contain with the artifact that would settle it.
| Requirement area | The usual assertion | Evidence to ask for |
|---|---|---|
| Call direction and route | Inbound and outbound are supported | A live call each way on the telephony route named in your scope |
| Grounded answering | It answers from your own content | A recording of a question your documents do not cover, and the passage any answer was drawn from |
| Handover to a person | Warm transfer is supported | A recording from the receiving side showing what context arrived with the call |
| Behavior under failure | The service is highly reliable | The documented fallback when a component is unavailable, and the record of the most recent incident |
| Keeping your number | You can use your existing number | The specific route, the steps involved, who performs each one and how long it takes |
| Language coverage | Multiple languages are supported | Recordings in each required language on your own call reasons, not a generic sample |
| Data handling | Security is enterprise grade | Named certifications with current reports, a subprocessor list, and retention settings shown in the product |
| Change control | It is easy to configure | A recorded session of a non-developer making a named change, with the elapsed time visible |
Two rows repay extra attention. The fifth decides how reversible the decision is, and the routes differ materially, as set out in the ways an existing business number can reach a voice agent.
The seventh needs care in the other direction. Certification, consent, disclosure and recording duties vary by jurisdiction, call direction, sector and purpose, so ask suppliers what they hold and what they support, and establish which obligations apply to you with your own counsel. The controls themselves are covered in the controls a voice agent deployment is expected to have.
Questions That Separate Capable Suppliers From Confident Ones
A handful of questions are hard to answer well without having actually run systems in production. They are worth more than a long feature matrix, and they take a few minutes each.
- Play us a call where the agent got something wrong, and tell us what changed as a result.
- Who configured what you have shown us, what is their job title, and how long did it take them?
- Whose name are the telephony and model provider accounts in, and who holds the keys to them?
- What happens to a live deployment when a model or voice version we launched on is retired?
- Which of the capabilities in your response are available today, and which are planned?
- If we end the contract in eighteen months, what do we take with us and in what format?
- Who is reachable when the line misbehaves outside office hours, and what is committed in writing?
The first question is the most revealing of the seven. A supplier with real deployments has a failure they can describe precisely and a change they made afterwards. A supplier without them changes the subject to the roadmap.
The third looks administrative and is not. Where the provider accounts sit in the customer's name, as they do with Pulastya AI, usage and limits stay visible to the buyer and the relationship with those providers survives a change of platform.
The fourth question is the one that predicts year two. Ask specifically what notice is given and who does the re-testing, because a version retirement reaches callers directly.
Scoring the Responses, and What Not to Weight
A scoring scheme decides the outcome more than the questions do, because it determines what a confident answer is worth against a demonstrated one.
- Mark each requirement mandatory or desirableA mandatory requirement that is not evidenced removes the supplier. Say so in the document rather than deciding later.
- Score the evidence, not the claimGive the full mark only where the named artifact arrived. A described capability with nothing attached scores as unproven.
- Discount anything on the roadmapScore planned capability at a fraction of delivered capability, and state the fraction in the document so nobody argues later.
- Score the operator experience separatelyHow quickly your own team can change the agent is a distinct dimension from how well it handles calls.
- Keep the commercial score out of the capability scoreCombine them at the end. Blending early lets a low headline figure carry a supplier past a mandatory gap.
There are also things that should carry no weight at all: customer logos without a reachable reference, funding announcements, the polish of the demo environment, and any certification named without a current report behind it.
Where scored evidence has to come from your own calls rather than from a response, run it as a separate exercise before the final score, using the approach in a trial designed to make a buying decision.
What to Require in Writing Rather Than in the Response
Some things cannot be demonstrated inside a procurement window at all. For those, the correct evidence is a commitment that survives the signature, and the requirements document is where it gets asked for.
- Acceptance criteria written from your own trial calls, with the consequence of failing them stated.
- A definition of availability that says what counts as an outage for a phone line, not only for an interface.
- Notice before the default model, voice or telephony behavior of your deployment is changed.
- Who re-tests after such a change, and against what.
- Return and deletion of your documents, recordings, transcripts and call records when the contract ends.
- Notification obligations if an incident touches call content.
The fifth item is the one that determines how free the next decision will be. A platform where an existing business number is kept by pointing its webhook at the service, as Pulastya AI does, leaves the number itself outside the contract, which narrows what has to be negotiated on exit.
What each of these commitments should actually contain depends on how the deployment is governed, which is set out in governing a voice deployment across security and operations. The capability side of the requirements can be scored against a structured set of evaluation criteria, and configuration options are listed on the AI voice agent platform.
Frequently Asked Questions
Short enough that every line has an evidence column somebody intends to read. A hundred unanswerable feature questions produce a hundred confident yes answers and no information. Thirty requirements, each paired with the artifact that would prove it, discriminate between suppliers far better and take less time to score.
Ask what the supplier holds, ask for the current report rather than the logo, and ask which obligations the product helps you meet. Which rules apply to your calls depends on jurisdiction, call direction, sector and purpose, so establish your own duties with counsel and use the RFP to find out what a supplier can evidence.
Ask for it, but score it separately and combine at the end. Blended scoring lets an attractive headline figure carry a supplier past a requirement marked mandatory. Ask for the commercial response in a structure you define, so the offers arrive in comparable shape rather than in each supplier's preferred one.
State in the document that an unevidenced yes scores as unproven, name the artifact you expect for each requirement, and ask suppliers to mark every capability as available, configurable or planned. The combination changes the incentive, because an overstated response becomes visible at the point evidence is due rather than after signature.
Ask the supplier to play a recording of a call the agent handled badly and explain what changed afterwards. It is difficult to answer without production experience, it reveals how the supplier treats failure, and it tells you whether there is a process for improvement or only a roadmap.
