This market is young, credentials are hard to interpret, and confident presentation is cheap. These are the questions that produce different answers from people who have actually deployed something.
1. What does the system do when it is not sure?
The single most revealing question.
A vendor who has shipped will answer immediately and in detail: confidence thresholds, what triggers a handover, what the customer experiences. A vendor who has not will describe how accurate it is — which is an answer to a different question.
Every system is uncertain sometimes. What it does then determines whether it is safe to put in front of customers.
2. Who owns what you build?
Ask specifically about the workflow definitions, the prompts and the integration configuration, and what you receive if the relationship ends.
If the answer involves a proprietary platform you cannot export from, you are renting rather than buying, and the price of leaving grows every month. Not automatically wrong, but it should be priced in knowingly.
3. Where does the data sit, and who else touches it?
Ask for the sub-processor list — the model provider, telephony, hosting, transcription. A vendor who cannot produce one does not know where your customers' data goes.
If any component sits outside India, that should be stated in the proposal rather than discovered later. See the DPDP checklist for why this belongs in the contract.
4. What does it cost to run each month?
Build cost is the number in the proposal. Running cost is the number you live with — model usage, telephony minutes, hosting, monitoring.
A vendor who has operated systems knows these figures and will give you a range. A vendor who has only built demos usually has not thought about it, and the answer arrives as a surprise in month two.
5. Can we see it working on our data?
Not a demo. Your enquiries, your recordings, your documents, with their gaps and inconsistencies.
Demos are built on clean data by definition. The gap between demo and production is almost entirely a data-quality gap, and the only way to size it is to try.
6. What will you tell us we should not automate?
A useful vendor has an answer. Sometimes the honest recommendation is that a process is too variable, too low-volume, or too consequential to hand over yet.
A vendor for whom everything is a fit is selling capacity, not judgement, and you will find the limit yourself later.
7. Who actually does the work?
Ask whether the person scoping the system is the person building it, and who you speak to in month six.
In small engagements the answer should be short. A long chain between you and the person doing the work is where context is lost, and context is most of the value in this kind of project.
What good answers have in common
They are specific, they concede limitations, and they arrive quickly because the person has met the problem before. Vague, uniformly positive answers are the signal — not because the vendor is dishonest, but because they have not yet run into the parts that are hard.
Questions
- Should we expect case studies from a new agency?
- You should expect proof, which is not the same thing. A new agency can show you the system running on your own data, which is arguably stronger evidence than a case study about somebody else's business.
- How do we compare quotes that are structured differently?
- Reduce each to build cost, monthly running cost, and what you own at the end. Those three make otherwise incomparable proposals comparable, and the third is the one most often left vague.
- Is it a problem if a vendor uses off-the-shelf tools?
- Usually the opposite. Standard tooling means the work is portable, hiring for it is possible, and you are not dependent on one team's private framework. Custom code should be justified by a need, not by preference.
Want this working on your numbers rather than in an article? We scope it on one call.
Book a Consultation Call