The moment chat platforms opened their APIs, a particular idea took hold: if people already spend the day in a messaging window, bring the work to them. No more switching to a ticketing system to approve a request, no more logging into the ERP to check whether an invoice cleared. Ask in the channel, get an answer, approve with a button. A decade on, the verdict is clear and more nuanced than either the enthusiasts or the sceptics predicted. Bots in chat are excellent at a narrow band of work and consistently terrible at everything outside it. The organisations that got value from this pattern understood the boundary early. The ones that did not built conversational interfaces to processes that were never conversational, and quietly retired them.
The four things that actually worked
Notification with context. Not "a ticket was updated" but the ticket, the customer, the value, the change and a link — delivered into the channel of the team that owns it. This is the single highest-value bot pattern and the least glamorous. It works because it removes the polling behaviour that eats an operations team's day: no one has to keep checking a queue. Single-step approvals. Expense over a threshold, a purchase requisition, a leave request, a deployment to production. One decision, two buttons, recorded in the source system, visible to the team. Approval latency in most organisations is not a decision problem — it is an attention problem — and moving the decision to where attention already is collapses the cycle time. Read-only lookups. Customer status, order state, stock position, invoice ageing, who is on call. Fast, low risk, and it removes a login and three clicks from a question asked twenty times a day. Operational triggers with a clear contract. Restart a service, run a report, create a ticket, open an incident channel with the right people already in it. Well-defined verbs with predictable outcomes, executed under the requester's identity and logged. What unites all four: a single step, an unambiguous outcome, and no state to hold between messages.
| Interaction | Control to preserve |
|---|---|
| Contextual notification | Route an exception to its owning team |
| Single-step approval | Show the decision and write back the identity |
| Read-only lookup | Respect access to the source record |
| Operational trigger | Make the action predictable and logged |
| Multi-step collection | Link to a reviewable form or supported workflow |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Where it fails
The failure pattern is equally consistent. Multi-step processes in a chat window are worse than a form, and every organisation that has tried to build one has found the same set of problems. Conversation has no reliable state. A user starts a five-step request, gets interrupted by an actual conversation, comes back twenty minutes later and the bot has lost the thread — or worse, has not, and applies an answer to the wrong question. Forms hold state visibly; chat does not. There is no way to review before committing. A good form shows everything entered before submission. A conversational flow reveals one field at a time and then acts, which is an unpleasant property when the action moves money or changes a customer record. Error recovery is painful. Correcting field three of a seven-step conversational flow usually means starting again, and users learn this quickly and stop using it. And discoverability is close to zero. Nobody knows what the bot can do. Slash commands are invisible, help text goes unread, and capability that no one can find generates support requests rather than saving them. The most common end state for an ambitious bot deployment is a small group of power users who know the commands and everyone else asking them to run it. The design rule that emerged: if the interaction needs more than two exchanges, it needs a form. Use chat to notify, to decide and to launch — not to collect.
Practical Guidance for Workflow Automation Design
- Start with notifications carrying full context, not with conversational interfaces. Highest value, lowest build cost, and it changes team behaviour immediately.
- Cap conversational flows at two exchanges. Beyond that, send a link to a form and post the result back into the channel.
- Execute actions under the requesting user's identity, not a shared bot account. Otherwise every audit trail in the source system says the bot did it.
- Scope bot permissions tightly and review them like service accounts. A bot with broad write access to your ERP is a privileged identity that most access reviews miss.
- Make approvals record in the source system, not just in the chat thread. A decision that exists only as a message is not an approval when the auditor arrives.
- Design for discoverability or accept low usage. Contextual buttons on messages beat commands people have to remember.
- Instrument usage from day one and retire what nobody uses. Most bot estates accumulate dead commands that still hold live credentials.
- Decide which channels are records. Approvals and operational decisions in chat create retention, discovery and regulatory obligations that the platform default may not satisfy.
The Regional Dimension
In the Gulf, workflow-in-chat has a stronger business case than in most markets and a harder implementation path, for the same underlying reason: the volume of approval-driven, document-heavy process. Regional operating structures generate approvals at an unusual rate. Groups run multiple legal entities across mainland and free zones, often across several countries, with authority matrices that vary by entity and signatories who are frequently travelling. Payments, purchase orders, contract signatures, HR actions and government submissions all queue behind someone's attention. Approval latency is one of the most reliable sources of operational drag in a regional group, and it is precisely the problem that a well-built approval bot solves — not by changing the authority matrix, but by putting the decision in front of the approver wherever they are. The complication is that the incumbent channel is already messaging, and it is not the corporate platform. An enormous share of regional operational coordination and informal approval happens in WhatsApp groups: the site update, the "go ahead" on a purchase, the confirmation that a payment can be released. This creates a specific and underrated risk. An approval given in a personal messaging app is not recorded in any system, leaves the company when the employee does, and is close to useless in a dispute, an audit or a fraud investigation — and the region's history of payment fraud through spoofed instruction channels makes that more than a theoretical concern. The strongest argument for moving workflow into a governed chat platform here is not convenience; it is that the approval becomes evidence. Three further local design considerations. Government and regulatory submissions — e-invoicing clearance, WPS salary files, visa and labour transactions, VAT and corporate tax filings — have status that people currently check by logging into portals; a status-notification bot against those workflows is often the highest-value integration available, though many portals restrict automated access, so read the terms before building. Bilingual operation matters: a bot that posts only in English into a channel where half the team works in Arabic will be read by half the team. And multi-entity awareness is essential — a bot that routes an approval without knowing which legal entity the transaction belongs to will route it to the wrong person, repeatedly.
The objection worth taking seriously
The honest criticism is that moving work into chat frequently increases interruption rather than reducing it. The argument for bots was fewer context switches. The observed result in many deployments was more of them, because the same channel now carries conversation, notification and work, and every automated message arrives with the same urgency signal as a colleague's question. Teams that piped every system event into their channels discovered that a channel producing hundreds of automated messages a day is a channel nobody reads — and the notifications that mattered were lost alongside the ones that did not. Routing all notifications to dedicated channels and tuning aggressively is not a refinement; it is the difference between the pattern working and not. There is also a governance gap that took years to be taken seriously. Bots hold credentials and act on business systems, often with permissions granted generously during a hackathon-style build and never reviewed. Many were built by enthusiastic individuals rather than platform teams, and when those people left, nobody knew what the bot did or what it could reach. An inventory of chat integrations in a mature deployment is usually an uncomfortable document. And a fair operational point: automating an approval does not improve it. Making a bad approval chain faster produces faster bad decisions and, more often, a rubber stamp — a button pressed reflexively because it appeared in a channel between two conversations. Where approvals are a genuine control, the friction may be doing useful work, and the right intervention is to remove the approval step entirely rather than to accelerate it.
Common Questions
What is the best first bot to build?
A notification with full context into the channel of the team that owns the work — typically for exceptions, escalations or items breaching a threshold. It requires no conversational design, changes behaviour immediately, and is trivially measurable.
Should approvals happen in chat?
Single-step approvals with clear context, yes — provided the decision is written back to the source system with the approver's identity. Multi-step or judgement-heavy approvals belong in the system of record, with chat used only to prompt.
How should bot permissions be governed?
Exactly as service accounts: named owner, documented scope, least privilege, credential rotation, and inclusion in access reviews. Acting under the requesting user's identity rather than a shared bot identity solves most audit problems at the same time.
Do AI assistants change the two-exchange rule?
They relax it, and that creates a new problem. A language model can hold context across a longer conversation, handle corrections mid-flow and cope with an ambiguous request, so multi-step interactions that failed with rule-based bots are now workable. But a conversational interface that can be instructed in natural language can also be instructed by content it reads — a message, a ticket description, a document — and if that assistant holds write access to finance or HR systems, the injection risk is a direct operational risk. The practical position: let the assistant interpret, summarise and prepare, but keep the committing action behind an explicit human confirmation showing exactly what will happen, executed under the user's own permissions. The old rule was a usability constraint; the new one is a control.
Workflow Automation Design — notify, decide and launch in chat; collect in a form. The bots that survive are the ones with a single unambiguous job.