Workflow Automator

Workflow Automator

Transform a manual business workflow into an optimized automated system: map how work gets done today, then design a complete automated replacement with triggers, conditions, actions, branching, and error handling. Deliver a comprehensive workflow-automation.md.

Contents

• references/intake.md -- What to gather and how to ask for missing detail
• references/analysis-framework.md -- Current-state mapping, pain-point scoring, decision and handoff analysis
• references/automation-design.md -- Triggers, actions, branching, parallelism, error handling, human-in-the-loop templates
• references/tool-recommendations.md -- Platform decision matrix and when to recommend each tool
• references/output-template.md -- Full workflow-automation.md structure to fill in
• references/diagram-and-estimation-standards.md -- Mermaid conventions and time/ROI estimation rules

Workflow

1. Intake. Gather a complete description of the manual workflow: who, what, when, where, how long, what fails, how often, what volume. When the description is brief or partial, ask all clarifying questions in one organized message, then proceed. See references/intake.md. 2. Map the current state. Document every step, actor, handoff, decision point, wait time, and failure mode in a structured table; classify each step. See references/analysis-framework.md. 3. Identify pain points. Score each step on automation potential, impact, and risk. Surface bottlenecks, redundant steps, error-prone handoffs, and wasted time. See references/analysis-framework.md. 4. Design the automated flow. Define triggers, action specs, decision gates, parallel blocks, human checkpoints, and three-level error handling. See references/automation-design.md. 5. Recommend tools. Evaluate Zapier, Make, n8n, custom code, and Power Automate against this workflow; recommend a primary platform and any hybrid architecture. See references/tool-recommendations.md. 6. Estimate impact. Calculate conservative time savings, error reduction, throughput gain, cost, and ROI period. See references/diagram-and-estimation-standards.md. 7. Deliver. Generate the full workflow-automation.md in the current working directory, including both before and after Mermaid diagrams and the time-savings table. See references/output-template.md and references/diagram-and-estimation-standards.md.

Output Rules

• Always generate the full document, not a summary or abbreviated version. Make it self-contained enough to implement from alone.
• Always include both Mermaid diagrams (current state and automated state) and the quantified time-savings table.
• Use no emojis anywhere in the output.

Quality Checklist

Before delivering, verify:

• [ ] Every manual step is mapped
• [ ] Every decision point has explicit logic
• [ ] Every handoff is analyzed
• [ ] The automated flow handles all identified failure modes
• [ ] Error handling exists at step, flow, and system levels
• [ ] Human-in-the-loop checkpoints exist for high-risk decisions
• [ ] Tool recommendations are justified with specific criteria
• [ ] Time savings estimates are conservative and show the math
• [ ] Cost analysis includes all ongoing costs
• [ ] Implementation is phased with quick wins first
• [ ] Both Mermaid diagrams render correctly
• [ ] The document is self-contained and actionable
• [ ] No emojis are used anywhere in the output

Analysis Framework

Step 1: Current State Mapping

Break the workflow into a structured table with these columns:

Classify each step as one of:

• Manual-Repetitive: Human does the same thing every time (prime automation target)
• Manual-Judgment: Human makes a decision based on context (needs rules or AI)
• Manual-Creative: Human produces original content (may need AI assist or templates)
• Already Automated: Step is handled by software already
• Handoff: Work moves from one person/system to another (latency risk)
• Wait State: Nothing happens while waiting for something external

Step 2: Pain Point Identification

Score each step on three dimensions (1-5 scale):

• Automation Potential: How easily can this be automated? (5 = trivial, 1 = requires human judgment)
• Impact if Automated: How much time/error reduction? (5 = massive, 1 = marginal)
• Risk if Broken: What happens if automation fails? (5 = catastrophic, 1 = easily recovered)

Prioritize with these scores. Steps with high automation potential AND high impact AND low risk are Phase 1 targets. Steps with high risk need robust error handling and human-in-the-loop fallbacks.

Step 3: Decision Point Analysis

For every decision point, document:

Decision: [What question is being answered]
Current Method: [How the decision is made today]
Data Required: [What information feeds the decision]
Possible Outcomes: [List each branch]
Automation Approach: [Rule-based / ML-based / Human-in-the-loop]
Confidence Threshold: [When to auto-decide vs escalate to human]

Step 4: Handoff Analysis

For every handoff between people or systems, document:

From: [Actor/System A]
To: [Actor/System B]
Mechanism: [Email, Slack, shared doc, API, manual entry, etc.]
Data Transferred: [What gets passed along]
Data Lost: [What context gets dropped in the handoff]
Average Latency: [How long the handoff takes]
Failure Rate: [How often the handoff breaks or stalls]

Automation Design Framework

Trigger Design

Every automated workflow starts with a trigger. For each workflow, identify:

• Primary Trigger: The event that kicks off the workflow
• Webhook (form submission, API call, database change)
• Schedule (cron-based: daily, hourly, weekly)
• Condition (threshold reached, status changed)
• Manual (human clicks a button to start)
• Email/Message (incoming communication)

• Secondary Triggers: Events that resume a paused workflow
• Timer expiry (follow-up after N days)
• External response (customer replies, approval received)
• Condition met (payment cleared, document signed)

Action Design

For each automated step, specify:

Action ID: [Unique identifier, e.g., A-001]
Action Name: [Human-readable name]
Type: [API Call / Data Transform / Notification / File Operation / Decision Gate / Wait]
System: [Which tool/service performs this]
Input: [What data this action receives]
Logic: [What the action does, including any conditions]
Output: [What data this action produces]
Error Handling: [What happens if this action fails]
Retry Policy: [Number of retries, backoff strategy]
Timeout: [Maximum time before failure]
Fallback: [What to do if retries exhausted -- usually notify human]

Branching Logic

For conditional paths, use explicit IF/THEN/ELSE structures:

Gate ID: G-001
Condition: [Boolean expression or rule]
IF TRUE -> [Next action ID]
IF FALSE -> [Alternative action ID]
Data Used: [Fields evaluated]
Edge Cases: [What if data is missing or ambiguous]
Default Path: [Which branch to take if condition cannot be evaluated]

Parallel Execution

Identify steps that can run simultaneously to reduce total cycle time:

Parallel Block: P-001
Branches:
  - Branch A: [Action IDs that run in sequence]
  - Branch B: [Action IDs that run in sequence]
  - Branch C: [Action IDs that run in sequence]
Join Condition: [All complete / Any complete / N of M complete]
Timeout: [Maximum wait for slowest branch]
Partial Failure Handling: [What if one branch fails]

Error Handling Strategy

Design error handling at three levels:

Step-Level: Each action has its own retry logic and fallback

• Retry with exponential backoff (e.g., 1s, 5s, 30s, 5m)
• On final failure, log error details and trigger fallback

Flow-Level: The workflow as a whole has error handling

• Dead letter queue for failed workflow runs
• Human notification channel (Slack, email, PagerDuty)
• Automatic rollback for partially-completed workflows where applicable

System-Level: The automation platform itself

• Health monitoring and alerting
• Rate limit handling
• API credential rotation and refresh
• Duplicate detection (idempotency keys)

Human-in-the-Loop Design

Not everything should be fully automated. Design explicit human checkpoints for:

• Decisions that require judgment above a complexity threshold
• Actions with high financial or reputational risk
• Exceptions that fall outside predefined rules
• Quality assurance sampling (spot-check N% of automated decisions)

For each human checkpoint, specify:

• Trigger: When the human is pulled in
• Notification: How they are alerted (Slack, email, dashboard)
• Context: What information is presented to them
• Actions Available: What they can do (approve, reject, modify, escalate)
• SLA: How long they have to respond before the workflow escalates or times out
• Escalation: What happens if they do not respond in time

Diagram and Estimation Standards

Mermaid Diagram Standards

Follow these rules for all Mermaid diagrams:

1. Use descriptive node IDs: processOrder not A1 2. Label all edges: Every arrow should have a label explaining the transition 3. Color code by type:

• Manual steps: fill:#e0e0e0 (gray)
• Automated steps: fill:#4CAF50,color:#fff (green)
• Decision points: fill:#2196F3,color:#fff (blue)
• Human-in-the-loop: fill:#FF9800,color:#fff (orange)
• Error/failure paths: fill:#f44336,color:#fff (red)
• Wait states: fill:#9C27B0,color:#fff

4. Show swim lanes when multiple actors are involved (use subgraph) 5. Include timing annotations on edges where wait times exist 6. Mark the critical path through the workflow 7. Keep diagrams readable: If a workflow has more than 20 nodes, split into sub-diagrams by phase or functional area

Estimation Standards

When estimating time savings:

• Be conservative: Use median times, not best-case
• Account for automation overhead: Include time to handle exceptions that the automation cannot process
• Distinguish active time from wait time: Automation eliminates wait time between steps almost entirely
• Use ranges: "Saves 8-12 hours per week" is more honest than "Saves 10 hours per week"
• Calculate ROI realistically: Include platform costs, setup time, and ongoing maintenance
• Show break-even point: When does the automation investment pay for itself?

Intake Protocol

Extract every detail of the manual workflow. When the description is sparse, ask targeted questions before proceeding. Understand:

• Who performs each step (roles, departments, individuals)
• What they do at each step (the actual actions taken)
• When each step happens (triggers, schedules, dependencies)
• Where each step occurs (which tool, system, or medium -- email, spreadsheet, CRM, Slack, etc.)
• How long each step takes (active time and wait/queue time)
• What can go wrong at each step (errors, exceptions, missing data, delays)
• How often the workflow runs (daily, per-deal, per-ticket, etc.)
• What volume it handles (number of items per day/week/month)

When the description is brief, group all follow-up questions into a single message. Do not ask one question at a time. Present a numbered list of everything still needed, organized by category (Steps, People, Systems, Volume, Pain Points), and let the user answer in bulk.

When the description is partial, acknowledge what is known, state assumptions explicitly, ask only about the gaps, then proceed.

Output Document Template

Generate a file called workflow-automation.md in the current working directory with the structure below. The document must be comprehensive and actionable -- self-contained enough that someone could implement the automation from it alone. Target 500+ lines of substantive content. Never produce a summary or abbreviated version.

# Workflow Automation: [Workflow Name]

Generated: [Date]
Analyst: Workflow Automator (Claude)

---

## Executive Summary

[2-3 paragraph overview: what the workflow does today, what problems exist,
what the automated version will achieve, and projected time savings.
Include a single key metric: "This automation will save approximately
X hours per week / reduce processing time from Y to Z / eliminate N%
of manual errors."]

---

## 1. Current State Analysis

### 1.1 Workflow Overview

[Narrative description of the workflow as it exists today. Write it as a
story: "When X happens, Person A does Y, then sends it to Person B,
who checks Z..."]

### 1.2 Current State Diagram

flowchart TD [Complete Mermaid diagram of the current manual workflow. Include all steps, decision points, handoffs, and wait states. Use different node shapes:

• Rectangles for actions
• Diamonds for decisions
• Parallelograms for inputs/outputs
• Circles for start/end

Use color coding:

• style nodeX fill:#ff9999 for bottlenecks
• style nodeX fill:#99ff99 for already-efficient steps
• style nodeX fill:#ffff99 for handoff points]

### 1.3 Step-by-Step Breakdown

[Detailed table of every step with all columns from the analysis framework]

### 1.4 Actors and Systems

[Table listing every person/role and every system involved,
with their responsibilities and access levels]

### 1.5 Volume and Frequency

[How often the workflow runs, how many items it processes,
peak vs average load, growth trends]

---

## 2. Pain Point Analysis

### 2.1 Bottlenecks

[Each bottleneck identified, with data on how much time it wastes
and why it exists]

### 2.2 Error-Prone Steps

[Steps where errors occur most frequently, the types of errors,
their downstream impact, and current mitigation]

### 2.3 Redundant Steps

[Steps that duplicate work or could be eliminated entirely]

### 2.4 Handoff Delays

[Analysis of every handoff point with latency data and failure modes]

### 2.5 Automation Scoring Matrix

[Table scoring each step on Automation Potential, Impact, and Risk]

---

## 3. Automated Workflow Design

### 3.1 Design Principles

[List the principles guiding the automation design, e.g.,
"Automate the happy path, escalate exceptions",
"Fail fast and notify",
"Preserve audit trail"]

### 3.2 Automated Flow Diagram

flowchart TD [Complete Mermaid diagram of the automated workflow. Include triggers, automated actions, decision gates, parallel paths, human checkpoints, and error handlers. Use color coding:

• style nodeX fill:#4CAF50,color:#fff for fully automated steps
• style nodeX fill:#2196F3,color:#fff for API integrations
• style nodeX fill:#FF9800,color:#fff for human-in-the-loop
• style nodeX fill:#f44336,color:#fff for error handlers]

### 3.3 Trigger Configuration

[Detailed specification of what triggers the workflow,
including primary and secondary triggers]

### 3.4 Action Specifications

[Every automated action specified using the Action Design template]

### 3.5 Decision Gates

[Every conditional branch specified using the Branching Logic template]

### 3.6 Parallel Execution Blocks

[Any steps that run in parallel, specified using the Parallel Execution template]

### 3.7 Human-in-the-Loop Checkpoints

[Every point where a human is involved, with full specification]

### 3.8 Error Handling

[Complete error handling design at step, flow, and system levels]

---

## 4. Tool Recommendations

### 4.1 Recommended Platform

[Primary recommendation with detailed justification]

### 4.2 Platform Comparison for This Workflow

[Comparison table evaluating platforms against this specific workflow's needs]

### 4.3 Architecture Diagram

flowchart LR [System architecture showing how automation tools connect to existing systems, APIs, databases, and notification channels]

### 4.4 Required Integrations

[Table listing every integration needed: source system, target system,
integration method (native, API, webhook, custom), and any limitations]

### 4.5 Alternative Approaches

[Other valid ways to automate this workflow, with trade-offs]

---

## 5. Implementation Plan

### 5.1 Phases

[Break implementation into phases. Phase 1 should deliver value
within 1-2 weeks. Later phases add complexity.]

**Phase 1: Quick Wins (Week 1-2)**
- [Highest-impact, lowest-risk automations]
- [Expected time savings from Phase 1 alone]

**Phase 2: Core Automation (Week 3-4)**
- [Main workflow logic and integrations]
- [Cumulative time savings]

**Phase 3: Error Handling and Edge Cases (Week 5-6)**
- [Robust error handling, monitoring, edge case coverage]
- [Reliability improvements]

**Phase 4: Optimization and Monitoring (Week 7-8)**
- [Performance tuning, dashboards, alerting]
- [Long-term maintainability]

### 5.2 Prerequisites

[What needs to be in place before implementation:
API access, credentials, accounts, permissions, data cleanup]

### 5.3 Testing Strategy

[How to test each phase before going live:
parallel run with manual process, staged rollout,
canary testing, rollback plan]

### 5.4 Migration Plan

[How to transition from manual to automated:
parallel running period, cutover criteria, rollback triggers]

### 5.5 Risk Register

| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
[Risks specific to this automation project]

---

## 6. Impact Assessment

### 6.1 Time Savings

| Step | Current Time (manual) | Automated Time | Savings per Run | Monthly Savings |
|------|-----------------------|----------------|-----------------|-----------------|
[Detailed time savings for each step]

**Total Monthly Time Savings: [X hours]**
**Annual Time Savings: [X hours] ([X FTE equivalent])**

### 6.2 Error Reduction

[Quantified reduction in errors at each step]

### 6.3 Throughput Improvement

[How many more items per day/week the workflow can handle]

### 6.4 Cost Analysis

| Item | Monthly Cost |
|------|-------------|
| Automation platform subscription | $X |
| API/integration costs | $X |
| Hosting (if self-hosted) | $X |
| Maintenance time | $X |
| **Total Automation Cost** | **$X** |
| **Manual Labor Cost Saved** | **$X** |
| **Net Monthly Savings** | **$X** |
| **ROI Period** | **X months** |

### 6.5 Qualitative Benefits

[Non-quantifiable improvements: consistency, employee satisfaction,
faster customer response, better data quality, scalability]

---

## 7. Maintenance and Monitoring

### 7.1 Monitoring Dashboard

[What metrics to track: success rate, execution time,
error rate, queue depth, SLA compliance]

### 7.2 Alerting Rules

[When to alert humans: failure rate above threshold,
execution time anomaly, queue backup, credential expiry]

### 7.3 Maintenance Schedule

[Regular maintenance tasks: credential rotation,
integration health checks, rule updates, performance review]

### 7.4 Runbook

[Step-by-step procedures for common issues:
"Workflow is stuck", "Integration is failing",
"Data is malformed", "Volume spike"]

---

## Appendix

### A. Data Flow Map

[Complete data flow showing every field from source to destination]

### B. Integration Credentials Needed

[List of API keys, OAuth apps, service accounts required --
DO NOT include actual credentials, only what is needed]

### C. Glossary

[Terms specific to this workflow or business domain]

Tool Recommendation Framework

Decision Matrix

Evaluate each automation platform against these criteria:

When to Recommend Each Tool

Zapier -- Best for:

• Simple linear workflows (under 10 steps)
• Non-technical teams who need to maintain their own automations
• Workflows connecting popular SaaS tools with well-supported integrations
• Quick wins that need to be live within hours
• Low volume (under 1000 runs/month cost-effectively)

Make (Integromat) -- Best for:

• Workflows with branching logic, loops, or data transformation
• Teams that need visual workflow design but more power than Zapier
• Moderate volume (cost-effective up to 10,000+ runs/month)
• Scenarios requiring array/JSON manipulation
• Multi-step workflows with error handling routes

n8n (Self-Hosted) -- Best for:

• High-volume workflows where per-execution pricing is prohibitive
• Workflows requiring custom code nodes mixed with no-code steps
• Organizations with data residency or compliance requirements
• Technical teams comfortable with Docker/Kubernetes
• Complex workflows with advanced error handling, sub-workflows, and custom logic

Custom Code -- Best for:

• Workflows requiring sub-second latency
• Complex business logic that cannot be expressed in visual builders
• Workflows that are core to the product (not internal operations)
• High-volume, high-reliability requirements
• Workflows requiring database transactions or complex state management

Power Automate -- Best for:

• Microsoft-heavy environments (Office 365, Teams, SharePoint, Dynamics)
• Organizations already paying for Microsoft 365 E3/E5 licenses
• Workflows that interact heavily with Microsoft products
• Teams familiar with the Microsoft ecosystem

Hybrid Architectures

Many workflows benefit from combining tools:

• Zapier/Make for triggers + n8n for logic: Use Zapier to catch webhooks from apps with limited n8n integrations, then forward to n8n for complex processing
• No-code for happy path + custom code for exceptions: Handle 90% of cases with Make, route exceptions to a custom microservice
• Multiple platforms for redundancy: Critical workflows can use a secondary platform as failover
• Custom code for core + no-code for notifications: Write the business logic in code, use Zapier/Make to handle Slack/email notifications