Workflow Automation for Operational Excellence

A practical, step-by-step method for identifying and implementing digital automation in SME operations. You will map current workflows, choose the right tool category, design error-proof and secure automations, validate them, and roll them out without disrupting daily work. The course closes with honest ROI measurement, change management and a 90-day action plan.

Course structure

• Module 1: Foundations: automation for operational excellence (4 lessons). What automation can and cannot do, the range of approaches, why Lean comes first, and how to recognize a good candidate.
• Module 2: Find, map and prioritize opportunities (4 lessons). Build an opportunity pipeline, map how work really happens, measure a baseline and decide what to automate first.
• Module 3: Tools and architecture design (5 lessons). Understand the tool categories, choose the right one, design error-proof workflows, plan for exceptions and govern data and access.
• Module 4: Build, validate and integrate (4 lessons). Deliver in small increments, prove the automation with structured testing, deploy without disrupting operations and keep it healthy.
• Module 5: Business case, change and results (4 lessons). Make an honest ROI case, lead the people side of change, measure results against the baseline and plan your next 90 days.

Interactive labs

• Is this task a good automation candidate?: Sort each task into one of three groups using the candidate criteria. Checking your answers shows the reasoning, so you can apply the same screen to your own pipeline.
• Automation candidate prioritization: Rate each workflow on implementation effort and the time or value it would save, then see where it lands. Rename or add items to prioritize your own pipeline.
• Automation business case calculator: Enter your baseline hours, labour cost and expected costs to estimate annual savings, payback and 3-year ROI for a candidate automation.

How it works

• Work through 21 short lessons at your own pace. Each has key takeaways, an exercise for your own workplace and a quick knowledge check.
• Try the three interactive labs as you reach them in the course.
• Pass the 20-question final exam (70% or higher, unlimited retakes) to unlock your Chmltech certificate of completion.
• Free, with no sign-up. Your progress is saved in this browser.

Workflow automation means using software to carry out the repeatable steps of a business process with little or no human effort. A purchase order is approved, a record is created in the ERP, a customer gets a confirmation email, and a report lands in a shared folder, all without someone copying data from one screen to another.

For a small or mid-sized business, the goal is not robots for their own sake. The goal is operational excellence: work that flows reliably, with fewer errors, shorter lead times and people freed for tasks that need judgement.

What automation does well

• Moves data between systems that do not talk to each other (email to spreadsheet, web form to accounting system).
• Applies clear rules consistently, every time, at any hour.
• Triggers the next step so work does not sit in someone's inbox waiting to be noticed.
• Creates a record of what happened and when, which supports audits and problem solving.

What automation does not do

• It does not fix a badly designed process. Automating a confusing process gives you confusion at machine speed.
• It does not replace accountability. Someone still owns the outcome.
• It does not stay working on its own. Systems change, and automations need maintenance.

A worked example

Imagine a 25-person industrial distributor. Every morning a customer service rep opens about 40 emailed orders, retypes each one into the order system, and emails a confirmation. Each order takes around 6 minutes, so roughly 4 hours a day go to retyping. Typos cause wrong shipments a few times a month.

An automation could read the order emails, extract the customer, part numbers and quantities, create draft orders, and flag any line that does not match the price list. The rep now reviews and releases orders instead of keying them. The work still has a human owner, but the repetitive part is gone and errors are caught before they ship.

Notice what made this a good starting point: high volume, a clear structure, a measurable error problem and a person who understands the process well. You will use these same signals throughout this course to find, design and prove automations that last.

"Automation" covers a wide range of approaches. Knowing the spectrum helps you match the tool to the task instead of reaching for the most fashionable option.

Attended versus unattended

Attended automation runs when a person starts it and works alongside them, such as a button that builds a quote package. Unattended automation runs on a schedule or trigger with no one watching, such as a nightly inventory sync. Unattended runs need stronger error handling because nobody is there to notice a problem.

Deterministic versus probabilistic

Rules-based automation is deterministic: the same input always gives the same output. AI-based steps are probabilistic: they are usually right, but not always, and they can be confidently wrong. That difference drives design. Deterministic steps can often run unattended. Probabilistic steps generally need confidence thresholds and a human review path.

Start low on the spectrum

A useful habit is to check the simplest level first. Many teams buy a new platform when the feature they need is already sitting unused in their ERP or practice management system. Ask in this order:

1. Can our current software do this with a setting or built-in rule?
2. Can a simple workflow connect two systems through their APIs?
3. Do we need managed integration because the data is core and high volume?
4. Is there no API, so we need RPA on the user interface?
5. Is the input unstructured, so we need AI with review?

Each step down the list adds capability, but also cost, fragility and governance work.

Lean thinking gives automation its direction. Before you automate any step, ask whether the step should exist at all. Lean identifies eight common wastes, often remembered as DOWNTIME:

• Defects: errors and rework
• Overproduction: producing reports or documents nobody uses
• Waiting: work sitting in queues or inboxes
• Non-utilized talent: skilled people doing clerical tasks
• Transportation: moving information between systems or people
• Inventory: backlogs of unprocessed work
• Motion: searching, clicking, switching screens
• Extra processing: duplicate approvals, re-checking, reformatting

Eliminate, simplify, then automate

A reliable sequence is eliminate, simplify, standardize, automate. Remove steps that add no value. Simplify what remains. Make it the same every time. Only then build the automation. This order keeps you from paying to automate steps you could have deleted for free.

A worked example

An engineering office produces a weekly project status report. A coordinator spends about 3 hours each Friday pulling hours from the timesheet system, budgets from accounting and milestones from a spreadsheet, then formats a 12-page document for every project manager.

The first instinct is to automate the whole report. A Lean review asks different questions first:

1. Who reads it? Interviews show most managers read only the budget table and the late milestones list.
2. Is all of it needed? Eight of the twelve pages are never used. That is overproduction.
3. Is the milestone spreadsheet necessary? The project tool already holds milestones, so the spreadsheet is duplicate processing.

After simplification, the report is a one-page dashboard with two tables. The automation needed is now much smaller: a scheduled flow that pulls two data sets and refreshes the dashboard. It is cheaper to build, easier to test and less likely to break.

Value-added test

For each step, ask: would the customer willingly pay for this step if they saw it? Is it required by regulation or contract? If the answer to both is no, the step is a candidate for elimination, not automation. Steps that are necessary but add no value (such as compliance checks) are often excellent automation candidates, because they must happen but should cost as little effort as possible.

Not every task is worth automating. The best candidates share a recognizable profile. Use the criteria below as a quick screen before you invest any design effort.

Three outcomes, not two

Screening is not a yes-or-no decision. Many tasks fall into a middle group:

1. Automate now (rules-based): clear rules, structured inputs, stable process. Example: copying approved timesheet hours into payroll.
2. Automate with human review: the routine part can be automated, but a person checks exceptions or AI outputs before they take effect. Example: AI reads supplier invoices and a clerk approves anything below a confidence threshold or above a dollar limit.
3. Not a good candidate: the work depends on relationships, judgement, empathy or rare events. Example: negotiating a payment plan with a long-standing customer.

A worked screen

A fabrication shop considers three tasks. Generating weekly work orders from confirmed sales orders scores well on rules, volume and structured input, so it is an "automate now". Reading emailed drawings to estimate weld hours involves varied formats and engineering judgement, so at most it is "automate with review", with AI drafting an estimate for an estimator to correct. Deciding how to handle a customer's complaint about a cracked weld needs investigation and judgement, so it stays human.

Watch for hidden variation

People often describe a task as "always the same" until you look closely. Before accepting that a task is rules-based, pull 20 recent real examples and check how many follow the standard path. If many need special handling, either standardize the process first or plan for a human review step.

Most SMEs do not lack automation ideas. They lack a simple way to capture, compare and decide on them. An opportunity pipeline turns scattered suggestions into a managed list.

Where ideas come from

• Frontline staff who do the repetitive work every day
• Recurring complaints, errors and customer issues
• Gemba walks: going to where the work happens and watching it
• Month-end crunches and overtime patterns
• Audit findings and compliance gaps

A simple intake form

Keep the intake short so people actually use it. Capture:

1. The task in one sentence, starting with a verb ("Enter carrier invoices into accounting")
2. Who does it and how often
3. Roughly how long it takes each time
4. What goes wrong today
5. Which systems are involved

Pipeline stages

Worked example

A 60-person home health care agency holds a 30-minute monthly "automation huddle". Coordinators bring ideas on the intake form. In one meeting they log seven ideas, screen out two (one is rare, one depends on a phone conversation), and move three into assessment. The operations manager owns the list, and every idea gets an answer, even if the answer is "not now, and here is why".

That last point matters. When staff see their suggestions acknowledged and acted on, they keep contributing, and the pipeline becomes a source of continuous improvement rather than a one-time project.

Keep it visible

A shared spreadsheet or a simple board with one card per idea is enough. The tool is less important than the habit: a regular review, a named owner and clear stage definitions.

You cannot automate a process you do not understand. Mapping the current state, the way work actually happens today, is the foundation for every later decision.

Start with a SIPOC

A SIPOC sets the boundaries before you draw any detail:

The SIPOC answers: where does this process start, where does it end, and who cares about the output?

Then draw a swimlane map

A swimlane map shows each role or system as a horizontal lane and each step as a box in the lane of whoever performs it. Handoffs between lanes become obvious, and handoffs are where delays and errors usually hide.

When you map, capture for each step:

• Who or what performs it (person, role or system)
• Which system or document is used
• Decision points and the rules behind them
• Typical time and waiting time
• Common errors and exceptions

Map what is real, not what is written

Procedures often describe an ideal process. Sit with the people who do the work and watch several real cases. Ask "what happens when…?" questions: when the customer number is missing, when the part is discontinued, when the approver is on vacation. The workarounds you discover are often the most important part of the map.

Worked example

A distributor's warehouse maps its receiving process. The written procedure has five steps. Observation reveals eleven, including a receiver writing quantities on paper, walking to an office PC, and an accounts payable clerk later re-entering the same quantities to match invoices. Two lanes contain the same data entry. The map also shows that when a shipment is short, the receiver emails purchasing, and that email is often missed.

The map now points to two opportunities: capture quantities once at the dock on a handheld device, and route short shipments automatically to the buyer with a follow-up if nothing happens in 24 hours.

Keep it lightweight

Sticky notes on a wall or a simple diagramming tool are fine. The value comes from the conversation and observation, not the software.

A baseline is the set of measurements that describe how the process performs today. Without it, you cannot size the opportunity, build a credible business case or prove the automation worked.

Core baseline measures

Handling time versus lead time

These two are often confused. Handling time is the effort a person spends. Lead time is how long the customer waits. An order may take 6 minutes to enter but sit for 2 days in an inbox first. Automation can reduce both, but the business case and the customer benefit may depend mostly on lead time.

Worked example

A clinic's intake desk processes new patient referrals. Over two weeks, staff keep a simple tally sheet:

• Volume: about 150 referrals per week
• Handling time: about 9 minutes each to key demographics and attach documents
• Lead time: referral received to first appointment booked averages 4 working days
• Errors: 6 referrals in two weeks needed a call back because of missing or mistyped details

Weekly effort is 150 × 9 = 1,350 minutes, or 22.5 hours. That figure feeds directly into the business case later. The lead time shows the patient impact, and the error count gives a quality target to improve on.

Practical tips

1. Measure for at least two weeks to smooth out daily swings, and note any unusual events.
2. Explain to staff that you are measuring the process, not judging individuals.
3. Write down your definitions, such as when lead time starts and stops, so you measure the same way after go-live.
4. Keep the raw data. You will compare against it when you validate results.

Good-enough data collected consistently beats perfect data you never gather.

Once you have several assessed candidates, you need to decide what to build first. An effort-versus-value matrix is a simple, visual way to compare them and agree as a team.

Scoring value

Score value from 1 to 5 using the baseline data. Consider:

• Hours saved per year (volume × handling time × share automatable)
• Error reduction and the cost of those errors
• Lead time improvement and customer impact
• Compliance or risk reduction

Scoring effort

Score effort from 1 to 5, considering:

• Number of systems involved and whether they have APIs
• Number of exceptions and decision rules
• Data quality and need for clean-up
• Skills required and approvals needed (IT, privacy, finance)

The four quadrants

Worked example

A 45-person manufacturer scores five candidates. Sending order confirmation emails from the ERP scores effort 1, value 3: a quick win. Integrating the e-commerce store with the ERP scores effort 4, value 5: strategic. Automating a quarterly safety report scores effort 2, value 2: a fill-in. Building an RPA bot to re-key data into an old quoting tool that is being replaced next year scores effort 4, value 2: rethink.

The team starts with the confirmation emails to learn the platform, while planning the e-commerce integration as a phased project.

Make the scoring a conversation

Score in a group that includes the people who do the work and someone who understands the systems. Disagreements about scores are useful: they reveal hidden effort or overlooked value. Revisit the matrix as you learn; a quick win can turn out to be harder than expected, and that is normal.

Finally, remember that early wins matter for change management. A visible success in the first month builds credibility for the larger projects that follow.

The market is crowded, but most tools fall into a few categories. Understanding the categories matters more than knowing every product name, because products change quickly.

The examples are listed only to help you recognize the categories. They are not recommendations, and the right choice depends on your systems and skills.

APIs: the key concept

An API (application programming interface) is a defined way for software to exchange data with other software. When systems have APIs, workflow and integration tools can connect them reliably. When they do not, you fall back on RPA or file exports. Before choosing a tool, list your core systems and find out whether each has an API and whether your subscription includes access to it.

Worked example

A professional services firm uses a cloud accounting system, a CRM and email. All three have APIs and the firm already licenses an office productivity suite that includes a low-code workflow tool. For new-client onboarding, that included tool is a sensible first choice: it can create the client in accounting, set up a CRM record and send a welcome email.

The same firm also has a legacy desktop time-billing system with no API. Moving data out of it might need an RPA desktop flow, or better, a scheduled file export that a workflow picks up.

Questions to ask about any tool

1. Does it connect to our core systems natively?
2. Who will build and maintain it, and do they have the skills?
3. How does it handle errors, retries and alerts?
4. Where is data processed and stored?
5. How does licensing scale as usage grows?

Tool selection should follow from the task, the systems and your team's capacity, not from a vendor demo. A simple decision path keeps the choice grounded.

A decision path

1. Is the input structured? If not (scanned invoices, free-text emails), you will likely need AI document processing with human review for the reading step.
2. Do the systems have APIs? If yes, prefer a workflow or integration tool. If no, consider RPA or file-based exchange.
3. How much volume and how critical? Low-to-moderate volume and departmental use suits low-code workflows. High-volume, business-critical data sync between core systems suits a managed integration platform.
4. Who will own it? Pick a tool your team or a reliable partner can maintain for years, not just build once.

Selection criteria

Worked example

A 30-person electrical contractor wants to process supplier invoices faster. Invoices arrive as PDFs in many layouts. The accounting system has an API. Volume is about 600 invoices a month.

Walking the path: the input is unstructured, so an AI document processing step is needed. The accounting system has an API, so a workflow tool can post the extracted data. Volume is moderate, so a low-code platform is enough. The controller will own it with help from an external partner for the first build.

The resulting design combines two categories: AI reads the invoice, a workflow matches it to the purchase order, and anything that does not match or falls below a confidence threshold goes to the accounts payable clerk for review.

Avoid tool sprawl

Each new platform adds licences, logins, skills and failure points. Where possible, standardize on one or two platforms and build expertise in them. Run a short proof of concept with real data before committing to any new tool.

Good automation design does more than speed up steps. It builds in quality so errors are prevented rather than caught later. Lean calls this poka-yoke, or error-proofing.

Design principles

• Capture data once, at the source. Every retyping step is a chance for error. Let the original form, file or system feed everything downstream.
• Validate on entry. Check required fields, formats and ranges before data moves on. A postal code, a part number or a date can be checked automatically.
• Use lookups, not free text. Pick customers and parts from master data lists rather than typing names.
• Make the standard path simple and send exceptions to a clear, separate path.
• Keep a single source of truth for each data element, and sync from it.

Drawing the future-state map

Redraw your swimlane map for the future state. Add a lane for the automation itself so everyone can see which steps the system performs. For each automated step, note the trigger, the input, the rule and the output.

Worked example

A fabrication shop's current process has a planner typing job details from sales orders into a production spreadsheet, then a supervisor printing travellers. Errors in material grade cause scrap a few times a quarter.

The future-state design pulls job data directly from the confirmed sales order, uses the material master list so grades cannot be typed incorrectly, and blocks release of a job if the drawing revision is missing. The planner's role shifts from typing to checking flagged jobs. The error is not just made less likely; the most common one becomes impossible.

Design for the people too

Future-state design should state who does what after go-live. Clarify which decisions remain with people and how they will know when the system needs them. A design that leaves staff unsure of their role will be worked around.

Every process has exceptions. The quality of an automation is often judged by how it handles the cases that do not fit, not the ones that do.

Types of exceptions

• Business exceptions: the data is valid but the case needs a decision, such as an order above a customer's credit limit.
• Data exceptions: missing, invalid or mismatched data, such as an unknown part number.
• System exceptions: a technical failure, such as an API timeout or expired password.
• Confidence exceptions: an AI step is unsure, such as a blurry scanned invoice.

Design rules for exceptions

1. Never fail silently. Every exception must land somewhere visible with an owner.
2. Route to the right person with the context they need to decide quickly.
3. Retry system errors a set number of times before alerting.
4. Set service levels for exception handling so items do not age in a queue.
5. Track exception volumes. A rising trend signals a process or data problem to fix.

Human-in-the-loop patterns

Worked example

An accounts payable automation processes supplier invoices. Invoices that match a purchase order within a small tolerance post automatically. Those with price differences go to the buyer. Those where the AI extraction confidence is low go to the AP clerk. Any invoice over $25,000 needs controller approval regardless. If the accounting system API fails, the flow retries three times, then alerts the controller by email and holds the invoice in a queue.

After three months of stable results, the team adds a weekly sample audit of ten auto-posted invoices to confirm nothing is slipping through.

Start with more review, then reduce it

At launch, keep more human checks than you think you need. As evidence builds that the automation is accurate, step down from approval to exception review to sampling. This builds trust and limits the cost of early mistakes.

Automations touch sensitive data and often run with powerful access. Basic governance keeps them safe, compliant and supportable. You do not need a large bureaucracy, but you do need clear rules.

Security essentials

• Service accounts: run automations under dedicated accounts, not a person's login, so they keep working when someone leaves and their actions are traceable.
• Least privilege: give each automation only the access it needs.
• Credential storage: keep passwords and keys in the platform's secure vault, never in a flow's text or a spreadsheet.
• Audit logs: make sure you can see what ran, when, and what it changed.

Privacy in Canada

Private-sector organizations in most provinces are subject to PIPEDA, and some provinces, including British Columbia, Alberta and Quebec, have their own private-sector privacy laws. Health information may fall under provincial health privacy legislation. In general terms, these frameworks expect you to collect personal information for identified purposes, limit its use to those purposes, protect it with appropriate safeguards and be accountable for it. For automation, ask:

1. What personal information does the flow handle?
2. Where is it processed and stored, including by cloud and AI services?
3. Is it being used only for the purpose it was collected for?
4. Who can see the logs, which may contain personal details?

This is general guidance, not legal advice. Involve your privacy officer or legal adviser for anything involving health, financial or other sensitive information.

A lightweight governance model

Worked example

A clinic builds a flow that copies referral details from a secure web form into its scheduling system. The review finds the flow was built under the office manager's personal login and that error notifications email the full referral, including health details, to a shared inbox. The fixes: move to a service account, store credentials in the vault, and change notifications to send only a reference number with a link to the secure system.

Citizen development needs guardrails

Low-code tools let business users build their own automations, which is powerful. Pair that freedom with the inventory and approval steps so useful personal flows do not become hidden, unsupported business dependencies.

Large automation projects that try to handle every case at once tend to run late and over budget. Building in small, working increments reduces risk and delivers value sooner.

Define a minimum viable automation

Start with the standard path that covers most cases, and send everything else to a person. Add exception handling in later increments as you learn which exceptions matter most.

A typical increment plan

Use PDCA for each increment

• Plan: define the scope, test cases and success measures.
• Do: build and test the increment.
• Check: compare results with the baseline and the success measures.
• Act: adjust, standardize what works and plan the next increment.

Worked example

A distributor wants to automate order entry from emails. Its customers send orders in three ways: the distributor's own order form template, customer-generated PDFs and plain email text. A review of 50 recent orders shows that most use the template.

Increment 1 handles only orders on the template, which are structured and predictable. Everything else goes to the rep as before. Within weeks, the reps are spending noticeably less time keying. Increment 2 adds AI extraction for customer PDFs with a review step. Plain-text emails stay manual for now because the effort is high relative to their volume.

Had the team tried to handle all three formats from the start, the first benefit would have been months away, and the project might have stalled on the hardest case.

Document as you build

For each increment, keep a short design note covering the trigger, steps, rules, exceptions, accounts used and owner. Future maintainers, including your own team a year from now, will rely on it.

Involve users early

Show working increments to the people who do the work. Their feedback on real cases catches design gaps that are invisible on a whiteboard.

An automation that works on a demo case is not ready for production. Technical validation proves it does the right thing across the range of real cases, including the awkward ones.

Levels of testing

Build a test case set

Use real historical cases, anonymized where they contain personal information. A good set includes:

• Typical cases from each main type
• Each known exception from your mapping
• Boundary values: zero quantities, maximum amounts, dates at month end
• Bad data: missing fields, wrong formats, duplicates
• Volume: a realistic peak day's load

Acceptance criteria

Agree on acceptance criteria before testing starts, so the decision to go live is objective. For example:

1. All standard test cases produce the correct output.
2. All exception cases are routed to the correct queue with the right context.
3. No test case causes silent failure or data loss.
4. For AI steps, extraction accuracy on the test set meets the agreed threshold, and all low-confidence results go to review.

Worked example

An engineering office automates timesheet transfer to payroll. The test set includes 40 historical timesheets: standard weeks, overtime, statutory holidays, an employee who changed departments mid-period, and one with a missing project code. Testing reveals the flow mishandles the statutory holiday code, which would have underpaid staff. The fix is made and re-tested before go-live.

Without that test case, the error would have reached employees' pay, the kind of failure that damages trust in automation quickly.

Re-test after changes

Keep the test set. Whenever the automation, a connected system or a business rule changes, run the tests again. This regression testing catches problems that small changes introduce.

Daily operations cannot stop while you introduce automation. Orders must ship, patients must be booked and invoices must be paid. A careful deployment approach protects the business during the switch.

Deployment strategies

A go-live checklist

• Acceptance tests passed and signed off by the process owner
• Users trained on their new role, including exception queues
• Service account, credentials and access confirmed in production
• Monitoring and alerts switched on and tested
• Rollback plan written and understood
• Go-live timed away from peak periods such as month end
• Extra support available for the first days

Plan the rollback

A rollback plan describes how to return to the manual process quickly if something goes wrong. It should state who decides, what triggers a rollback, how in-flight transactions are handled and how staff are told. Keeping the manual procedure documented and staff able to perform it for a period after go-live is part of the plan.

Worked example

A manufacturer automates the transfer of completed production counts from the shop-floor system to the ERP. Because inventory and costing depend on it, the team chooses a two-week parallel run. Supervisors continue entering counts manually, while the automation writes to a test company in the ERP. Each day, the two are compared.

In the first week, a mismatch reveals that scrapped parts were being counted as good. The rule is fixed. The second week matches cleanly, and the team cuts over on a Tuesday, avoiding the Friday shipping rush and month end. The manual procedure stays documented for the next quarter.

Communicate the switch

Tell everyone affected what changes, when, what they need to do differently and who to contact with problems. Surprises during go-live create resistance that lasts long after technical issues are fixed.

Go-live is the beginning of an automation's working life, not the end of the project. Systems update, rules change and data drifts. Without monitoring and clear ownership, automations quietly fail or produce wrong results.

What to monitor

• Run health: successful runs, failures and retries
• Exception volume: number and type of cases routed to people
• Queue age: how long exceptions wait before someone handles them
• Business results: handling time, lead time and error rate compared with the baseline
• AI accuracy: for AI steps, how often reviewers correct the output

Clarify roles with a RACI

R = responsible, A = accountable, C = consulted, I = informed.

A simple runbook

Each automation should have a short runbook: what it does, how to tell if it is working, common failures and fixes, how to pause it and who to call. Store it with the automation inventory.

Worked example

A home care agency's scheduling automation runs smoothly for months. Then the scheduling software vendor releases an update that renames a field. The flow does not fail outright, but it starts leaving visit notes blank. Because the team monitors exception volume and checks a weekly sample, a coordinator notices within days. The builder updates the field mapping, re-runs the test set and documents the change.

Without monitoring, the problem could have continued for weeks.

Plan for change

1. Subscribe to vendor release notes for connected systems.
2. Review each automation at least twice a year for relevance and accuracy.
3. Retire automations that are no longer needed rather than leaving them running.
4. Make sure at least two people know how each critical automation works.

A clear business case helps you decide whether to proceed, secure budget and later prove the value. It does not need to be complicated, but it must be honest about costs as well as benefits.

Benefits

• Labour time saved: annual hours × share automatable × loaded hourly cost
• Error reduction: fewer credits, re-shipments, rework or write-offs
• Faster lead time: earlier invoicing, faster bookings, better customer experience
• Capacity: growth handled without adding headcount
• Risk and compliance: consistent records and controls

Costs

• Build cost: internal time and any partner fees
• Licences and run costs, often monthly per user, flow or transaction
• Testing, training and change management time
• Ongoing maintenance, typically a recurring allowance each year

Worked example

Return to the clinic intake desk from the baseline lesson: 22.5 hours per week of referral keying. Assume 48 working weeks and a loaded cost of $38 per hour, and that 70% of the work can be automated.

Be honest about "savings"

Hours saved are only cash savings if they reduce overtime, temporary staff or future hiring. More often, time is redeployed to higher-value work such as patient follow-up. That is real value, but say so plainly rather than implying a headcount cut. Being clear about this also matters for change management.

Test the assumptions

Run a quick sensitivity check: what if only 50% is automatable, or the build costs twice as much? If the case still holds, you can proceed with confidence. If it collapses, refine the scope or reconsider. The calculator lab after this lesson lets you try this with your own numbers.

Most automation projects that struggle do so for people reasons, not technical ones. Staff may fear for their jobs, distrust the new system or simply keep using old workarounds. A structured approach to change addresses this directly.

The ADKAR model

ADKAR describes the five outcomes each person needs to reach for a change to stick:

Address job concerns directly

People will ask, sometimes silently, "Is this replacing me?" Leaders should answer clearly and truthfully. If the plan is to redeploy time to customer service, quality checks or growth, say so and describe the new work. Vague reassurance followed by surprises destroys trust for future projects.

Involve people early

• Ask frontline staff to help map the process and identify exceptions.
• Invite them into testing; they know the awkward cases.
• Name a respected team member as a champion who can answer questions.
• Give people a clear way to report problems and see them fixed.

Worked example

A distributor automates order entry. The two customer service reps who did most of the keying are worried. The manager meets them before the project starts, shows the error and overtime data, and explains the plan: their time will shift to proactive calls with key accounts and handling order exceptions, which needs their product knowledge.

Both reps help build the test set and spot several exceptions the builder had missed. At go-live, one acts as the champion. Three months later, the manager shares the reduction in shipping errors at a team meeting and credits the reps' input.

Reinforce the new way

Once the automation is stable, retire the old spreadsheets and shortcuts. If the old way remains available, people under pressure will return to it.

After go-live, you need evidence that the automation delivers what the business case promised. Measurement also reveals the next round of improvement.

Compare with the baseline

Use the same definitions you used for the baseline. Measure after the process has settled, typically one to three months after go-live.

These are illustrative numbers continuing the clinic example. Your results should come from your own data.

Benefits realization review

Hold a short review at three and six months. Ask:

1. Are we achieving the expected benefits? If not, why?
2. What are the actual run and maintenance costs?
3. How is the freed capacity being used?
4. What are the top exception types, and can we reduce them?
5. What did we learn that applies to the next automation?

Control plan

Borrowing from the Control phase of Six Sigma's DMAIC, a simple control plan keeps results stable. For each key measure, state the target, how often it is checked, who checks it and what happens if it drifts. A control chart or a simple trend line of exception volume often gives the earliest warning.

Feed the pipeline

Exceptions are improvement opportunities. If many referrals fail because a referring office uses an old form, the fix may be to work with that office, not to add more automation. Each round of PDCA makes the process cleaner and the automation simpler.

Share the results

Report results honestly, including what did not work. Short, factual updates build credibility for the pipeline and help leadership see automation as part of continuous improvement rather than a series of one-off IT projects.

You now have a complete approach for finding, designing, validating and sustaining workflow automation. This final lesson turns it into a practical 90-day plan you can start this week.

The method in one view

1. Find: collect ideas in a pipeline and screen them against candidate criteria.
2. Understand: map the current state, apply Lean to remove waste, and measure the baseline.
3. Prioritize: score effort and value, and start with a quick win.
4. Design: choose the simplest suitable tool, error-proof the future state and plan for exceptions.
5. Govern: service accounts, least privilege, privacy checks and an inventory.
6. Build and validate: small increments, real test cases, agreed acceptance criteria.
7. Deploy: parallel run or pilot, rollback plan, clear communication.
8. Sustain: monitoring, ownership, benefits review and continuous improvement.

A 90-day plan

Common pitfalls to avoid

• Automating before simplifying
• Choosing a tool before understanding the process
• Skipping exceptions and failure testing
• Building under personal accounts without an inventory
• Overstating savings or staying silent on job concerns
• Treating go-live as the finish line

Worked example

Picture a 35-person fabrication shop following this plan. In the first month it logs fourteen ideas and selects automatic work order creation from confirmed sales orders as its quick win. By week ten, a tested flow is ready; a one-week parallel run confirms it, and planners shift to checking flagged jobs. At the three-month review, the team shares results and chooses its second, larger project: an e-commerce to ERP integration.

The first project matters most for what it teaches: a repeatable method and a team that trusts it. Complete the final exam to earn your Chmltech certificate of completion, then begin week one.