A chat window is not a conversational interface

A company adds an assistant to its internal portal. A sales coordinator tries it on her first real question of the day: what is the status of the order for the northern distributor? The assistant answers with a paragraph from the help centre explaining what order statuses mean in general. She tries again with the order number. It replies that it does not have access to order data. She closes the panel and opens the ordering screen, as she did before.

A few months later the project report says adoption was low. The conclusion drawn is that people are not ready for conversational tools. The real conclusion is that they were not given one.

What they were given was a chat window placed on top of documents, instead of on top of the record and the actions. A conversation is useful when the other side knows who you are, can see the facts and can do something about them. A chat window with none of those is a search box that answers in full sentences.

Where chat-as-a-feature fails

It cannot see the record. The assistant answers from documents about the process rather than from the process itself. It can explain what “partially shipped” means. It cannot tell you which of your orders are partially shipped.

It does not know who is asking. The warehouse manager and the finance director get the same answer to the same question, although they need different things and are allowed to see different things. Without identity there is no relevance, and no safe way to show real data.

It either cannot act or acts without asking. The first version is a dead end: “you can change the delivery date in the ordering module”. The opposite failure is worse: an assistant wired straight to write operations, so a misread sentence becomes a changed order with nobody having looked at it.

It has no thread. Every conversation starts from nothing. Yesterday’s discussion about the same customer is gone, and nothing that was asked or decided is attached to the order it was about, so the next person starts again too.

It is judged as a feature, not as work. Success is measured in messages sent. The question that matters, how many tasks were finished faster or with fewer errors, is never asked.

What a conversational interface needs

Grounding in the company’s model. The answer to “what is the status of this order” has to come from the order itself: its lines, its delivery, its invoice, its open complaint. That requires a model of the business the conversation can query, which is what an ontology provides. Why this works better than searching documents is the subject of retrieval over the ontology.

Identity and permissions enforced on the server. The conversation inherits the rights of the person having it. The model never receives data the person may not see, and that is enforced where the data lives, not by an instruction in a prompt that a clever question can talk around.

Actions as proposals. “Move the delivery to Thursday and tell the customer” should produce a drafted change and a drafted message, shown to the person with the sources used, and executed only when they confirm. Critical steps wait for an approval from whoever is entitled to give it. This is the pattern Hurukan’s Agentic Logic layer is designed around: an agent proposes, a person decides on anything that matters.

A thread attached to the record. The conversation is stored with the order, case or supplier it was about, so the next person sees what was asked, what was decided and what was done.

A clean handoff to the screen. Some things are faster in a table. A good conversational interface knows when to open the right view with the filters already set instead of reading a long list aloud.

In Hurukan’s design, conversation is one way into the same record, the same agents and the same approvals, not a separate product with its own copy of the truth. Integrations with Microsoft 365 Copilot, Claude and ChatGPT are planned, not live; the intention is that people can talk to the system from the tools they already use while the facts, permissions and approvals stay in one place. Proposals that need a decision land in one approval inbox, described on the Decisions and Tasks page.

A test you can run today

Take the assistant you already have, or the one being proposed to you. Collect five questions a real employee asked a colleague this week; copy them from email or chat as they were written. Put each one to the assistant and score it on four points:

1. Did it answer from live data, or from a document about the process?
2. Did it know who was asking? Try the same question as two people with different roles.
3. Could it prepare the next step, and did it ask before doing anything that matters?
4. Tomorrow, could a colleague see what was asked and done, attached to the record?

If most of the answers are no, you have a chat window. That is fine for searching a handbook, and it is not a new way of working. The same four points apply when the hands are busy and the conversation is spoken, which is the subject of voice for hands-busy work.