Sooner or later a client will ask for ChatOps, usually after watching a competitor’s deploy bot announce releases in a shared channel. The idea is simple enough to explain in one sentence — operational work runs through shared chat, a bot posts events and executes commands from a reviewed list, and everything stays visible, permissioned and logged — but delivering it as a freelancer is a different matter. You are not there to babysit the thing forever. You need a delivery plan that produces a working setup, a trained owner and a clean exit. Here is the nine-step sequence I now follow on these engagements, with the mistakes from earlier contracts baked in as warnings.

Step 1: Inventory the Work Before Selling the Bot

Start where every honest engagement starts: a list of the operational actions the team actually performs by hand. Restarts, deploys, cache clears, page-outs, status checks, log fetches. For each one, mark whether a clean API exists behind it. Anything requiring clicks in a console is out of scope for now. This inventory does double duty: it sizes the contract honestly, and it stops you from promising a bot that commands systems the client has never exposed an endpoint for. Ten to fifteen automatable actions is a healthy starting catalogue for a mid-sized team; more than that usually means the client already knows what they want, which is a nicer problem.

Step 2: Design the Channel Map on Paper First

Decide which channels exist, who belongs in each, and what class of command is permitted where, before any code is written. A deploy channel is not an incident channel; an incident channel is not a general chat. One rule saves hours of pain later: address channels by their immutable identifier in the bot’s configuration, never by name, because names get renamed and a renamed channel silently reroutes output to whoever inherits the old label.

Step 3: Build the ChatOps Trust Chain Before Any Command Exists

The order of checks never changes, and building it first means every later command inherits the protection for free:

1. Verify the request genuinely came from the chat platform. Slack signs its requests — check the HMAC-SHA256 signature, honour the five-minute replay window, and answer within the 3,000-millisecond acknowledgement budget. Teams delivers signed JWTs. Mattermost typically issues a static token that authenticates the sender while signing nothing in the body — the weakest of the three arrangements, and the one that needs compensating checks.
2. Map the sender to an immutable user identifier. Display names are costumes; do not authorize against them.
3. Authorize the identifier against written policy: person, channel, command.
4. Require approvals where the stakes warrant them.
5. Record the outcome in append-only storage that sits entirely outside the chat platform’s reach.

That last item is the one clients skip until an auditor mentions it. Chat scrollback is not an audit log — it can be edited, it expires under retention rules, and it vanishes with the product. Keep the log append-only and outside the platform.

Step 4: Grade the ChatOps Risks in Writing, With the Client in the Room

Every command gets a tier before it gets built. Tier 0 posts information. Tier 1 reads state and changes nothing. Tier 2 performs a reversible write and demands a defined role in a defined channel plus a log entry. Tier 3 is reserved for the actions that keep clients awake, and it requires two people to authorize — the two-person rule, familiar from any serious change process — alongside a break-glass override for genuine emergencies, itself logged and reviewed. Getting the client to sign this ladder does more for the relationship than any demo: it shows them you think about their risk, not just your deliverables. Security frameworks formalize the same instincts — dual authorization appears in NIST’s access-control family as AC-3(2), and the audit content requirements map to AU-3 — which gives you something to cite when someone asks why the dangerous commands are inconvenient.

Step 5: Ship Read-Only First, Reversible Second, and Stop There

The first command should read something — deployment status, queue depth — and change nothing. The second should do a reversible write, like triggering a pipeline with a guard. Then pause. Freelance contracts go wrong when the consultant chases the impressive tier-3 command in week one. Let the client experience the safe ones, hold a retrospective, and let them ask for more. They will, and by then the trust chain, the tiers and the audit are already proven. This pacing also protects your invoice: each expansion arrives as a fresh, pre-approved piece of work rather than scope creep buried in the original estimate. Clients remember consultants who told them to wait, and the memory pays off in the renewal conversation.

Step 6: Fix the Notification Firehose While You Are There

Most teams you arrive at are already drowning in channel noise, and a new bot that adds to it will be blamed for the whole flood. The arithmetic is sobering: an ungrouped stream of roughly four hundred alerts a week, glanced at by twelve engineers who each spend ten seconds deciding whether to care, burns about thirteen hours of collective attention weekly — for messages most people do not act on. Batch related alerts, route by severity, and measure the actionable share of notifications; one documented setup ran at 23% worth-acting against a 50% target, which tells you how common the firehose is. Alertmanager users should know a version quirk here: in 0.34, editing an existing message requires a bot token, because plain incoming webhooks cannot update what they posted.

Step 7: Treat Credentials as Half the Contract

Bot tokens, webhook URLs and API keys are the real payload of the engagement, and they deserve explicit line items. Keep secrets in a secret manager, not in config files; rotate on a schedule and at handover; and remember that webhook URLs are credentials, however casually they get pasted around. Note the failure mode of the confused deputy, where an automation framework runs everything under one shared account — StackStorm’s long-standing default of executing as chatops_bot is the classic case — and configure per-request identity mapping so the audit trail names the human who asked, every time.

Step 8: Instrument the Things a Grown-Up Will Ask About

Before you leave, make sure the setup can answer simple questions about itself. What fraction of production-touching changes flowed through the permissioned path — the audited change coverage figure, 93.9% in one documented example? How often do commands succeed — 98.1% in the same case? What is the refusal rate and its mix? How long do approvals sit waiting? If the client later hires someone full time, these numbers are what they will use to judge whether your work still holds up. Command counts and message totals will not help anyone; exclude them from the dashboard you hand over.

Step 9: Hand Over a ChatOps Owner, Not Just a Repository

The final deliverable is a person, named, who owns the allow-list, the secrets and the review rhythm. Write the runbook for them: how to add a command, how to read the refusal log, how to run the weekly refusal review and the quarterly scope audit. If the client needs a broader engagement shape around this — assessment, guardrails, enablement — the patterns in combining cloud computing and DevOps consulting services slot this work in neatly, and the ground rules in the FAQs for new DevOps freelancers cover the contracting basics this article assumes.

One last warning belongs in every handover document: platform churn. Legacy custom bots lost their Slack support in March 2025, Teams is shedding its Office 365 Connectors when May 2026 arrives, and Opsgenie’s shutdown notice points at April 5, 2027. Your architecture should keep the decision logic in a gateway you own, so the next retirement costs the client a week of adapter work rather than a rebuild. The ChatOps field reference at the Ops Atlas documents these dates and the rest of the evidence base, and it is the checklist I keep open while writing handovers. Deliver against it and the client’s memory of your contract will be the good kind: quiet, boring, and still working a year later.