Should we have a #decisions channel in Slack?

It's better than nothing and a fine place to start: post the verdict, reason, and owner there whenever a thread closes. But it inherits Slack's problems: no structure, no supersede history, search by keyword only. Treat it as the inbox for a real log, not the log itself.

What should a decision record from a Slack thread contain?

Four fields: the verdict as one imperative sentence, the reason it was made, the alternatives that were rejected, and who agreed, plus a review date if the call is temporary. Link the original thread for the full debate.

How do we get the team to actually record decisions?

Lower the cost, don't raise the pressure. Make the format tiny, make the decider responsible for closing the thread, and backfill whenever someone asks a question that a record would have answered. Habits that require discipline from everyone fail; habits owned by one named person per decision mostly hold.

How do we stop product decisions getting lost in Slack?

Slack is where decisions happen, not where they survive. Keep deciding in threads (that part works), but capture the verdict somewhere permanent at the moment it's made: one sentence, the reason, the rejected options, who agreed. Teams that succeed make capture a reflex tied to the decision, not a cleanup job for later.

Product decisions do get made in Slack, and that part works: the debate is fast, the right people are in the thread, the call gets made. What fails is everything after. The verdict lives on page four of a thread, findable only by people who already know it exists.

Why Slack loses decisions

Slack is a stream, not a record. Three mechanisms do the damage.

The thread never closes. Most Slack decisions are implicit: someone proposes, two people thumbs-up, the topic moves on. Nobody states the verdict, so there's nothing to find later. Just a debate with no visible winner.

Search returns messages, not conclusions. Searching "pricing page" surfaces forty messages across six channels, with superseded takes ranked equal to the final call. To learn the answer, a reader has to re-run the whole argument.

And the record decays. People leave and take context with them. Channels get archived. History gets truncated. A decision that lives only in Slack has a half-life.

The standard fix ("someone should write these up") fails for a predictable reason: it asks a person to leave the conversation, open another tool, and file. Filing loses to shipping every time.

What actually works

Close threads explicitly. When a call lands, the decider posts one final message: the verdict as a single imperative sentence. "Verdict: we ship usage-based pricing; seat-based is out." Mark it with a fixed emoji so it's scannable. An unstated decision is the root failure; everything else builds on this.

Use a tiny, fixed format. Verdict, reason, rejected alternatives, who agreed, with a review date if the call is temporary. That's the whole decision log entry; a copyable version is in the decision log template, and the longer list of optional fields is in what a decision register should store. If it takes more than a minute to write, the format is too heavy and it will be skipped.

Route verdicts to one durable place. A #decisions channel, a doc, a log: the medium matters less than there being exactly one, outside the stream, append-only. When a decision is reversed, add a successor entry; don't edit history.

Filter hard. Log a decision only if it will constrain how someone builds or plans later. Most threads fail that test, which is what keeps the log short enough that people trust it and read it.

Make the decider own the close. Habits assigned to "the team" die. Habits assigned to the one person who made the call mostly survive.

Is a #decisions channel enough?

It's a good start and an incomplete finish. A dedicated channel fixes the first problem (verdicts stop being buried on page four of a debate) and it notifies people, which a doc doesn't. But a channel is still a stream: search still returns messages rather than the current answer, a reversal is just a newer message with nothing linking it to the call it replaced, and history is subject to the same retention limits as every other channel.

The pattern that holds up is both: post the verdict in the channel for visibility, and link it to an entry in a durable decision log that keeps status (active, superseded) and points from old entries to their replacements. The channel is the announcement; the log is the record.

The same failure shows up off Slack, too: calls that land in a meeting evaporate for the same reasons, covered in how to track decisions made in meetings.

Where Lockstep fits

Lockstep exists because the filing step is where every manual version of this dies. It watches the Slack channels where your product and engineering work happens (Notion too; Jira, Confluence, and Google Docs support is newer), drafts the decision record with its reason, and the owner approves it in one click, so the record stays ahead of reality instead of behind it. We're at design-partner stage, and it's Apache-2.0 if you'd rather self-host. See how it works, or how it compares to keeping decisions in Notion. If you're picking a manual log instead, start with our decision log software comparison or the Notion alternatives for tracking product decisions.