Blog

Field notes from
production

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.

Grid of article cards in the OrOn brand style
6Sectors covered
60 daysPer measurement
ProductionNot lab conditions
0Vendor fluff
Recent themes

What we are writing about

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.

Contact

Ask for a written brief

Tell us the use case and the volume. We come back within one business day with a scoped pilot, a timeline and a number.

Contact Us

Accessibility