Run
Running it day to day
What operations looks like after launch — monitoring, updates, support, and what breaks in practice.
Who does what
| Hosted SaaS | On-prem cloud | Kiosk | |
|---|---|---|---|
| Infrastructure | Us | Us, in your account | You, with our support |
| Software updates | Us | Us, on an agreed window | Scheduled with you |
| Content and knowledge base | You, with our help | You, with our help | You, with our help |
| Physical hardware | — | — | You |
Monitoring
Every deployment reports health: worker liveness, GPU state, session counts, error rates, software version. We watch it. For on-prem and kiosk you get the same view, and alerting can go to your channel as well as ours.
Worth watching yourself, because it reflects your users rather than our infrastructure:
- Conversation completion rate — sessions that reached a useful end
- Escalation rate — how often the avatar hands off
- Unanswered questions — the direct input to the next knowledge-base update
Updates
Software rolls out on an agreed window with a rollback path. Avatar assets, knowledge base content, and flow changes deploy without downtime. Model or rendering upgrades are scheduled — for kiosks, typically outside opening hours.
Kiosks restart into a working state unattended after power loss. This is deliberate: nobody should have to visit a mall at 6 a.m. to reboot a screen.
Support and escalation
Support scope and response times are set in your contract. In every case:
- A named channel, not a generic inbox
- Escalation to engineering for anything affecting live conversations
- Post-incident write-ups for anything that took a deployment down
What actually goes wrong
Honest list, in rough order of frequency:
- Audio hardware. Bad microphone placement, a wrong input device selected, or ambient noise in a hall. Overwhelmingly the biggest source of "the avatar does not understand me". Fix it physically before touching the software.
- Network policy. A firewall change blocking UDP breaks the media path. A relay fallback exists, and it costs latency.
- Stale knowledge. The avatar answers from a document nobody remembered was still indexed. Fixed by re-indexing, prevented by a refresh cadence.
- Upstream systems. An integrated endpoint gets slow or goes down, and the flow stalls. This is why timeout behaviour is agreed up front.
- Capacity at peak. More simultaneous conversations than provisioned. Visible in advance in the metrics if anyone is watching.
Changing content
Knowledge base updates, wording changes, new languages, and new avatars are routine and do not require a redeploy. Flow changes go through review before release. Tell us the cadence you want and we will fit it.