Fix it before you automate it.

Your invoice approval process takes six steps and three days because Margaret insists on printing everything, Bob's on holiday half the time, and the system requires approvals in a specific order that made sense in 2018.

• Bad approach: Automate the exact same six steps

• Good approach: Redesign it as two steps, then automate

To help identify if your process is broken or not, here are some of the questions to ask before automating anything:

• "Why do we do it this way?"

• "What happens if we just... stop doing this?"  

• "Is this working around a system limitation or solving an actual business problem?"  

• "Would we design it this way today if we started from scratch?"

• "Is this process stable or still changing?"  

Most businesses have a few processes that desperately need automation, a couple that would benefit, and many that work fine manually. The trick is knowing which is which.

You can't automate what you don't understand. And most businesses don't actually understand their own processes.

Step 1: Document How It Actually Works (Not How You Think It Works)

Grab someone who does the work. Not their manager. Not the person who designed the process five years ago. The person actually doing it today.

Ask them to show you. Not tell you. Show you.

Watch them work for 30 minutes. You'll discover:

• Steps nobody documented

• Workarounds everyone knows but nobody mentions

• Software being used that IT doesn't know about

• Data being copied manually because systems don't talk

Output: Process map showing actual steps, time per step, who does what, what systems are involved

Tool: Spreadsheet. Fancy process mapping software optional.

Step 2: Identify Automation Candidates Using the RSVP Framework

Not every process is worth automating. Use RSVP to evaluate:

R - Repetitive: Done multiple times per day/week/month

S - Stable: Process doesn't change constantly

V - Volume: High enough volume to justify automation cost

P - Painful: Causes errors, delays, or drives people insane

Examples:

Good candidates:

• Invoice processing (500/month, stable workflow, rule-based, manual entry errors)

• Customer onboarding (50/month, same steps every time, documents need generating)

• Data entry between systems (happens 100x/day, error-prone, nobody likes doing it)

Bad candidates:

• CEO's monthly report (once a month, changes every time, requires judgment)

• Client relationship management (requires human touch, context-dependent)

• Strategic planning (not repetitive, needs human judgment)

Step 3: Calculate Time and Error Cost

This is where automation justifies itself financially.

Formula:

(Hours spent per month × Hourly cost) + (Errors per month × Cost to fix) = Monthly cost

Example:

Manual invoice processing:

• 200 invoices/month

• 15 minutes per invoice = 50 hours

• £25/hour labor = £1,250

• 8 errors/month (4% error rate)

• 45 minutes to fix each = 6 hours

• 6 hours × £25 = £150

Total monthly cost: £1,400

If automation costs £300/month + £6,000 to implement = £800/month effective cost (amortizing implementation over 12 months)

Monthly savings: £600 = £7,200/year

Payback: 8.6 months

That's how you justify automation to the finance team.  

Step 4: Prioritize Using Impact vs Effort Matrix

You can't automate everything at once. Prioritization separates successful projects from abandoned ones.

• Impact (Y-axis): How much time/money/pain this saves

• Effort (X-axis): How difficult to automate

As well as...

• Quick wins (High impact, low effort): Do these first

• Strategic projects (High impact, high effort): Do after quick wins prove ROI

• Fill-ins (Low impact, low effort): Do when capacity available

• Time sinks (Low impact, high effort): Don't do these

A common mistake is starting with the most complex, highest-impact automation. You spend six months, burn budget, team loses faith. Start with wins that take 2-4 weeks and prove the concept.

Now the actual implementation. This is where most guides wave hands and say "use the right tools."  

Not helpful.

Here's what actually happens:

Phase 1: Process Design (Before Any Technology)

You've identified what to automate. Now redesign it for automation.

Questions to answer:

• What triggers the process? (New invoice received, customer signs up, time-based schedule)

• What's the happy path? (Everything goes right, no exceptions)

• What are the exceptions? (What breaks the rules, how often, how do we handle them)

• Where does data come from? (What systems, what format, is it reliable)

• Where does output go? (What systems, who needs to know, what format)

• What needs human involvement? (Approval steps, judgment calls, exception handling)

Output: Process design document showing triggers, steps, data flows, exception handling, success criteria

Don't skip this. Most failed automation is because nobody mapped edge cases before building.

Phase 2: Select Tools (Technology Choices That Actually Matter)

For simple automations: Zapier, Make, Microsoft Power Automate

• Good for: Connecting cloud apps, simple if-then logic, no-code

• Not good for: Complex business logic, large data volumes, custom requirements

For moderate complexity: Custom development with APIs

• Good for: Integrating internal systems, custom business rules, scalability

• Not good for: Teams without developers, rapidly changing requirements

For complex workflows: Full business process automation platforms

• Good for: Enterprise-scale, complex approval chains, audit requirements

• Not good for: Small businesses, simple processes, limited budgets

The tool selection mistake everyone makes: Choosing enterprise software for small problems. You don't need IBM BPM to automate sending welcome emails.

Phase 3: Build and Test (Where Things Actually Get Built)

• Start with one scenario: Build the happy path first. Get that working. Then add exceptions.

• Build in sandbox: Never test automation on production data. Ever. Create test environment with dummy data.

• Test edge cases: What happens when someone uploads a PDF instead of Excel? When approval is on holiday? When system is down?

• Load test: If it works for 10 items, does it work for 1,000? Test at expected volume + 50%.

• Error handling: What happens when automation fails? Alert someone? Retry? Log for review? Plan this before launch.

Common mistakes:

• Assuming happy path is only path (it's not)

• Not testing at scale (works fine with 10 items, breaks with 1,000)

• No error notifications (automation silently fails, nobody knows)

• Hardcoding values (works until something changes, then breaks)

Phase 4: Pilot with Small Group (The Risk Mitigation Phase)

Never roll out automation company-wide immediately. Run a pilot.

Pilot parameters:

• 2-4 weeks duration

• Single team or department

• 25-50% of volume

• Clear success metrics

• Daily monitoring

• Quick rollback plan

What to monitor:

• Processing time vs manual baseline

• Error rates

• User feedback

• Exception handling frequency

• System performance

Pilot success criteria (define these before starting):

• 50%+ time reduction

• Error rate below X%

• Team satisfaction score above Y

• No critical failures

• Exception handling works

If pilot succeeds: Refine based on feedback, document, train, roll out

If pilot fails: Learn why, fix, pilot again (or abandon if unfixable)

Phase 5: Roll Out and Monitor (Ongoing Management)

Automation isn't "set it and forget it." It needs ongoing attention.

• Week 1-2: Monitor daily. Fix issues immediately. Hand-hold users.

• Week 3-4: Monitor every other day. Address patterns in issues.

• Month 2: Weekly checks. Optimize based on real usage.

Ongoing: Monthly performance reviews. Quarterly optimization.

What to track:

• Processing volume

• Completion rate

• Average processing time

• Error rate and types

• Exception frequency

• User satisfaction

When to pause automation:

• Error rate spikes above 5%

• Processing fails > 10% of volume

• Critical business impact

• Regulatory/compliance concern

Have a rollback plan: Know how to go back to manual process if automation fails catastrophically.

AI isn't magic. It's really good at specific things and terrible at others.

What AI is actually good for in automation:

• Document processing: Extracting data from invoices, receipts, contracts (OCR + AI)

• Customer support: Answering repetitive questions, routing complex ones to humans

• Data categorization: Sorting emails, classifying support tickets, organizing files

• Predictions: Forecasting inventory needs, predicting customer churn, scheduling optimization

• Content generation: Email responses, report summaries, data analysis

What AI is bad at in automation:

• Nuanced judgment: "Is this customer being difficult or having a bad day?"

• Novel situations: Anything it hasn't seen in training data

• Accountability: Can't be held responsible when it gets things wrong

• Transparency: "The AI decided" doesn't work for audits or compliance

How to actually use AI in automation:

1. AI for classification + rules-based automation

AI categorizes (email is sales inquiry vs support request), then rules route it appropriately

‍

2. AI for extraction + human verification

AI pulls data from invoice, flags uncertain items for human review (confidence scores)

‍

3. AI for drafting + human approval

AI generates customer response, human reviews before sending

‍

4. AI for recommendations + human decision

AI suggests next action, human decides whether to take it

‍

Pattern: AI handles repetitive parts, humans handle judgment. Don't try to automate judgment.

According to Deloitte research, 50% of organizations plan to incorporate AI into automation initiatives by 2025. But implementation success requires understanding AI's limitations, not just its capabilities.

Before you start:

• [ ] Process documented as it actually works (not as designed)

• [ ] Broken steps redesigned or removed

• [ ] Time and cost calculations show positive ROI

• [ ] Priority ranked against other automation candidates

• [ ] Stakeholders informed and supportive

• [ ] Exception scenarios identified

• [ ] Success criteria defined

During implementation:

• [ ] Tool selected based on complexity needs, not marketing

• [ ] Development in sandbox/test environment

• [ ] Happy path working reliably

• [ ] Edge cases tested

• [ ] Error handling built in

• [ ] Documentation created

• [ ] Training materials prepared

• [ ] Rollback plan documented

After launch:

• [ ] Pilot with limited scope (2-4 weeks)

• [ ] Daily monitoring first week

• [ ] User feedback collected and acted on

• [ ] Issues fixed quickly

• [ ] Success criteria met before full rollout

• [ ] Performance metrics tracked

• [ ] Monthly optimization reviews

• Automating the wrong thing: High-visibility process that's done once a quarter instead of daily pain point

• Skipping process redesign: Automating broken workflow, now it's broken faster

• No exception handling: Works 95% of time, fails catastrophically 5% with no plan

• Over-engineering: Building custom when £20/month SaaS tool exists

• Under-engineering: Using simple tool for complex problem it can't handle

• No monitoring: Automation breaks, nobody notices for weeks, chaos ensues

• Forgetting humans: Not training users, not planning transition, resistance kills adoption

• Ignoring data quality: Garbage in, garbage out—now automated

DIY works when:

• Connecting two cloud apps (Gmail → Slack)

• Simple if-then logic (new sale → send welcome email)

• Using no-code tools (Zapier, Make)

• Small volume, low risk if breaks

• You have time to maintain it

Get professional help when:

• Custom business logic required

• Integrating internal systems

• High volume or mission-critical

• Regulatory/compliance requirements

• Need scalability and reliability

• Don't have technical expertise

What Octogle does: We build custom automation for processes no-code tools can't handle. When you need intelligent document processing, complex business rules, or systems integration that requires actual development—not just connecting apps.

Get a free automation scan: We examine your workflows, identify what's worth automating, estimate savings, recommend approach. Then you decide if you want help or DIY it.