Messy intent in. Structured outcome out.
For twenty years, enterprise service has relied on a lazy assumption: it is easier to train a human to speak “database” than it is to train a computer to speak “human”.
You see it every time someone opens a portal.
Select category.
Select sub category.
Select urgency.
This is not help. It is data entry. We ask employees to do the pre processing work for the system. They translate a real world interruption (“my laptop is overheating”) into the rigid language of records and fields.
That translation work is the hidden cost of portal centric service. It is not just time. It is attention.
People-centric service flips the burden. The person starts with messy intent, in plain language, in the place they are already working. The system does the organising work behind the scenes.
The inversion: unstructured intent, structured outcomes
Traditional service experiences depend on structured input. The system only works cleanly if the user feeds it clean, labelled data.
Modern conversational experiences enable unstructured intent. A person can describe the problem the way they naturally would, and the platform can still produce a structured outcome: the right workflow, the right data fields, and the right routing.
Old Way: Human works hard to understand the Computer.
New Way: Computer works hard to understand the Human.
This is not a small UX tweak. It changes what “good” looks like.
A good experience is not “did the user choose the right category”.
A good experience is “did the user reach an outcome with minimal translation effort”.
When the system does not understand intent, we compensate with forms, menus, and taxonomies. When it can understand intent, we can design for momentum.
Why this shift is possible now
Virtual agents used to be thin wrappers over decision trees. They were portals with a chat bubble, asking the same ten questions in a different order.
What changed is language understanding.
Modern NLU and language models can interpret a messy sentence, identify what it is about, and pull out what matters. The agent can take:
“My VPN keeps dropping and I have a client call in ten minutes”
and respond with the right next step, or create a well formed case with a clean summary for a human to pick up.
This is the practical role of a virtual agent now. Not a chatbot. A translator.
The shift from storefront to engine room
In part one of this series, we described the service platform as the warehouse: the workflows, approvals, routing rules, knowledge, audit trails, and ownership that make service possible.
The portal does not disappear. Its role changes.
It becomes the engine room for high assurance work. Most people should not need to “visit” it to get momentum on everyday interruptions.
The question is not “portal or chat”.
The question is “how much translation work do we push onto the user”.
This only works when the engine room is ready: knowledge is owned, permissions are reliable, workflows exist, and handoff paths are clear.
Where chat wins
Chat based experiences in collaboration tools win when the goal is speed, confidence, and staying in flow. These are high frequency, low risk moments where friction kills adoption:
- “Is there an outage right now?”
- “What is the status of my request?”
- “Reset my password”
- “Unlock my account”
- “I need VPN help”
- “Who owns this service and how do I contact them?”
They also support a different operating model. When something is urgent, people naturally swarm. They ask a question in a channel, tag someone they trust, or message a teammate. A good service experience should harness that behaviour, not fight it.
The goal is not deflection. It is friction reduction: fewer steps to start, fewer back and forth loops, and a clean handover when a human is needed.
The Engine Room: High Assurance Work
Some work should stay structured, because the cost of being wrong is high, or the work is genuinely multi step.
Use a form or guided workflow when you need strong guardrails and precise data:
- Joiners, movers, leavers
- Procurement and asset lifecycle
- Privileged or regulated access
- Major change and outage planning
- Anything that needs a reviewable record
People centric design simply refuses to make this the default for everything.
The best pattern is often: start in chat, capture intent, ask only what is essential, then hand off into a high assurance flow with context pre filled.
No repetition. No “start again”.
The real metric: attention saved
Ticket volumes tell you how much work entered the system. They do not tell you how much effort it took for the business to get help.
A people centric metric is simpler: how much translation work did we remove from the user?
You can measure this in practical ways:
- Time to start (from “I need help” to the first meaningful step)
- Number of clarification loops
- Completion rate without escalation
- Time to first meaningful response
- Drop off rate (people abandon and route around the process)
If those improve, you are returning attention to the business.
People centric design principles
- Design for intent, not taxonomy. People describe needs, not categories.
- Make the system do the translation work. Structured outcomes should not require structured input.
- Keep people in flow. Meet them in the tools where work already happens.
- Ask fewer questions, later. Collect the minimum needed to start, then progressively disclose.
- Never make someone repeat themselves. Carry context from chat to workflow to human handoff.
- Put heavy work in the engine room. Use forms when risk and governance demand it.
- Measure effort, not just volume. Optimise for attention saved and momentum restored.
A practical next step
If you want a structured way to identify your best starting intents, map where translation effort sits today, and shape a sensible pilot plan, you can explore the Intent First Virtual Agent Assessment.
The destination portal is not dying because portals are bad. It is fading because work moved on. People centric service is what happens when we stop forcing humans to speak database, and start designing systems that speak human.