How to automate Slack standups: the report nobody reads

An automated standup is easy to set up and follows a predictable arc: it launches, people answer properly for a fortnight, then the answers become a restatement of the ticket board, and within a month nobody reads anybody else's. The thread is still posted every morning and it coordinates nothing.

The failure is not the format. It is that most standups have drifted into reporting — everybody accounting for their day to a channel — when the thing a standup exists to do is surface the small number of situations where somebody needs somebody else.

What we'll cover

• What a standup is for
• Why the daily log stops being read
• The blocker is the whole point
• Building it with CodeWords
• Questions worth asking
• Timing, threads and time zones
• Pulling what the tools already know
• What the summary should actually say
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

What a standup is for

Finding where somebody is stuck, so it does not stay stuck for three days.

Noticing duplication, where two people are unknowingly working on the same thing.

Catching the mismatch between what the team thinks is happening and what is happening.

Not reporting progress. The board already holds that and repeating it in prose adds nothing.

Not attendance. A standup used to confirm people are working is a different instrument with different effects on behaviour.

Not a status update for a manager, which is a legitimate need and should be met by something else rather than by repurposing a coordination ritual.

Why the daily log stops being read

It restates the board. Anybody who wanted that could look.

Volume defeats it. Eight people writing three lines each is a wall nobody reads daily.

Nothing requires a response, so reading it has no consequence and people stop.

It rewards the appearance of productivity, which changes what people write within weeks.

There is no summary, so any pattern across the responses is invisible.

Nobody owns it. An unowned ritual continues indefinitely because stopping it requires a decision.

The blocker is the whole point

Ask about it specifically, as its own question, not as a third bullet people leave blank.

Make "no blockers" the easy answer, so the ones that appear are real.

Route them, immediately, to somebody who can help rather than to a channel where everyone assumes somebody else will.

Track how long they last. A blocker in its third day is a different thing from one raised this morning, and only the automation can see that.

Report the pattern. Blockers of the same type recurring is a process problem, and it is invisible when each is resolved individually.

Escalate the old ones, since the failure mode of a written blocker is that it is acknowledged sympathetically and then persists.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so Slack, the tracker, the calendar and the repository can meet in one automation.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: the questions, the timing, how blockers are routed, and what gets summarised.
3. Authorize the connections — Slack, the issue tracker, and the calendar.
4. Describe the exceptions: somebody on leave, a person who has not responded, a blocker older than a defined period.
5. Run it for two weeks and check whether anybody acted on anything in it.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Questions worth asking

What would you like help with? — which is the blocker question phrased so people actually answer it.

What changed since yesterday that others should know? — which filters for relevance rather than asking for a list.

What are you working on today? — one line, which is worth keeping mainly for catching duplication.

Not what you did yesterday, which is where the reporting tone comes from and which the board already records.

Not an estimate of completion, which produces defensive answers and no useful information.

Two questions is usually right. Three is the maximum, and each additional one reduces the quality of the answers to all of them.

Timing, threads and time zones

A window, not a moment, so nobody is answering at an artificial time for them.

In a thread, always, or eight responses bury the channel every morning.

Post the summary in the channel, not the individual responses, which inverts the usual arrangement and is what makes it readable.

Remind once, privately, and never publicly chase somebody for not having answered.

Respect leave and holidays automatically, since asking somebody on holiday for a standup update is the fastest way to make the whole thing resented.

Distributed teams need asynchrony to be real. If the summary is written before half the team has woken up, the arrangement is synchronous with extra steps.

Pulling what the tools already know

What moved on the board does not need typing, and asking for it is what makes standups feel like administration.

Merged and opened work, from the repository, which is factual and free.

What is in review, waiting for somebody, which is a blocker nobody labels as one.

Meetings today, from the calendar, which explains a great deal about who has capacity.

Pre-fill the answer and ask for confirmation and additions, which takes thirty seconds instead of three minutes.

Leave the judgement to the person. The tools know what happened and not what it means, which is the only part worth a human writing down.

What the summary should actually say

If the responses live in a thread, the channel message is the product, and writing it well is what decides whether the arrangement survives.

Lead with the blockers, named, with who could help. If there are none, say so in three words and stop.

Note the collisions. Two people working near the same thing is the finding a summary can produce and an individual response never can.

Say what is different from yesterday, rather than restating the same shape of update daily.

Name who is away, since that answers several questions people would otherwise ask individually.

Keep it to a few lines. A summary as long as the responses has solved nothing.

Do not rank or score anybody. A summary that implicitly compares people changes what they write within a week, and what they write is the input to everything above.

Making it survive

Handle non-responses gracefully — a missing update is not a report to anybody.

Make reminders idempotent, so nobody gets chased twice.

Respect a global message frequency cap, since this is one of several automations contacting the same people.

Handle Slack outages by holding rather than skipping the day silently.

Report the outcome: response rate, blockers raised and resolved, blocker age, and whether anybody replied to anything.

Limits worth knowing about

An automated standup cannot create psychological safety. If people do not say they are stuck, the format is not the reason.

Written coordination is slower than a two-minute conversation for anything complicated.

Response rates fall over time, always, and are worth watching as the health signal for the whole thing.

It cannot replace a conversation for a team that genuinely needs to coordinate closely.

Retiring it is a valid outcome that nobody chooses because no one owns the decision.

What to build first

The blocker routing. Ask the blocker question on its own, and when somebody answers, send it directly to a person who can help rather than leaving it in a thread. Track how long it takes to clear. That is the entire value of a standup, delivered without requiring anybody to read a daily log.

Two habits make the difference. Post a summary in the channel and keep the individual responses in a thread, since that single inversion is what makes the output readable. And give the standup a named owner and a review date, because an unowned daily ritual runs for years after it stopped coordinating anything.

Frequently asked questions

What is a standup actually for?

Finding where somebody is stuck, noticing duplicated work, and catching mismatches between what the team thinks is happening and what is. Not reporting progress, which the board already records.

Why do automated standups stop being read?

They restate the board, eight people's responses become a wall nobody reads, nothing requires a response so reading has no consequence, and there is no summary — so any pattern across responses is invisible.

What is the most important question?

The blocker, asked on its own rather than as a third bullet people leave blank. Phrase it as "what would you like help with", which people answer far more readily.

What should happen to a reported blocker?

It should be routed to a specific person who can help, not left in a thread where everyone assumes somebody else will. Track its age and escalate the old ones, since the usual failure is sympathetic acknowledgement followed by persistence.

How many questions should a standup ask?

Two, three at most. Each additional question reduces the quality of the answers to all of them, and "what did you do yesterday" is the one to drop first.

Should responses go in the channel?

No — responses in a thread, summary in the channel. That inversion is what makes the output readable and is the single most effective change to a struggling standup.

What can be pre-filled automatically?

What moved on the board, what was merged or opened, what is sitting in review, and what meetings somebody has today. Pre-fill it and ask for confirmation, which turns three minutes of typing into thirty seconds of judgement.

When should a standup be stopped?

When nobody acts on anything in it for a month. Give it a named owner and a review date at the start, since an unowned daily ritual runs for years after it stopped coordinating anything.

What should the channel summary contain?

Blockers first with who could help, collisions between people working near the same thing, what is different from yesterday, and who is away. A few lines. A summary as long as the responses has solved nothing.

Should a standup summary compare people?

Never. An implicit ranking changes what people write within a week, and what they write is the input to the only useful thing a standup produces.

Is an async standup as good as a conversation?

For coordination, usually adequate. For anything complicated, no — written exchange is slower, and a team that genuinely needs to coordinate closely will do it in a call regardless of what the automation posts.

What is the health signal for a standup?

The response rate, watched over months. It falls in every implementation; how fast it falls tells you whether the standup is still doing something.

Related reading

• Automating a weekly team digest
• Automating meeting scheduling
• Automating task assignment