Everything here comes from deployments that actually shipped, including the parts that went wrong. Client names are withheld under NDA; the sectors, architectures and numbers are real.
Full posts are published to our mailing list first. Write to Sales@or-on.io to be added, or ask for any of these as a written brief.
Where the latency cliff actually sits
We assumed latency degraded experience gradually. Call data across three deployments showed a sharp behavioural break, not a slope, past a certain point callers start talking over the agent and satisfaction collapses.
Hebrew is not a translation problem
Israeli Hebrew code-switches into English constantly, moves fast, and uses register in ways a translated script cannot capture. What we changed after the first Hebrew deployment underperformed.
Escalation is a feature, not a failure
The deployments with the highest satisfaction scores were not the ones with the highest automation rates. Designing the handover well mattered more than automating one more percent.
What on-premise actually costs
GPU sizing, concurrency headroom and the real total cost of running a speech-to-speech stack in a government data centre, with the numbers from a live deployment.
The first use case decides the programme
Across enterprise rollouts, the pattern is consistent: pick the highest-volume, lowest-complexity category first. The teams that started with the hard case mostly did not get to a second one.
Guardrails in regulated voice
How we constrain what an agent may say in enterprise and financial contexts, and how we prove it held, the deterministic layer over a probabilistic system.
How it works
How we write these
Anonymised, measured and reviewed by the customer before anything is published.
Deploy
Something ships to production and runs long enough to produce real data.
Measure
At least 60 days against the customer's own pre-deployment baseline.
Anonymise
Names, logos and identifying details removed; sector, architecture and numbers kept intact.
Customer review
The customer reads and approves before anything is published or shared.
Every post comes from a real production deployment
Numbers measured against the customer's own baseline
Client identities withheld under NDA
Customer reviews and approves before publication
Failures and regressions included, not just wins
Written briefs available on request to Sales@or-on.io
FAQ
Blog questions
Straight answers. Anything missing? Write to Sales@or-on.io.
Write to Sales@or-on.io and we will add you to the list. Posts go out to the mailing list first, typically once or twice a month, and only when there is something measured worth writing about.
Yes. If one of the themes above is directly relevant to a deployment you are evaluating, ask and we will send the full write-up, usually including detail that does not go into a public post.
Because most of our customers operate under NDA, particularly in government and regulated sectors. Sectors, architectures, integration patterns and measured outcomes are all real, only the identities are removed.
Yes, deliberately. The deployments that underperformed taught us more than the ones that went smoothly, and a vendor blog with no failures in it is marketing rather than engineering.
Some customers do, once a deployment is mature and they are willing to be named. If that interests you, Sales@or-on.io will connect you with the engineering team.