Chat-first internal tools: why the interface is a conversation
Internal tools are built for the questions somebody anticipated. The questions nobody anticipated become tickets, and tickets are where an operations team’s week goes. A chat-first tool is a bet that a conversation, backed by the real systems and real permissions, can absorb the long tail.
What “chat-first” has to mean
- Answers come with their sources. A number without the query and the table it came from is a rumour.
- The conversation can take action, not only answer — draft the Slack message, update the row, retry the job — and the action is a reviewable proposal, not a side effect of a sentence.
- Permissions are the person’s, not the chat’s. Two people asking the same question get different answers when their access differs, and that is correct.
- A solved problem becomes an operation. When a conversation worked, it should be publishable as a reusable thing with named inputs and scope, so the next person does not have to rediscover it.
What it should not mean
Chat is not an excuse to remove structure. A pipeline is still a pipeline and should be shown as one; a proposed change is still a diff and should be shown as one. The conversation is the front door, not the whole house.
The measure of success
Fewer tickets that say “can someone check…”. Not fewer tickets overall — the real ones should still be filed, with the evidence attached — but the ones that were never really a ticket, only a permission somebody lacked.