A robot bought with enthusiasm and parked in a storeroom eight months later is a familiar sight. The causes are consistent enough to be listed, and almost none of them are technical faults.
The pattern of failure
It follows a recognisable sequence.
Months one and two. Enthusiasm. Customers photograph it, staff show it to visitors, management is pleased.
Months three and four. Novelty fades. Customers stop paying attention. The robot answers a narrower and narrower set of questions.
Months five and six. Content drifts out of date. It gives a wrong price, or does not know about a new item. Staff begin steering customers away from it.
Month seven. A fault occurs. Nobody is clearly responsible for reporting it. It sits unrepaired.
Month eight. It is moved out of the way, and then out of sight.
The critical point is months three to five. That is where the outcome is decided — not at purchase and not at installation. Deployments that survive that window generally continue; those that do not, do not recover.
The causes, in order of frequency
Nobody owned it. The most common cause by a clear margin. Everyone was pleased to have it and nobody was responsible for it. Content ages, faults go unreported, and the machine quietly stops being used.
Content was never maintained. A robot that gives one wrong answer in front of a customer loses staff confidence permanently, and staff confidence is what keeps it in service.
Staff were not brought in. Where staff saw it as a threat or an imposition, they did not defend it, did not report faults, and did not steer customers toward it.
The scope was wrong. It was bought to do something it was not capable of, and the disappointment was structural rather than fixable.
Support was inadequate. A fault took weeks to resolve and the gap became permanent.
The physical placement was wrong. Out of the customer path, or in a spot where it could not manoeuvre, so it was simply not encountered.
What the successful ones have in common
Consistent and unremarkable.
A named person responsible. Not a committee. One person whose job includes the robot, with time allocated for it.
A content review rhythm. A set interval — monthly is typical — where someone checks what the robot has been asked and whether the answers remain correct.
A narrow, well-defined job. Successful deployments do one thing well. Failures try to do everything.
Staff who see it as helping them. Usually because it absorbed a task they disliked rather than one they valued.
A defined escalation route. Everyone knows what to do when the robot cannot handle something.
Realistic expectations set at the start. Where management understood from the beginning what it would and would not achieve, ordinary limitations were not experienced as failures.
The staff question specifically
Underestimated more often than any other factor.
Staff decide whether a robot is used. They can direct customers to it or around it, report faults or ignore them, keep content current or let it rot. None of this appears in a purchase decision and all of it determines the outcome.
Announce it before it arrives. A robot appearing without warning reads as a decision made about people rather than with them.
Say plainly what it means for their jobs. If nobody is being replaced, say so directly. If roles will change, say what to. Ambiguity is worse than unwelcome clarity.
Give it the task they least enjoy. The fastest route to acceptance.
Involve them in the content. They know what customers actually ask, which is different from what management assumes.
Let them switch it off. Staff who can stop the robot during a busy period are far less resistant than those who cannot.
Judging at six months, not one
A point about evaluation.
The first month tells you nothing. Novelty inflates every measure — interactions, attention, apparent satisfaction. Judging on that data produces the wrong conclusion in both directions.
Month six is where the real figures are. Whether it is still used, whether content is current, whether staff engage with it, whether it saves the time it was meant to save.
Measure the specific thing you bought it for. If it was to reduce repeated questions at reception, count those. General satisfaction figures conceal more than they reveal.
Ask staff directly. Whether it helps or gets in the way. The answers are usually blunt and accurate.
Be prepared to conclude it was not worth it. Sometimes the honest answer is that the task did not need a robot. Recognising that is not a failure — continuing to fund something that does not work in order to avoid admitting it is.
Frequently asked questions
When is the outcome of a deployment decided?
Months three to five, when novelty has faded and routine has not yet formed. Deployments that survive that window generally continue; those that do not rarely recover.
What is the most common cause of failure?
Nobody owning it. Everyone is pleased to have the robot and nobody is responsible for it, so content ages, faults go unreported and the machine quietly stops being used.
Why do staff matter so much?
They decide whether a robot is used — they can direct customers to it or around it, report faults or ignore them, keep content current or let it rot. None of this appears in a purchase decision.
When should a deployment be evaluated?
At six months, not one. Novelty inflates every first-month measure. Month six shows whether it is still used, whether content is current and whether it saves the time it was meant to save.
More in Robots in Vietnamese business and Myths and questions.
