Why we send an engineer to sit in your contact centre
Most AI call centre projects fail after handover, not before it. Why Voho puts forward deployed engineers inside the customer's operation, what they actually do week by week, and when you do not need one.
The uncomfortable fact about enterprise AI is that the software is rarely the reason a project fails. The model works. The demo worked. What fails is the distance between the people who built the system and the people whose job it is to answer the phone.
A specification is written. Someone builds against the specification. It is delivered, it passes acceptance, and then it meets a call mix nobody described accurately, on a phone estate nobody documented fully, with escalation rules that were decided in a meeting rather than by listening to what actually happens when a caller gets angry. Three weeks later the containment rate is half what the pilot showed and nobody in the building owns the problem.
Voho's answer to this is not a better specification process. It is to stop writing one from a distance. We send forward deployed engineers into the customer's own contact centre, and they stay until the thing works on real calls.
What a forward deployed engineer is, concretely
A forward deployed engineer is one of our engineers, working from your site, inside your operation, with access to your call recordings and your systems, building the deployment in place. Not a project manager, not a solutions consultant, and not a support contact. Somebody who writes the code, sitting where the calls are.
The reason this works is unglamorous. Almost everything that determines whether an AI call centre succeeds is knowledge that exists in your contact centre and has never been written down: that a particular intent is 30% of volume but was never in the requirements, that callers describe a fault in three different ways, that the transfer to the billing team is the one that always goes wrong, that the busiest hour is not the one on the report. None of that survives a specification. All of it is obvious within a week of sitting there.
What the first month actually looks like
| Week | What the engineer is doing | What you get at the end of it |
|---|---|---|
| Week 1 | Listening to real recordings with your supervisors. Mapping the actual intent distribution, not the assumed one. Walking the Cisco or Avaya estate with whoever owns it. | An intent map ranked by volume, and a shortlist of what is genuinely automatable now. |
| Week 2 | Building the top intents against your live systems. Tuning dialect and vocabulary on your own recordings, including your product, site and system names. | Working agents for the highest-volume intents, tested on recorded calls rather than scripts. |
| Week 3 | Escalation design with your operations team. Deciding what the agent must never attempt, when it hands over, and exactly what the human receives on transfer. | A written escalation policy your supervisors agree with, implemented rather than documented. |
| Week 4 | Live on a slice of real traffic. Sitting with the floor, listening to what breaks, fixing it the same day. | Measured containment per intent on real calls, and a list of what to do next. |
The fourth week is the one that matters and it is the one a remote engagement cannot do. Being present when a call goes wrong, hearing the supervisor's reaction, and having a fix deployed before the end of the day changes the relationship between your floor and the system. It stops being a thing that was done to them.
What we need from you
This model has a cost on your side too, and it is worth being direct about it, because the deployments that struggle are the ones where these were not available.
- Real call recordings, including the difficult ones. Clean recordings are actively misleading and tuning against them produces a system that only works on clean calls.
- A supervisor who can give a few hours a week. Not a steering committee: one person who knows what actually happens on the floor and will say so.
- Somebody who owns the telephony and can answer questions about the SIP trunk, the routing rules and the queues.
- A decision-maker for escalation policy. What the agent must never attempt is a business decision, and it cannot be made by us.
- System access that arrives in week one rather than week five. This is the single most common cause of a deployment slipping, and it is almost always procedural rather than technical.
When you do not need this
Forward deployment is the right model for an enterprise with an existing contact centre, a real telephony estate, systems that have to be written into, and a compliance function that will ask where the data lives. It is the wrong model, and an unnecessary expense, in several cases.
If you have an in-house engineering team that wants to own voice quality as a product surface, you do not need us on site; you want the platform and the documentation, and Voho is self-serve for exactly that reason. An account comes with credit on it and an agent can be built in the browser without a sales conversation. If your use case is a single intent with a clean API behind it, appointment booking against one calendar, say, forward deployment is overkill and you should say no to anyone selling it to you.
We would rather tell you that at the start than bill for a month of it.
Why we do it this way
It is an expensive way to sell software. Engineers on site do not scale the way licences do, and it puts a hard limit on how many customers we can take at once. We do it because the alternative is a category of AI deployments that demo well and quietly stop being used, and there are enough of those in the Kingdom already.
It also reflects what Voho is. The company is AI-native rather than a contact centre business that added a model, and Arabic is the first-class case rather than a localisation layer: six dialects with what we believe is the best Saudi Arabic available, multilingual within a single sentence the way real Saudi calls are, and all data hosted in the Kingdom or inside your own network. None of that is worth much if the deployment does not survive contact with your actual callers, which is what the engineer on site is there to ensure.
If you want to see what the engineer would be building, the demos on this site run in the browser with no sign-up, in Saudi Arabic, including the transfer and the ticket being raised in a real system.
Frequently asked
- What is a forward deployed engineer?
- An engineer from the vendor who works from the customer's own site, inside the operation, building the deployment in place rather than against a written specification. For an AI call centre that means listening to real recordings with your supervisors, building against your live systems, designing escalation with your operations team, and being present on the floor when the first real traffic goes through.
- How long does an AI call centre deployment take?
- A focused deployment covering the highest-volume intents typically reaches live traffic on a slice of calls within about a month, assuming system access is available in the first week. Access delays are the most common cause of slippage and they are usually procedural rather than technical, so it is worth starting that process before anything else.
- Do we need a forward deployed engineer, or can we build it ourselves?
- If you have an in-house team that wants to own voice quality as a product surface, or your use case is a single intent with a clean API behind it, you do not need one. Voho is self-serve for that case: an account comes with credit and an agent can be built in the browser. Forward deployment earns its cost when there is a real telephony estate, several systems to write into, and a compliance function that will ask where the data lives.
- What does the customer have to provide?
- Real call recordings including the difficult ones, a supervisor who can give a few hours a week, someone who owns the telephony and can answer questions about the SIP trunk and routing, a decision-maker for escalation policy, and system access in week one. The last one is the most common reason a deployment slips.
Keep reading