I have developed a pretty simple test for conversational technology: if I tell your chatbot what I need and it responds by making me choose from six categories, we are not having a conversation. I’m filling out a form in disguise.
We have been doing this to people for years. First, it was phone trees. Then came service portals with giant grids of categories. Now, we have bots asking the same questions in little speech bubbles and pretending the experience is conversational because the interface looks like texting. The technology has changed, but the burden on the user is still the same.
AI gives us a chance to rethink self-service more fundamentally. A conversational experience should let people approach IT roughly the way they would approach another person: explain what they need, provide whatever context they have, and let the service work out the best way to help.
Users shouldn’t have to choose the technology
Traditional self-service portals ask people to make a surprising number of decisions before they get to what they want. Search the knowledge base or browse the catalog? Open a ticket or talk to the virtual agent? Pick “Software Access” or “Install Applications”?
The colleague in need does not care about any of these distinctions! They have an intention: “I need access.” A conversational experience should start there and do as much of the translation as possible behind the scenes.
One of the ideas behind the self-service portal redesign we have been working on at InvGate is using a conversational interface so that the user can simply start. Short text can behave like search and surface an immediate answer, relevant knowledge, or a catalog item. An attachment, voice input, or more complicated explanation can open a conversation with the Virtual Service Agent.
There is some fairly sophisticated routing happening underneath that experience, but the important design decision is that the user does not need to understand it. Search versus chat should be our problem. People should get to choose the experience they want with as little friction as possible.
Enterprise software has a bad habit of exposing its architecture to users and then requiring they repeat it back from memory to navigate! We present five ways to get help because the system contains five different mechanisms for providing it. That makes perfect sense to the people who configured the software, and considerably less sense to everybody else. Tesler’s law gets proven again and again.
Conversation is mostly about context
Another good test of a conversational experience is whether the system remembers what you just told it. We have all dealt with the opposite: you explain your problem to a bot, it sends you elsewhere, the next screen asks for the same information, and eventually a human joins and asks you to explain it again.
Context needs to travel with the user. If someone says they cannot connect to the VPN from a hotel and attaches a screenshot of the error, the system should use that information to search, answer, troubleshoot, route, or create a request without forcing the person to reorganize the problem into whatever fields happen to exist in the backend system.
This is where natural language is genuinely useful in Service Management. People do not experience their problems in catalog taxonomy. They experience something getting in the way of their work and describe it using whatever information or emotion makes sense to them. Our systems should be doing more of the translation.
There is also a trap here. Once organizations invest in a virtual agent, they tend to want people to talk to it even when talking is unnecessary. If somebody asks a simple question and we already know the answer, give them the answer. If they came to check whether their laptop request has been approved, show them the status. Nobody opens an IT portal because they are hoping for a rich conversational experience. They want something resolved.
That is why conversational design has to reach beyond the chat window. In our redesigned portal, the home page also changes according to the person, so someone with nothing pending sees a much cleaner experience than a manager with several items waiting for approval. The interface is responding to context before the user has typed anything.
When someone selects their path, believe them. Someone who clicks to search expects search. And the new interface is becoming LLM.
People have preferences, your portal should keep up with them (Jakob’s Law).
Please stop making bots pretend to be people
There is one part of “conversational” technology that drives me crazy: the theater.
“Hi Matt! 👋 I’m ITBot, your super-friendly digital helper! How can I make your day AMAZING?”
Please just reset my password.
We keep trying to make software conversational by giving it personality when we should be making it useful. People are perfectly capable of understanding that they are interacting with software.
What makes a conversation feel good is much more practical. The other party understands what you mean, remembers what you said, gives you a useful answer, and does not waste your time. A good system should recognize when it cannot help and hand the situation over cleanly instead of trapping somebody in a loop because the virtual agent is desperate to hit its containment target.
I would rather have a boring bot that understands me than a charming one that sends me back to the service catalog.
A conversational experience is only as good as its knowledge
Making self-service easier to approach means more people will use it, so the quality, accuracy and timeliness of the answers matters even more.
Generative AI makes it tempting to think the model itself is the knowledge source. For enterprise service, I think that is backwards. The useful model is one that can take knowledge the organization already trusts and make it easier for people to access and understand.
In InvGate Service Management, the Virtual Service Agent can answer from approved knowledge base content and from Knowledge Snippets extracted from previously resolved tickets. Those snippets still go through human review before they become usable knowledge.
Thinking in cycles like this develops the data your agents (virtual and literal) need to do their jobs so well.
A great answer behind a weird conversation is painful, and a fluent wrong answer is still a wrong answer. Bad knowledge wrapped in confident natural language is much easier to fool people into wasting their time than an obviously outdated knowledge article from 2019.
Look at the outcome, not the chatbot
The goal is not chatbot adoption.
I would be very cautious about celebrating that 70% of employees interacted with a virtual agent this month. Maybe they loved it. Maybe your portal made them fight a robot before they were allowed to speak to anyone.
The better measure is what happened after the interaction. Did the person get what they needed? Did the system preserve enough context to avoid making them start over? If the issue needed a human, did that person inherit enough information to continue sensibly?
Even better is understanding agent performance and technology adoption levels. When you’ve got agents who struggle to balance workloads or
Every question answered accurately on the spot is work that never needs to enter a queue. Every status check handled without opening a ticket saves one person from typing “Any update?” and somebody else from typing “Still working on it.”
Conversational service should make the machinery of Service Management less visible to the people using it. Let them explain what they need in their own terms, preserve the context they provide, and find the shortest useful path to an answer or resolution. Sometimes that path is a conversation. Sometimes it is search, a status update, an approval button, or a human being.
If the user has to learn how your conversational experience works before it can help them, it probably is not very conversational yet.