Business Automation Examples: McDonald's to Step Functions

Business automation examples include order confirmations, invoice reminders, factory assembly lines, warehouse robots, and cloud workflows that coordinate tasks and approvals. Business process automation uses defined rules and triggers to carry out repeatable work with less manual input. The useful starting point is understanding the work well enough to simplify it and explain what should happen when it goes wrong.

This guide follows that idea from the McDonald brothers' kitchen through KFC, Ford, Toyota, operating rooms, Amazon, and Tesla. It covers the four moves you can use to improve a process, what a small business should automate first, and how AWS Step Functions turns a sequence of tasks into a managed workflow. It also explains the service distinctions you need for Cloud Practitioner and Solutions Architect Associate practice.

What business automation really means

A process is a repeatable sequence with a starting condition, some work, and an outcome. An order arrives, somebody checks it, somebody prepares it, and the customer receives it. Automation transfers some of that execution to software or machinery according to rules you define.

Standardisation and documentation prepare the process for that transfer. A checklist can make a manual handoff more reliable, while a booking form can replace an exchange of messages. Neither requires a physical robot, and neither removes your responsibility for the outcome. SAP's explanation of process automation describes this wider range of workflows, rules, and software tools.

Think of a recipe card as an analogy for a transferable process. The card needs ingredients, instructions, and a way to recognise an acceptable result; an instruction to ask its author leaves the next person dependent on that author. For software, the equivalent questions concern required inputs, task order, success conditions, and failures.

The McDonald brothers' kitchen

Richard and Maurice McDonald opened McDonald's Bar-B-Q in San Bernardino in 1940, with carhops and a 25-item menu. Sales soon topped $200,000 a year, and after the war hamburgers accounted for 80% of them. Those figures made the menu a useful place to reconsider the work, as History's account of the restaurant's development explains.

In 1948, the brothers closed for three months and rebuilt the operation around self-service and a nine-item menu. Paper wrappings and cups replaced plates and silverware, removing dishwashing from the service process. Customers walked up to order instead of waiting for carhops, and the hamburger cost 15 cents.

The layout received the same attention as the menu. The brothers drew their proposed kitchen in red chalk on a tennis court to work through its arrangement; when rain washed it away, they drew it again. Smithsonian's history describes that planning and the initial customer resistance to the new service model.

The lesson is to examine the decisions upstream of a repetitive task. Changing the serving materials removed the need to wash those dishes, while narrowing the menu reduced the work the kitchen had to support. Treating dishwashing alone as the automation problem would have missed the possibility of removing it from the process.

A working kitchen and a repeatable business

Ray Kroc visited in 1954 after the restaurant ordered eight Multimixers. The brothers had already franchised their concept: accounts differ, putting operating franchises somewhere between six and ten. Kroc subsequently became their national franchise agent and opened his Des Plaines restaurant in 1955, as McDonald's corporate history records.

Fred Turner wrote McDonald's first Operations and Training Manual in 1958, as his Nation's Restaurant News profile records. Hamburger University opened in 1961, and Harry Sonneborn's property arrangements made McDonald's its franchisees' landlord. Together, documentation, training, and the landlord relationship supplied instructions, practical preparation, and additional control over the operating model.

That is a useful interpretation of the expansion story, not a complete explanation of its outcome. It doesn't mean the brothers had no written procedures, or that their franchisees routinely ignored them. For your own process, the practical question is whether somebody can learn it, execute it, and receive useful feedback without asking its designer about every decision.

The four moves

You can organise process improvement into four moves: cut, write, hand off, and watch. This is a practical framework for thinking through the examples, not a claim that every successful business followed an identical method. Its value is making you examine the process before choosing a tool.

1. Cut unnecessary work. Ask what each step contributes to the outcome. Remove duplicate entry, unused reports, or approvals that add no useful decision before implementing them.
2. Write the remaining process. Specify its trigger, inputs, acceptable output, and exceptions. Give the instructions to somebody unfamiliar with the work and revise the unclear parts.
3. Hand off the repeatable steps. Assign them to a trained person, a machine, or software. Make clear what the next step receives and how it knows the preceding work succeeded.
4. Watch the result. Examine errors, delays, quality, and the experience of the people doing the work. Give somebody the authority and information needed to intervene.

The order matters because a tool can preserve unnecessary work as easily as useful work. Michael Hammer's article Reengineering Work: Don't Automate, Obliterate puts redesign ahead of mechanising existing routines. Before automating an approval, establish whether that approval should exist and what decision it is supposed to make.

The same moves elsewhere

KFC: make the operating model transferable

Harland Sanders taught independent restaurant operators his chicken preparation method and collected a royalty per chicken sold. KFC had more than six hundred locations when he sold it in 1964 for $2 million. Subsequent owners standardised menus, branding, and stand-alone take-out stores, as the history of KFC describes.

Heublein bought the business in 1971; sources put the price between $239 million and $285 million. That change in sale price does not isolate the financial contribution of standardisation, and Sanders continued visiting restaurants as a quality controller. Use the example to separate teaching a method, organising its delivery, and checking its output: each needs attention.

Ford: measure the effects on workers too

Ford's assembly-line experiments progressively reduced Model T build time from 12.5 hours to 93 minutes. The Henry Ford museum also reports labour turnover of around 370%, alongside the difficulty of retaining workers for repetitive jobs. Its account of the five-dollar day explains that the later pay arrangement was conditional profit-sharing, motivated partly by retention.

For process design, this broadens what you should measure. Faster completion can coexist with training costs, fatigue, or difficulty keeping the operation staffed. A useful review asks how the process affects the people expected to sustain it.

Toyota: build in the ability to stop

Toyota describes its production system through jidoka and just-in-time production. Jidoka, loosely translated as automation with a human touch, includes detecting abnormalities and stopping: equipment can stop automatically, or an operator can use the stop cord. The roots include Sakichi Toyoda's automatically stopping looms.

Just-in-time means making what is needed, when needed, in the amount needed. Applied to your own workflow, the useful design questions concern demand, acceptable output, and the conditions that require intervention. A warning needs a response path, and the person responding needs permission to change what happens next.

The operating room: standardise critical checks

A study of the World Health Organization's 19-item surgical checklist involved eight hospitals in 2007–2008. Deaths fell from 1.5% before implementation to 0.8% afterward, while complications fell from 11.0% to 7.0%. The published study reported an association with the checklist programme; it didn't show that paper alone caused those changes.

This example concerns a structured manual process rather than software automation. Its relevance is the preparation: people agree on checks and handoffs before delegating execution. Standardising a check still leaves room for professional judgement about the situation it reveals.

Amazon: automate movement within the process

Amazon announced an agreement to acquire Kiva Systems in March 2012 for approximately $775 million. Kiva's approach brought shelves to workers, changing how products moved through picking rather than requiring the worker to travel to each shelf. The acquisition announcement describes the technology's role in fulfilment.

The useful comparison is with the handoff in a software workflow. You can improve an operation by changing how work reaches its next station, even when that station still requires a person. Look for waiting, movement, and repeated information transfer alongside the task itself.

Tesla: more machinery can mean more complexity

In 2018, Elon Musk acknowledged that Tesla had automated too much and described removing a complex conveyor network. Tesla also added a Model 3 assembly line in a large parking-lot tent, reported by Wired. The account doesn't say the tent line was wholly manual.

The practical lesson is to keep the proposed handoff proportionate to the work you understand. Before extending automation, test whether it handles the actual inputs and whether you can recover when it fails. A larger automated system can give you more dependencies to diagnose.

Why good small businesses stay small

Owner dependence is one possible constraint on growth. If every quote, scheduling decision, and exception comes back to you, delegating the physical work still leaves decisions waiting for your attention. Michael Gerber's argument in The E-Myth encourages owners to develop how the business operates alongside doing its day-to-day work.

Treat that as a management argument, not a universal explanation for business size or failure. The US Chamber's discussion of business failure lists problems including cash flow, insufficient demand, poor management, financial challenges, and inventory mismanagement. Lack of automation is absent from its list, and software cannot establish demand or make an unsuitable product profitable by itself.

There is stronger evidence for the value of management practices in a particular setting. A randomised experiment offered management consulting to selected Indian textile plants and compared them with control plants. The researchers reported a 17% productivity increase in the first year and more plant openings within three years in their published research summary.

That result supports taking operational routines seriously; it does not promise the same return from purchasing an automation application. Decide what you want from the business before choosing its next process change. Delegation can be worthwhile because it reduces dependence on your availability, even when expansion is not your goal.

What to automate first, and what to leave alone

A practical starting rule is to choose frequent, predictable work with a clear output and a recoverable mistake. Order acknowledgements, booking confirmations, pickup reminders, and invoice preparation are candidates to examine. Start with the process whose rules you can explain and whose result you can check.

There is a relevant vendor-published example from Sweet As Choice Bakery in Auckland. Thryv's case study reports invoice creation falling from 15–20 minutes to 1–2 minutes. Those are the vendor's reported customer figures, not an independently established saving you should expect for your business.

Work through a hypothetical cake shop

Imagine a cake shop where orders arrive by phone and text, and staff ask the owner about every change. Begin by reviewing what customers actually order and which decisions genuinely need the owner's judgement. The goal is to find a repeatable path while keeping unusual requests visible.

1. Simplify intake. Agree what information an order requires and remove duplicate recording. Keep a way for customers to describe a request that does not fit the standard choices.
2. Write the decisions. Define what staff can confirm, change, or refund themselves. Explain when they should escalate instead of filling the gap with a guess.
3. Test the instructions manually. Let somebody else follow them and note every unclear handoff. Revise the procedure before connecting applications to carry it out.
4. Automate a bounded task. For example, send an acknowledgement after an order is recorded. Make its wording distinguish receipt of a request from acceptance of a custom commission.
5. Review the outcome. Check confirmations against actual orders and investigate exceptions. Expand the process only when you understand the failures and know how to correct them.

Keep judgement and recovery available

Keep people involved in unusual commissions, quality decisions, and repairing a damaged customer relationship. You can automate collecting information or notifying the right person while leaving the decision with them. Define that boundary explicitly so a failed automated step does not quietly become an unresolved customer problem.

Lisanne Bainbridge's Ironies of Automation describes the difficulty of leaving people to monitor automation and handle its hardest cases. Reduced hands-on practice can make intervention harder when it is needed. As a design response, keep recovery instructions usable and give the people responsible opportunities to practise them.

Automation in the cloud: Step Functions as the recipe card

In AWS, Step Functions is the managed workflow orchestrator: its state machine defines how tasks proceed, while an execution represents a run of that process. A Task state can invoke Lambda, and a Standard workflow provides execution history for inspecting progress. AWS's Step Functions introduction explains the relationship between workflows, states, and executions.

The surrounding services have distinct roles. EventBridge routes events, SQS holds messages for consumers, and Lambda runs code without you managing servers. SNS distributes a published message to subscribers.

• Step Functions: coordinates task order and tracks a workflow's progress / SQS: buffers messages between components; queues alone do not define the whole business process.
• EventBridge: routes an event to a target / Step Functions: coordinates the work that follows, including defined failure paths and waits.
• Lambda: performs a unit of work / SNS: distributes a message to interested subscribers. Neither role, by itself, describes the progress of an entire order.

For the messaging distinctions, read the SQS, SNS, and EventBridge guide. The AWS Lambda guide explains the compute component in more detail. Choose each component according to the responsibility you need it to carry.

Separate the task from its recovery policy

Consider a hypothetical order workflow that validates a request, prepares fulfilment, and records the outcome. Write down what each task produces, which failures merit another attempt, and where unrecoverable failures should go. These decisions are the workflow's operating instructions.

Step Functions provides Retry for configured retry handling and Catch for directing a failed task to a fallback path. Define that path deliberately: it might request manual investigation or perform compensating work. Catching an error is a routing decision, not proof that earlier business actions have been undone.

In a Standard workflow, the execution history helps an operator locate the task that failed. You still need to decide what the operator should do with that information. For the hypothetical shop, the runbook should explain how to recognise an incomplete order and who may resolve it.

Let the workflow wait for a person

A process can automate routine work while pausing for an approval. Step Functions supports a callback pattern using a task token, allowing a Standard workflow to wait for a response. This is useful when the next task depends on a human decision rather than another calculation.

For the hypothetical cake shop, picture a custom commission that needs the owner's acceptance. The design should distinguish an order awaiting review from an order rejected or already in fulfilment. Making those states explicit gives staff a shared description of the work still to do.

Exam traps

The Cloud Practitioner certification calls for recognising service roles, while Solutions Architect Associate practice adds architectural requirements such as recovery and visibility. Read the complete requirement before picking a familiar service. The following practice scenarios help you separate related responsibilities.

Queues do not supply the entire workflow

In a practice question on Step Functions orchestration, directly chained Lambda functions leave operators struggling with incomplete work and custom progress tracking. The requirement combines retries, state tracking, and visibility, which points to a Standard workflow with Retry and Catch. Adding queues improves the handoffs but leaves the team responsible for the overall process and its progress model.

Human approval can be part of automation

A practice question on a loan approval workflow includes a wait for an underwriter alongside automated tasks. Step Functions coordinates that sequence and its approval wait. Sending a notification or holding a message addresses a piece of the process without supplying the requested coordination.

Routing, scheduling, and fanout have different jobs

A practice question on event routing and scheduling combines resource events with scheduled work. EventBridge handles event routing, and EventBridge Scheduler supplies scheduled invocations. A workflow service would coordinate subsequent tasks if those tasks also needed a defined sequence.

By contrast, a practice question on fanout notifications asks how to publish a message for independent recipients. SNS supplies the publish-and-subscribe relationship. Identify whether the requirement concerns distributing information or coordinating dependent work before choosing the service.

Moving polling does not remove it

A practice question on S3 event notifications versus polling contrasts detecting uploads through events with repeatedly listing a bucket. Scheduling Lambda to perform the same listing preserves the polling design. The event notification and queue approach changes how work is discovered and buffers it for consumers.

Continue with the Cloud Practitioner practice questions and the Solutions Architect Associate practice questions. For each scenario, identify what starts the work, what performs it, and what must remember its progress before evaluating the options.

Frequently asked questions

What is an example of business automation?

Sending an acknowledgement after an order is recorded is a simple example. More involved examples include warehouse movement and a workflow that validates an application, waits for approval, and sends the decision.

What should a small business automate first?

Start by examining frequent tasks with clear rules, checkable outputs, and recoverable errors. Confirmations, reminders, and invoice preparation are useful candidates after you simplify the process and test its instructions.

Was the McDonald's Speedee Service System automation?

It was a redesigned, standardised operating process that prepared work for repeatable execution. Its menu reduction, self-service, and specialised tasks show the process design behind automation, even where people still performed the work.

What is AWS Step Functions used for?

It coordinates tasks as a workflow, including their sequence and configured error handling. Standard workflows also support processes that wait for a human response and provide execution history for investigating progress.

What is the difference between Step Functions and SQS?

Step Functions manages workflow progression, while SQS holds messages for consumers to process. A queue can be part of a larger automated process, but queues alone leave its overall state and coordination for you to design.

Watch the full episode

The episode's spoken comparisons make the jump from a restaurant handoff to a cloud workflow easier to follow, and its discussion gives you time to weigh where human judgement still belongs. Two Brothers Built McDonald's. A Salesman Took It. on YouTube