Setting up blocker detection workflows

Blockers are the silent killers of team velocity. Someone is stuck waiting on an approval, a dependency, or a decision — and nobody finds out until the sprint review. Dailybot’s blocker detection workflows catch these stalls early by scanning check-in responses, triggering follow-ups, and notifying the right people.

This guide walks you through setting up blocker detection from scratch.

Prerequisites

Before you begin, make sure you have:

• An active Dailybot workspace with at least one check-in running
• Admin or manager permissions in your workspace
• A check-in that includes a blocker-related question (recommended but not required)

If your check-in does not already ask about blockers, add a question like “Is anything blocking your progress?” or “Do you need help with anything?” This gives Dailybot a clear signal to work with.

Step 1: Enable keyword detection

Open the check-in you want to monitor and go to the detection rules section. Enable keyword detection and add your trigger terms.

A good starter keyword list includes:

• blocked, blocking, blocker
• stuck, stalled, waiting on
• dependency, depends on
• need help, need access
• cannot proceed, can’t move forward

You can add team-specific terms too. If your team says “parked” when something is on hold, add that. If “waiting for legal” is a recurring theme, include it.

Dailybot scans each response as it comes in and flags any that match your keywords. Flagged responses are marked in the dashboard so you can spot them at a glance.

Step 2: Configure conditional follow-up questions

When a blocker is detected, you often need more context. Who owns the dependency? What exactly is needed? When is it needed by?

Set up conditional follow-up questions that trigger automatically when a blocker keyword is found. For example:

• “Who or what is blocking you?” — identifies the owner of the dependency
• “What do you need to unblock this?” — clarifies the action required
• “When do you need this resolved by?” — establishes urgency

These follow-ups appear as additional prompts in the same check-in conversation. The person answers inline, and the extra context is attached to the blocker flag in the dashboard.

Step 3: Set up manager notifications

Flagging a blocker in the dashboard is useful, but managers need to know immediately when someone is stuck. Configure notification rules to push alerts to the right people.

Direct message notifications — Send a DM to the team lead or manager when a blocker is detected. The notification includes the person’s name, the flagged response, and any follow-up answers.

Channel notifications — Post a summary to a dedicated channel (like #blockers or #team-health) so the whole team has visibility. This works well for cross-functional teams where the unblocking action might come from anyone.

Digest notifications — Instead of real-time pings, bundle blocker alerts into a daily or weekly digest. This is better for teams with high blocker volume where real-time alerts would create noise.

Choose the approach that fits your team’s culture. High-urgency teams benefit from real-time DMs. Larger organizations often prefer channel posts with daily digests for leadership.

Step 4: Create escalation rules

Some blockers do not get resolved quickly. Escalation rules make sure nothing falls through the cracks.

Define time-based escalation tiers:

Tier 1 — Immediate (0-4 hours): The direct manager is notified. This is your default notification from Step 3.

Tier 2 — Same day (4-24 hours): If the blocker has no update after 4 hours, notify the team lead and post to the team channel.

Tier 3 — Overdue (24-48 hours): If still unresolved after a day, escalate to the department head or project owner. Include the full blocker history in the notification.

Tier 4 — Critical (48+ hours): Flag in the weekly leadership report and trigger a dedicated unblocking session.

Adjust these timelines to match your team’s pace. A fast-moving startup might escalate after 2 hours. An enterprise team with longer cycles might wait 48 hours before the first escalation.

Example: A complete blocker detection workflow

Here is how it all comes together for a typical engineering team:

1. Morning check-in runs at 9:00 AM. Developer answers “I’m blocked on the staging environment — waiting for DevOps to provision new credentials.”
2. Keyword detection catches “blocked” and “waiting for.” The response is flagged.
3. Follow-up questions fire: “Who owns this dependency?” → “DevOps team.” “When do you need it?” → “Today, ideally before noon.”
4. Manager notification goes to the engineering lead via DM with full context.
5. Channel post goes to #blockers so DevOps sees it too.
6. 4-hour escalation — If no update by 1:00 PM, the VP of Engineering gets a ping.

The developer did not have to file a ticket, send an email, or chase anyone down. The workflow handled it.

Tuning your detection over time

After your first week, review the flags. Are there false positives? Remove keywords that trigger too often on non-blocker responses. Are blockers slipping through? Add new terms based on how your team actually describes being stuck.

Check your escalation metrics monthly. If most blockers resolve at Tier 1, your team’s responsiveness is strong. If many reach Tier 3 or 4, the underlying process — not the detection — needs attention.

Good blocker detection is a living system. Tune it, and it becomes one of the most valuable workflows in your Dailybot setup.