{"id":935,"date":"2026-10-26T18:40:00","date_gmt":"2026-10-26T18:40:00","guid":{"rendered":"https:\/\/flyaiaa.com\/blog\/?p=935"},"modified":"2026-10-26T18:40:00","modified_gmt":"2026-10-26T18:40:00","slug":"chatops-compared-dms-channels","status":"publish","type":"post","link":"https:\/\/flyaiaa.com\/blog\/chatops-compared-dms-channels\/","title":{"rendered":"Three Ways to Run Ops: DMs, Channels and ChatOps"},"content":{"rendered":"

Two flight-support coordinators once ran the same kind of operation \u2014 charter bookings, crew changes, handler requests, weather calls \u2014 in two completely different ways. One lived in direct messages; the other moved her team into a shared channel and eventually into ChatOps<\/strong>, where a bot posts events and executes only the commands it has been cleared to run. Their stories make the cleanest comparison of the three ways teams coordinate operations that I know, and the practice they converge on is documented in depth at the Ops Atlas’s ChatOps entry<\/a>. Here is the comparison, told as it happened, trade-offs and all.<\/p>\n

Way One: The Direct Message Office<\/h2>\n

The first coordinator, at a small charter desk, did everything through private chats and phone calls. It felt efficient. Requests went straight to the person who could act, no committee, no audience. The bill arrived later, in three currencies. The first was continuity: when he caught flu, nobody knew which handler in Nice had been promised what, because the promises lived in threads only he could read. The second was accountability: a catering change nobody could attribute turned into a billing dispute with no receipt of approval. The third was speed, ironically \u2014 every request queued behind his attention. Direct messages hide work, and hidden work has a way of resurfacing at the worst moment, usually as the question nobody can answer: who authorised this?<\/p>\n

Way Two: The Channel That Only Talks<\/h2>\n

The second coordinator started simpler than full automation. Her team moved everything into one shared channel, and a bot posted events: aircraft position updates, weather holds, schedule changes, fuel releases. No commands, no magic \u2014 just announcements everyone could see. The improvement was immediate and measurable. New joiners read a week of history and understood the operation. Overlaps got caught because two people saw the same event at once. Noise was the failure mode, and she learned to fight it editorially: group related updates into one message, cut anything a competent colleague would scroll past. Published numbers explain why that discipline matters \u2014 in one documented example only 23% of notifications were actionable against a 50% target, and ungrouped alert traffic costing twelve people ten seconds apiece across four hundred weekly messages adds up to thirteen hours of lost attention. A channel that only talks solves visibility. It does not, by itself, solve action: the restart, the re-booking, the release still happened in whatever tool lived outside the chat, unrecorded and unpermissioned.<\/p>\n

Way Three: Full ChatOps, Where the Channel Can Act<\/h2>\n

The third stage is where the channel stops being a noticeboard and becomes a control surface. Her team allowed the bot to execute a small, explicit set of commands: request a crew car, resend a handling request, move a pickup time \u2014 each matched against an allow-list, each refused politely if it fell outside the list or the requester lacked the role. Free text never touched a shell; the bot pattern-matched or it declined. Every execution, every result, every refusal landed back in the thread. Consequential moves \u2014 anything that cost money or touched passenger data \u2014 required a second, distinct approver, which is the two-person rule, with a documented emergency bypass for genuine disruptions.<\/p>\n

The quiet revolution was in the plumbing. Requests were verified as genuinely coming from the platform before anything ran \u2014 each service proves origin differently, from cryptographic signatures with short acknowledgement windows to signed tokens to, in one well-known case, a static token that leaves the message body unprotected and is therefore treated as weak. Senders were mapped to permanent account IDs, not display names, because anyone can rename themselves. And the audit trail was written to a system outside the chat, since history in a channel expires and edits, while an audit record must do neither. The lineage here is long: GitHub’s Hubot dates to 2011, the term itself to Jesse Newland’s February 2013 talk, and by the mid-2010s the practice had its defining case \u2014 hundreds of deploys a week flowing through a guarded, locked chat queue. Chat has been a legitimate control surface for over a decade.<\/p>\n

The Day That Settled It<\/h3>\n

What converted the sceptics on her team was an afternoon of weather chaos, the kind every charter desk eventually meets. Under the old direct-message office it would have been an hour of “are you handling this?” and two duplicate calls to the same handler. Instead the channel ran the disruption like a script. One command declared the disruption and opened a dedicated thread; the paging command brought in the duty manager; each decision \u2014 rebook, delay, swap \u2014 was requested and approved inside that thread, with the two-person rule engaging on the one passenger-data change; and when the weather cleared, the timeline was already written, so the archive command closed a complete record. Nobody reconstructed what had happened from memory afterwards, because nobody had to. Teams in software describe the same arc with incident automation \u2014 declare, create, page, timeline, archive \u2014 and with paging commands built to fail loudly, falling back to a second route when the first is unreachable, and reporting changes rather than restating unchanged states. The principle transfers intact: emergency tooling earns trust by being loud about failure and quiet about stability.<\/p>\n

One further refinement matters for anyone scaling this up. Keep the state somewhere other than the channel. The most famous deployment queue in software eventually moved its state into a proper state machine with a graphical interface, leaving chat as the trigger \u2014 summoned work, remembered elsewhere. A channel that doubles as the database turns every migration into archaeology, scrolling hundreds of messages to reconstruct what was actually true.<\/p>\n

The Honest Comparison<\/h2>\n

Laid side by side, the three ways trade off like this:<\/p>\n