Every automation project begins with a process that shouldn't exist in its current form.

This is the story of how we dissected a 47-step change order approval process, identified what actually needed human attention, and rebuilt it into something that works. Not a theoretical exercise — a real implementation for a real design and build firm.

The lessons apply far beyond construction.

---

The Scenario

The Client

A mid-sized design and build firm in the South West. 23 employees, specialising in commercial fit-outs. Good reputation, steady work, growing client base. But their operations team was drowning.

The symptom that brought them to us: change orders were taking too long.

When a client requested a modification mid-project — different materials, adjusted timelines, scope additions — the approval process took an average of 4.5 days. For changes that should be straightforward, this was killing both project momentum and client relationships.

Clients would call asking "Have you looked at my request yet?" The answer was often "It's in progress" — which really meant "It's sitting in someone's email inbox waiting for them to have time to deal with it."

The Process (Before)

The change order approval process involved 47 discrete steps across 5 different tools:

• Email (Outlook)
• Project tracking (Trello)
• Estimating system (custom Excel workbook)
• Accounting (Xero)
• Document storage (Google Drive)

Here's what actually happened when a client requested a change:

Steps 1-8: Initial Request

1. Site manager identifies needed change
2. Site manager emails project coordinator
3. Project coordinator logs request in Trello
4. Project coordinator requests estimate from estimator
5. Estimator opens estimate system
6. Estimator creates new estimate
7. Estimator emails estimate to project coordinator
8. Project coordinator uploads estimate to Google Drive

Steps 9-16: Client Communication 9. Project coordinator updates Trello card 10. Project coordinator emails client with estimate 11. Client responds via email 12. Project coordinator logs response in Trello 13. If client has questions, project coordinator emails estimator 14. Estimator responds via email 15. Project coordinator forwards response to client 16. Client confirms or requests changes

Steps 17-24: Approval Process 17. Project coordinator checks if change requires director approval (over £5k) 18. If yes, project coordinator emails operations director 19. Operations director reviews estimate 20. Operations director checks project budget in accounting system 21. Operations director emails approval/rejection 22. Project coordinator updates Trello 23. Project coordinator emails client with approval 24. Client confirms they want to proceed

Steps 25-32: Documentation 25. Project coordinator creates change order document 26. Project coordinator uploads to Google Drive 27. Project coordinator emails document to client for signature 28. Client signs and returns 29. Project coordinator saves signed document 30. Project coordinator updates Trello with "Approved and signed" 31. Project coordinator emails site manager that change is approved 32. Site manager confirms receipt

Steps 33-40: Financial Updates 33. Project coordinator emails accounting with change order details 34. Accounting opens project in Xero 35. Accounting manually enters change order amount 36. Accounting updates project budget 37. Accounting confirms update via email 38. Project coordinator updates Trello 39. Project coordinator files email confirmation 40. Project coordinator updates master project spreadsheet

Steps 41-47: Timeline Updates 41. Project coordinator checks if timeline needs adjustment 42. If yes, project coordinator emails site manager 43. Site manager provides new timeline 44. Project coordinator updates Trello 45. Project coordinator emails client with new timeline 46. Client confirms 47. Project coordinator updates all relevant parties

The full process touched email 14 times, required 8 file uploads, involved 6 different people, and required manual data entry into 4 separate systems.

The Numbers

• Average completion time: 4.5 days
• Steps requiring human judgment: ~10
• Steps that were pure data transfer: ~37
• Error rate: ~15% of approvals needed rework due to missing information, incorrect values, or lost communications
• Time spent per change order: Approximately 3.5 hours of cumulative staff time across all participants

The firm processed roughly 200 change orders per year. That's 700 hours of administrative time — nearly half a full-time employee — just moving information between systems.

And that doesn't count the cost of delays. When a change order takes 4.5 days to approve, projects stall. Clients get frustrated. Site managers can't plan work efficiently.

---

Mapping the Process

How We Documented Everything

Before automating anything, we needed to understand everything. We spent two weeks embedded with the team, documenting every action, every decision point, every handoff.

Our approach:

1. Shadow each role

We sat with the site manager, project coordinator, estimator, operations director, and finance manager. Each saw only their piece of the puzzle. We needed the complete picture.

The site manager didn't know what happened after they sent the initial email. The project coordinator didn't know what the estimator did with their request. The operations director didn't know how long the whole process took.

Everyone knew their part was slow. No one knew the full extent of the problem.

2. Document literally everything

Every click, every email, every phone call. Not what people thought they did — what they actually did.

The gap between these is often where inefficiency hides.

For example, the project coordinator told us "I update Trello when I get the estimate." In reality, they updated Trello when they remembered to, which was sometimes immediately and sometimes three days later. This created confusion about what stage each change order was at.

3. Map the exceptions

Standard processes are easy to understand. It's the exceptions that reveal system fragility.

What happens when a client doesn't respond? When an estimate needs revision? When approval authority is unclear? When someone is on holiday?

We found 12 different exception scenarios. Each had its own informal workaround. None were documented. All created delays.

Identifying Decision Points vs Mechanical Tasks

The critical insight came from categorizing each step:

Decision points — steps requiring human judgment:

• Is this change feasible within the current project timeline?
• What's the appropriate pricing for this modification?
• Should we proceed without client pre-approval?
• Does this change require additional regulatory consideration?
• Is the client's budget sufficient for this change?

Mechanical tasks — steps that follow deterministic rules:

• Copy estimate value from one system to another
• Send notification email when status changes
• Generate PDF from approved estimate
• Update project total when change order is approved
• Log communication in project history
• Set reminder for follow-up
• Update timeline based on new completion date

The ratio was revealing: approximately 80% of steps were mechanical. Data transfer, notifications, document generation, status updates. Things that required no judgment — just execution.

The 80/20 Insight

Here's what the analysis revealed:

80% of steps were data transfer. Only 20% needed human judgment.

This is the pattern we see repeatedly. Processes accumulate complexity not because decisions are complex, but because information movement is complex. Each handoff between systems creates overhead. Each manual entry creates error potential.

The solution isn't to speed up the manual steps. It's to eliminate them entirely.

---

The Automation Architecture

Design Principles

Before building anything, we established constraints:

Additional principles:

Visibility: Every automated action should be traceable. If something goes wrong, you should be able to see exactly what happened and when.

Override: Humans should be able to intervene at any point. Automation should assist, not constrain.

Graceful degradation: If automation fails, the process should continue manually. No one should be blocked because a system is down.

Notifications, not barriers: Alert humans to exceptions; don't block progress on edge cases.

The New Architecture

The redesigned workflow has 12 steps total:

Automated (8 steps):

1. Change request logged → system auto-populates project context
2. Notification sent to estimator with all relevant data
3. Estimate created → automatically linked to original project
4. Estimate completion triggers client communication
5. Client approval → automatically updates project financials
6. Document package generated (estimate, approval, updated contract)
7. All relevant parties notified of approval
8. Project timeline automatically adjusted if needed

Human (4 steps):

1. Site manager submits change request (with description and photos)
2. Estimator creates and validates estimate
3. Client reviews and approves (or requests revision)
4. Operations director approves (for high-value changes only)

The automated steps happen invisibly. The human steps are the only things that require attention.

How It Actually Works

Let's walk through the same change order with the new system:

Step 1: Site Manager Submits Request

Site manager notices client wants different tile specification. Opens DesBu on their phone, navigates to the project, clicks "Request Change Order."

They enter:

• Description: "Client wants porcelain tiles instead of ceramic in bathroom"
• Photos of the space
• Urgency: Normal

They submit. Time: 2 minutes.

What happens automatically:

• System pulls all project context (client details, current budget, timeline, team members)
• System identifies the assigned estimator for this project
• System sends notification to estimator with all context
• System creates a change order record linked to the project
• System logs the request in project history

Step 2: Estimator Creates Estimate

Estimator gets notification on their phone: "Change order request for [Project Name]"

They open it and see:

• Full description and photos
• Current project budget and status
• Client's previous change orders (if any)
• Original project estimate for reference

They create the estimate:

• Select materials from rate library
• Add labor costs
• Add markup
• Review total

They submit. Time: 15 minutes.

What happens automatically:

• System generates professional PDF of estimate
• System checks if amount requires director approval (>£5k)
• If yes, sends notification to operations director
• If no, proceeds directly to client
• System sends email to client with estimate attached
• System sets follow-up reminder for 48 hours
• System updates project coordinator

Step 3: Client Approves

Client receives email with estimate. They click the link, review the estimate, and click "Approve."

Time: 5 minutes.

What happens automatically:

• System generates change order document
• System sends document to client for signature
• System updates project budget
• System notifies all team members
• System adjusts project timeline if needed
• System creates invoice line item for future billing
• System logs approval in project history

Step 4: Operations Director Approves (if needed)

If the change order is over £5k, operations director gets notification.

They review:

• Estimate details
• Current project budget
• Client's payment history
• Project profitability

They approve or request changes. Time: 5 minutes.

What happens automatically:

• System proceeds with client communication
• System logs director approval
• System updates financial projections

Total Time

Before: 4.5 days, 3.5 hours of staff time After: 4 hours average, 30-45 minutes of staff time

Time savings per change order: 3 days, 2.5-3 hours of staff time

Annual savings (200 change orders): 550+ hours, near-elimination of delays

---

Implementation Details

The Build Process

Development took 6 weeks:

Weeks 1-2: Finalize workflow design, build database schema, create test data

We spent most of this time mapping edge cases. What happens when a client wants to revise an estimate? When an estimator is on holiday? When a change order needs to be cancelled?

Each edge case needed a clear path through the system.

Weeks 3-4: Implement core automation logic, build notification system

The notification system was critical. We needed to ensure people got notified at the right time, through the right channel (email, SMS, or in-app), without being overwhelmed.

We implemented smart batching: if multiple change orders need attention, send one notification with a summary rather than multiple individual notifications.

Weeks 5-6: Integration testing, edge case handling, user training

Testing revealed several issues:

• Notifications were too frequent (fixed with batching)
• Some edge cases weren't handled (added manual override option)
• Mobile interface was clunky (redesigned for thumb-friendly use)

Testing Approach

We used a "shadow mode" rollout:

Week 1: Automation runs alongside manual process, no actions taken — just logging what it would do

This caught several issues:

• System was calculating markup incorrectly for certain materials
• Notifications were being sent at odd hours (fixed with time-zone awareness)
• Some project data wasn't being pulled correctly

Week 2: Automation handles notifications only, humans still do all data entry

This let the team get used to the new notification system without risking the actual process.

Week 3: Full automation for standard cases, manual backup for exceptions

First real test. We found:

• Change orders submitted outside business hours needed queuing logic
• Some clients preferred phone approval over email (added flexibility)
• High-value changes (>£10k) required additional approval step

Week 4+: Full automation with monitoring

By week 4, the team trusted the system. Manual interventions dropped to near-zero.

Rollout Strategy

Training focused on the new mental model, not the new tools:

Old model: "I need to update these 5 systems and send these 3 emails"

New model: "I need to make this decision; the system handles the rest"

The hardest part wasn't technical. It was convincing people to trust the automation.

We addressed this by making every action visible. A real-time log showed exactly what the system was doing, when, and why. If someone wanted to verify that a client had been notified, they could see the exact email that was sent and when.

Transparency built trust.

---

Results

The Numbers

| Metric | Before | After | Improvement | |--------|--------|-------|-------------| | Total steps | 47 | 12 | 74% reduction | | Human steps | ~10 | 4 | 60% reduction | | Average time | 4.5 days | 4 hours | 96% faster | | Error rate | ~15% | <2% | 87% reduction | | Staff time per order | 3.5 hours | 45 minutes | 79% reduction |

Annual impact:

• Time saved: ~550 hours per year
• Error-related rework eliminated: ~25 incidents per year
• Client satisfaction: Measurably improved (faster turnaround cited in feedback)
• Revenue impact: Estimated £15,000-£20,000 in recovered time

Beyond the Numbers

The less quantifiable improvements matter equally:

Reduced stress

The operations coordinator described the old process as "constant anxiety about what might fall through the cracks." That anxiety is gone.

They no longer wake up at 3am wondering if they forgot to follow up with a client. The system handles it.

Better decisions

With administrative burden removed, the team spends more time on decisions that actually matter:

• Feasibility assessments
• Pricing strategy
• Client relationships
• Project planning

The estimator told us: "I used to spend 60% of my time on admin and 40% on actual estimating. Now it's reversed."

Scalability

The firm can now handle 50% more change orders with the same team. Growth no longer requires proportional administrative hiring.

They're currently processing 280 change orders per year (up from 200) with the same operations team.

Client relationships

Clients notice the difference. Response times went from days to hours. Communication is clearer. Nothing falls through cracks.

One client said: "You guys are so on top of things. Other contractors take a week to get back to me about changes."

What We'd Do Differently

Start smaller

We automated the entire workflow at once. In retrospect, automating just the notification sequence first would have delivered immediate value with less risk.

Lesson: Find the highest-pain, lowest-risk piece and automate that first. Build trust before tackling the whole process.

Invest more in monitoring

We built adequate logging but underinvested in dashboards. Visibility into workflow health should be a first-class feature, not an afterthought.

Now we build monitoring into every automation from day one.

Document edge cases earlier

Several exceptions emerged only during shadow mode. More thorough process mapping upfront would have caught these.

We now spend an extra week on edge case discovery before building anything.

---

The Takeaway

The goal isn't fewer steps. It's the right steps.

Humans should make decisions. Systems should handle execution. When these responsibilities are clearly separated, both function better.

The 47-step process wasn't designed to be complex. It accumulated complexity because tools didn't talk to each other, because information needed to be manually shepherded between systems, because no one had stepped back to ask: "Which of these steps actually require a human?"

Every workflow has this hidden ratio of decisions to data transfer. Find it. Automate the transfer. Protect the decisions.

---

Applying This to Your Practice

You don't need to automate a 47-step process to see benefits. Even small automations compound.

Start with these questions:

1. What task do you do every week that's exactly the same every time?
2. What information do you copy from one place to another regularly?
3. What follow-ups do you sometimes forget?
4. What errors happen because someone forgot a step?

Those are your automation candidates.

The pattern is always the same:

• Identify the repetitive task
• Separate decisions from data transfer
• Automate the data transfer
• Keep humans in control of decisions

You don't need custom software for everything. Sometimes it's as simple as:

• Email filters that auto-file messages
• Calendar reminders that trigger automatically
• Templates that pre-fill information
• Zapier connections between tools

Start small. Build trust. Expand gradually.

---

RAAIX builds automation systems that eliminate operational friction. If your team spends more time managing processes than doing actual work, let's talk →