Every number here has a definition, a sample and a date.

Why a method outranks a logo wall

A logo wall asks you to infer a capability from a customer’s willingness to be associated with us. The inference is weak. A logo proves that a contract existed, not that the product did what the page claims, and it certainly does not tell you the baseline, the cohort or the quarter. It is also unfalsifiable from the outside: you cannot ask a logo what it measured, and the answer would not be published if you did.

A method is a different artefact. It lets a stranger reconstruct the claim, disagree with the definition, and re-run the test on their own traffic. That is the standard we are trying to meet here. You should be able to read the voice latency section, take the definition to your own pilot, measure the same segment, and get a number that is comparable to ours even if it is worse. A number you can argue with is more useful than a testimonial you cannot check.

There is a commercial reason as well. A case study is written once and ages badly: the customer changes their stack, the result stops being reproducible, and the page stays up because it converts. Definitions can be checked every quarter. A case study about a large account also tells a three-person team in Nashik very little. A method at least tells them what we would measure in their situation and what we would refuse to conclude from it.

What a method cannot prove should be said before anyone asks. It cannot prove your result, because your list, your languages and your callers are not our replay set. It cannot prove the claim is true today, only that it was true on the date of the run. It cannot prove the absence of failures, because a sample is not a census. It cannot substitute for a trial in your own account. And it cannot rescue a number produced by an uncalibrated judge or measured on a segment nobody defined, which is why the definitions come before the numbers on this page.

The five fields every number carries

We use a small internal test before a figure goes on a page. It has to carry five fields: the quantity, the segment, the population or sample, the window, and its status. The quantity is the thing being counted, such as milliseconds or hours. The segment is where the clock starts and stops. The sample is how many observations, on what mix, and whether any were excluded. The window is the date range and the conditions. The status says whether the number is a measurement, a target, a design intent or a model.

Four of those five are missing from most vendor claims, and the omission is usually not dishonest. It is shorthand. A team measures something internally, writes the headline, and drops the qualifiers because the landing page has limited space. The problem is that the qualifiers were the meaning. A median of 420 milliseconds across a curated set of clean English prompts and a median of 420 milliseconds across Hinglish telephone audio are different achievements that produce the same sentence.

Status is the field we guard most carefully. Measured means a run exists with a record we can produce. Target means we build against it and have not yet met it, or have met it only in conditions that do not generalise. Design intent means the architecture is shaped to achieve it, and no number should be inferred. Modelled means arithmetic on assumptions rather than observation, and it is labelled as such wherever it appears.

The rule has a cost. It makes some sentences longer and some marketing assets weaker. A competitor can write a single confident number where we write a clause about the sample. We accept that trade because the alternative is a page that cannot be defended in a procurement meeting, and because the first question a serious buyer asks is not what the number is but what it was measured on.

420 milliseconds: what the clock actually covers

The published voice figure is 420 ms at p50 for the India region. The clock starts when the system decides the caller has finished speaking, which is a decision, not a silence threshold. It ends when the first audible byte of synthesised speech reaches the caller’s handset. Everything between those two points is counted, including the finalisation of the transcript, the model producing its first token, the synthesiser returning its first frame, and the network path in both directions.

Two things are outside the clock and it matters that they are named. The caller’s own thinking time is outside it, because a slow answer is not the same as a slow system. So is anything the agent says before the answer begins, such as a generated holding phrase while a lookup runs. Strictly, a turn that uses a holding phrase has a short time to first audio and a longer time to the actual answer, and we report the first. We do not use the holding phrase to hide a slow tool call; the tool call still appears in the trace with its own duration.

The segment is a single turn, not a call. A call is a sequence of turns, and the median of the turns is not the median of the calls. We publish the turn median because it is the unit a caller experiences as responsiveness, and we keep call-level distributions internally for capacity work. Conflating the two is one of the easier ways to make a voice product look faster than it feels.

It is both a measurement and a target, and the difference is what you are allowed to infer. Read it as a measurement when you want to know what our stack did on a recorded set, on a date, with the model version attached. Read it as a target when you are deciding what to expect on your own calls, because no individual call is promised it. A page that made only the first claim would be overselling, and a page that made only the second would be hiding that we measure at all. The stage split published on the voice page is a third thing again, a design intent: it is the budget we allocate across endpointing, recognition, model and synthesis, and it is labelled a sample because individual runs move those shares.

The sample and the tail: why p95 is the planning number

A median from twelve turns is an anecdote with a decimal point. Our rule is that a publicly quoted p50 needs at least 600 complete turns, at least 100 turns in any single language named beside the figure, and failed turns counted in the denominator rather than quietly dropped. The run is repeated on two consecutive days with the same replay set and the same model version, and the pooled median is quoted. If the two daily medians differ by more than ten per cent, we do not publish until the cause is understood. Those thresholds are a rule we set for ourselves, not a measured result, and they are the first thing we would raise if the claim were challenged.

The replay set is deliberately not live customer traffic. Live calls cannot be replayed, the input cannot be held constant, and using them for a published figure would require consent for a purpose the caller never agreed to. Replay controls the audio and leaves the network as the variable we cannot hold, which is why every run is tagged with the access network used. A run on office fibre is not comparable to a run on 4G in a moving vehicle, and we do not present it as though it were. That is the honest limit of the number: it describes our stack on a recorded set, not your callers on your route.

A median is a fine summary and a poor planning number. Half of all turns are slower than the median by definition, and the calls people remember are the ones where the agent paused long enough for them to say hello twice. In a conversation one slow turn can end the call, so the distribution matters more than its midpoint. p95 tells you what a caller hits on a bad turn several times in a hundred, and p99 tells you what produces the complaint rather than the compliment.

We publish p50 because it is the number the site has always used and because it is honest when labelled. We will quote p95 from the same run when asked, and we do not publish a p95 we have not measured. The distinction matters: a p95 assembled from a different run, a different network or a different replay set is not a percentile of the same population. If the p95 looks bad, the useful response is to read the trace, not to find a friendlier sample.

The tail belongs to design, not marketing. Timeouts, fallback phrases, barge-in behaviour and the decision to hand off to a human all depend on the slow end of the distribution. A system tuned to its median cuts the caller off the moment a turn runs past the typical value; a system tuned to its p95 waits long enough to be tolerable and has a policy for the turn that exceeds the budget. The same logic applies to every aggregate here: a typical 48-hour figure says nothing about the account that took three weeks, and an eval average can hide a weak slice. Run the pilot on your own recordings, two hundred calls, your network, and measure p50 and p95 yourself. That is the only number that describes your calls.

What 48 hours means, and what it excludes

The go-live figure describes one workflow reaching production, not a platform being installed. The clock starts when four preconditions exist: workspace access, a lawful basis and a clean contact or call list, one named owner on the customer side who can approve copy, and a working connection to the system the workflow must read or write. It ends when the workflow handles real traffic, a production trace shows a completed run, and that named owner accepts the outcome against the definition agreed at kickoff.

In scope is a single standard blueprint on one channel, or a two-step sequence such as a form fill followed by a WhatsApp message and a call task. Out of scope, explicitly: DNS propagation and record TTLs, sending domain warm-up, Meta template review and re-approval, WhatsApp number migration and release by the previous provider, DLT registration and operator scrubbing for SMS and voice sender identities in India, payment gateway onboarding and KYC, historical data clean-up, a rebuild of existing automations, and procurement or DPA redlines.

Those exclusions are not small print. DLT registration is a telecom process with its own queue and rejection reasons. A number release depends on another company’s support desk. Template review depends on a platform that does not share our calendar. A DNS record propagates on a TTL we do not control. None of these can be compressed by working harder, and quoting a 48-hour figure that silently includes them would set a customer up for a missed launch they would blame on the product.

The honest label for the figure is a typical elapsed time on completed onboardings where the preconditions were already true. We do not publish it as a median with a distribution, because the population is self-selected and the failures are mostly accounts that never met the preconditions. We do not present it as an SLA, and we will not accept a contract clause that turns it into one. If a customer needs a committed date, the right instrument is a project plan with named dependencies, not a number from a marketing page.

Delivery is not placement

Email has two success events and vendors often report the easier one. The first is server acceptance: our sending infrastructure connects to the recipient’s mail system, the message is offered, and the server returns a 250 acceptance. The second is placement: the message lands in the inbox, a tab, the spam folder, or nowhere the recipient will look. Acceptance is visible to us in real time and is a fact about the handoff. Placement is a judgement made by a provider we do not control, using reputation and engagement signals we can only infer.

That gap is why delivery rates near one hundred per cent are not the reassurance they appear to be. A message can be accepted and spam-foldered, accepted and filed to a promotions tab nobody opens, or accepted and silently discarded downstream. None of those events generates a bounce, so a dashboard built on acceptance looks healthy while the campaign fails. The provider’s postmaster tooling, complaint rates, replies and panel data are the only ways to see past the handoff.

Our billing unit follows the same line. Email overage is charged at ₹0.03 per delivered email, exclusive of 18% GST, and delivered here means accepted by the receiving server, not confirmed in an inbox. We state that because a customer comparing an invoice to a panel report deserves to know why the numbers differ. Billing follows acceptance rather than placement, so a message that was accepted and spam-foldered still counts toward the allowance, and we do not claim to guarantee placement on a shared or dedicated IP.

What we can do is narrower and more defensible. We can keep authentication aligned, monitor bounces and complaints, honour suppression before the send rather than after, keep volume inside a reputation-safe ramp, and report per-domain behaviour where our provider gives us the data. We cannot promise an inbox, because the decision belongs to a system we do not run. Any vendor who promises it is either describing an acceptance rate or has not read their own dashboard.

Seed panels: a sample with a composition line

A seed panel is the closest thing to a placement measurement available to a sender. A set of monitored mailboxes is added to a campaign, or receives a copy, and the panel classifies what happened at each mailbox: inbox, tab, spam, or missing within an observation window. Good panels also report authentication results and a rendering screenshot. The output is useful, and it is a sample of a handful of mailboxes rather than a measurement of your list.

Four limits decide how much weight the result can carry. Seeds have no engagement history, and providers weigh engagement heavily, so a seed is not a typical subscriber. Panel mailboxes are known to providers and sometimes share domains with other panel customers. Cell sizes are small: a hundred seeds split across six domains leaves roughly sixteen per cell, so a single message moving to spam shifts that cell by six points. And the observation window is usually hours, while real recipients open over days.

Panels also disagree with each other, and not because one is broken. They use different mailbox sets, different reading methods and different definitions of inbox. One counts the promotions tab as inbox, another does not. One observes for two hours, another for a day. That is why a report is only comparable with itself over time, under stable composition, and why the panel name, method, date and send volume belong in any screenshot we share.

Our practice is to run a panel before a change of sending domain, IP pool or template system for accounts where we manage sending, and to report per domain rather than as a blended percentage. We do not run a panel on every campaign, because the cost would be passed on for a measurement that is noisy at low volume. And we never present a panel result as a guarantee. A clean panel is one positive signal among bounces, complaints, replies and revenue, and it loses to the outcome whenever the two disagree.

Consent and deletion: what an audit row contains

A consent claim is only as good as the row behind it. Ours carries the contact identifier, the purpose, the notice version and a hash of the notice text, the collection point such as a form or a call, the channel, the timestamp in IST with a UTC equivalent, the lawful basis declared by the customer, the actor who recorded it, and a pointer to the evidence: a form submission identifier, a message identifier or a call recording reference. Withdrawal is a second timestamp on the same row, not a deleted row, because the history is the proof.

The notice version is the field most often missing elsewhere. A boolean called opted in cannot answer the question an auditor actually asks, which is what this person was shown on the day they agreed. If the notice changed in June and the consent was collected in March, the version field is the difference between evidence and assertion. It also lets a customer re-collect consent when the purpose changes, instead of pretending the old permission covers the new use.

A deletion row is a different shape. It records the request identifier, the requester and how identity was verified, the scope agreed, the systems in scope, a per-system outcome, the categories retained with a reason, the backup expiry date, the approver, and the completion time. Retained categories are not a failure. Consent records and tax invoices have their own retention basis, and erasing the evidence of lawful processing on request would defeat the audit the request is meant to satisfy. We say which categories survive, and why, in the confirmation.

There is no unattended sweep to point at, and we will not claim one. Retention is configured per data class, and a scheduled deletion is a job with a run record: what was selected, what was deleted, what was skipped and why. Where the trigger is a person, the operator and the reason are in the row. The evidence is the run record plus the absence of the record in live systems, which is why we prefer an export of rows to a screenshot of a settings page. A screenshot shows intent; a row shows what happened.

The evaluation harness: sets, rubrics and gates

Behaviour is measured with a harness, not with a demo. A golden set is sampled from real traces, redacted, labelled against the correct outcome, stratified by channel, language and intent, and versioned so that every score can be tied to the exact set that produced it. A portion is held back and never used for tuning, because a set that is edited after every failure stops being a measurement and becomes a mirror of the last prompt change.

Scoring is mostly deterministic. Did the agent call the order lookup before quoting a date, did the arguments match the schema, was consent captured before a template send, did the reply stay inside policy, was the escalation handed off with context. These are checks, not opinions. A rubric covers the remaining qualitative criteria with anchored levels, and critical criteria such as consent or a medical refusal can fail a case on their own. The decision rule is written before the run, so two reviewers cannot disagree about what a pass means afterwards.

Gates use slices, not an average. An agent can improve its overall score while getting worse at escalation, because escalation is a small share of traffic. We gate on the slices that carry legal or financial risk, with their own thresholds, and we measure the noise floor by running the unchanged system twice before setting a limit. A gate that fails randomly teaches the team to bypass it, which is worse than no gate. A named owner signs off on each release candidate.

We do not publish a pass rate from this harness. The set is ours, the rubric is ours, and a percentage on a marketing page would be read as a benchmark against other vendors when it is only a statement about our own cases on our own date. What we will do is run a joint evaluation with a customer’s own cases in a sandbox and let them score the calls. That is slower than a headline and considerably more useful, because it answers the question the headline was standing in for.

An uncalibrated judge is not evidence

Using a model to score another model is reasonable at volume and dangerous without calibration. Judges carry known preferences: longer answers, the first option in a comparison, text that resembles their own output, and a general tendency to agree with a confident claim. None of that is visible in a score. A judge that was never compared with human labels produces a number with no error bar, and a number with no error bar is a preference dressed as a measurement.

Calibration is unglamorous. Label a few hundred cases by hand against the rubric, run the judge on the same cases, and measure agreement per criterion rather than in aggregate. Where agreement is poor, either tighten the rubric with worked examples or replace the judge with a deterministic check. Report the agreement rate beside the score, because a 92 per cent pass rate from a judge that agrees with humans 60 per cent of the time is not a 92 per cent anything. Agreement is not truth either; a judge and a human can agree on a bad rubric.

The ordering that works is: deterministic checks first, human labels for the anchor set, and a calibrated judge only where judgement is unavoidable. Anything observable in a trace should be code. That includes the presence of a tool call, the shape of its arguments, the consent flag before a send, the length of a reply, the latency of a turn and whether a human approval was requested. These are cheap, stable and impossible to argue with, which is exactly what a gate needs.

No figure on this page comes from an uncalibrated judge. The published numbers here are latency, elapsed time and process facts, not quality scores. When we eventually publish a quality figure, it will arrive with its set version, its sample size, its slice breakdown and its judge agreement, or it will not arrive at all. That is a stricter standard than most pages apply, and it is the only one that survives a customer asking how the number was produced.

What we deliberately do not publish

Some things are withheld for consent. We do not name customers, quote their results or display their logos without written approval for that specific use. A customer’s traffic mix and conversion rate are their commercial information, and a vendor page is not the place to disclose them. Where a customer agrees to be referenced, the resulting document belongs to a joint review with a named approver, and it is dated, because an approval is not perpetual.

Some things are withheld for security. We do not publish penetration test dates, internal test catalogues, tenant isolation test cases, key management procedures or the exact version of every dependency. The security page states controls and status, and the detail goes to a buyer under a review process. That is not a refusal to be transparent; it is the difference between describing a lock and mailing out its pin. The same applies to sub-processor contract terms, which are available under the DPA rather than on a web page.

Some things are withheld because publishing them would destroy the measurement. Individual evaluation cases, the full rubric and the holdout are not public, because a public set gets trained against and stops measuring anything. The same logic applies to the exact replay prompts behind a latency figure: publish the audio and the next run measures memorisation rather than the stack. We publish the definition, the sample rule and the date, which is what a buyer needs to audit the claim without contaminating the test.

And some things are withheld because we do not have them. There is no public uptime percentage, because there is no live status provider feeding one and a template number would be invented. There is no customer count, no net revenue retention figure, no independent benchmark placing us against a competitor, and no certification we have not earned. Those absences are not modesty. They are the same rule as the rest of the page: if it is not measured, it is not stated.

Reading 420 ms critically: a worked example

Take the headline as a stranger would. The first question is what the clock covers: end of speech to first audible byte, or request sent to response received. Ours is the first, which is the harder definition, and a vendor using the second will look faster on the same stack. The second question is whose stack and which region: ours, on infrastructure in Mumbai, over Indian telephony legs. A number measured on a laptop in another country answers a different question.

The third question is the sample. The published rule requires six hundred turns, two runs, no silent exclusions and at least a hundred per language named. The fourth is the percentile: p50 is a median, so half the turns are slower, and the p95 from the same run is the number to plan with. The fifth is the condition: 4G in a moving vehicle is not office fibre, and a run that does not say which one it used has hidden its most important variable.

Now decide what the number licenses. It supports a reasonable expectation of conversational turn-taking on a decent Indian mobile connection, for the languages tested, on the date of the run, with the model version recorded. It does not support a claim that every call answers in under half a second, that the product is faster than a named competitor, or that your IVR will feel instant with your prompts and your tool calls on the critical path. That is four different claims, and only the first is on the table.

The useful next step is a pilot on your own recordings. Two hundred calls, your accent mix, your network, your longest tool call, measuring p50 and p95 separately. If our number holds, you have evidence for your own environment rather than ours. If it does not, you have found the gap before signing, which is the outcome this page is designed to produce. A vendor whose numbers survive that test has earned the deal; one whose numbers do not has done you a favour by publishing them.