lean-stack
Menu

How to write an A3 report: step by step, with an example

How to write an A3 report section by section, with a worked A3 example and the coaching questions that turn A3 problem solving into learning.

Updated October 25, 2026 · 9 min read · Root Cause Analysis Software

By the lean-stack editorial team

To write an A3 report, work through six boxes on one sheet: background, current condition, goal, root cause, countermeasures and follow-up.

An A3 is a single sheet of paper, named after its size, that tells the story of a problem from background to follow-up. The page limit forces you to understand the problem well enough to explain it simply.

John Shook's book Managing to Learn describes the A3 as a way for managers to coach. The steps below follow the usual layout.

What you need before you start

You don't need a solution to start an A3. Starting with one already chosen is the quickest way to weaken it. You do need:

  • A process owner: Someone accountable for the area who can support decisions.
  • A specific problem: Not a broad frustration such as 'communication is poor'.
  • Baseline evidence: Counts, timestamps, examples or observations that show the problem exists.
  • Input from people close to the work: They see details that reports miss.
  • Time to observe: The A3 depends on what actually happens, not what people assume.
  • A coach: Someone who will ask questions about each box, not fill it in for you.

The layout

The left side tells the story so far: background, current condition, goal and root cause. The right side holds the countermeasures, the action plan, the results and the follow-up. Read left to right, the sheet follows a PDCA cycle: the left side is Plan, and the right side covers Do, Check and Act.

A title bar runs across the top with the problem name, the owner, the coach and the date. Keep the date of each revision. An A3 is rewritten several times as the owner learns more, and the old versions show how the thinking changed.

1. Background and problem statement

Explain why this problem matters now, in terms of safety, quality, delivery, cost or customers. Then describe the gap between what should happen and what actually happens.

Do not hint at a cause or a solution yet. Coaching question: would someone from another department understand why it is worth solving?

A vague statement such as 'the team is inefficient' gives nothing to investigate. A useful one names the process, the measured gap, the time frame and the impact. For example: 'Over the past six weeks, 18% of tickets in the billing queue missed the two-business-day response target.'

If the problem feels too large, split it. 'Order fulfillment delays' might become 'late picking confirmations for priority orders on the afternoon shift'. A narrower problem makes every later box easier.

2. Current condition

Go and see at the gemba. Draw the process as it really works, with data on how often the problem occurs, where and how large it is.

Coaching question: how do you know? Was this observed, or taken from a report?

3. Goal

Set a specific, measurable target and a date. The goal should close all or part of the gap in the problem statement.

Coaching question: how will we know, on the date, whether we hit it? If the answer needs a new measure, set that measure up now, before any change is made.

Don't write a solution as the goal. 'Install a new dashboard' is a possible countermeasure. 'Make overdue work visible before the daily cutoff' describes the result you want.

4. Root cause analysis

Use five whys, a fishbone diagram or both to move from symptoms to causes. Verify the likely causes with data or a quick test before acting.

Coaching question: if you removed this cause, would the problem disappear? How could you check that cheaply?

Skipping this step has a measurable cost. In a NIST survey of US manufacturers, plants that relied most on reactive maintenance, fixing equipment after it fails, had 3.3 times more downtime and 16 times more defects than plants that relied on it least.

5. Countermeasures and plan

List countermeasures that address the verified causes, each with an owner and a date. Call them countermeasures, not solutions, because they are hypotheses until the results come in.

Coaching question: which root cause does each countermeasure address? A countermeasure that maps to no verified cause is a guess and should come off the sheet.

Five checks for each countermeasure

Run each proposed action through these questions before it goes on the sheet:

  • Does it address a verified root cause? If not, it is a side task.
  • Is it within scope? If the team cannot test it, break it into smaller actions.
  • Does it rely on memory or reminders? Changes built into the process last longer than reminders.
  • Could it cause a problem elsewhere? Check the steps downstream.
  • How will we know it worked? Link it to a follow-up measure.

If a date is not known yet, write down the decision that is still needed rather than inventing a date. An A3 should show uncertainty so the team can resolve it.

6. Follow-up

Check results against the goal. If the target was met, update the standard work so the gain sticks. If not, return to the root cause analysis.

A standard only holds if people can follow it. In the Uptime Institute's 2025 outage analysis, 85% of major data center outages caused by human error stemmed from staff not following procedures, or from flaws in the procedures themselves.

Coaching question: what did we learn that another team could use? Share the A3 with teams that run a similar process, and note any problems the work uncovered that need an A3 of their own.

Check two kinds of measure. A result measure shows whether the outcome improved, such as fewer late orders. A process measure shows whether the new method is being followed, such as orders entered with all required fields. A good result with no process change is often luck.

When the A3 closes, name who will watch the process from now on, how, and what would trigger reopening the problem.

A3 report example

The example below fills in every box for one problem. It is illustrative: the company and numbers are made up to show the level of detail each box needs, not taken from a real case.

Title bar: Late shipments on the Series B pump line. Owner: order desk lead. Coach: operations manager. Version 3, dated at each revision.

Background: the largest customer for Series B pumps requires 95% of orders to ship within two working days. The contract is up for renewal in six months, and the customer has raised late orders twice this quarter.

Current condition: over the last eight weeks, 78% of Series B orders shipped within two days (312 of 400). The owner followed 20 late orders from receipt to dispatch. 14 of them waited more than a day at the credit check, 4 waited for a part, and 2 had address errors. Picking and packing took under three hours for every order observed.

Goal: 95% of Series B orders ship within two working days, measured weekly, by the end of next quarter.

Root cause: five whys on the credit delay. Why did orders wait? The credit check had not been done. Why not? Checks run once a day, at 4 pm. Why once a day? The credit team batches them to clear in one sitting. Why batch? Each check means opening three systems, so the team avoids switching back and forth. Why three systems? Customer limits, open invoices and payment history sit in separate tools. The team tested the cause by running checks every two hours for one week. That week, 2 orders waited more than a day for credit, against 14 in the 20 late orders studied before.

Countermeasures: 1. Orders under the customer's approved limit with no overdue invoices skip the manual check; owner: finance systems analyst; due in four weeks. 2. Manual checks run at 10 am and 2 pm instead of 4 pm; owner: credit team lead; due next week. 3. A one-screen credit view that pulls the three sources together; owner: IT; due in ten weeks. The part shortages go to a separate A3, owned by purchasing.

Results and follow-up: by week six, 93% of orders shipped within two days. The credit view went live in week ten, and over weeks eleven to fourteen 96% of orders shipped on time. The new check rules went into the order desk standard work, and the weekly on-time chart stays on the team board. Purchasing's A3 on part shortages is still open.

A second example: an office queue

An illustrative office case, shorter, to show the same thinking outside a factory. A billing support team misses its two-day first-response target on a growing share of tickets.

Current condition: tickets arrive through a general request form. The billing category is optional, urgency is set inconsistently, and agents scan descriptions to decide what to handle first.

  1. 1

    Why do tickets miss the target? Many wait until the second or third day before anyone opens them.

  2. 2

    Why do they wait? Agents work oldest first, but priority and complexity are not visible in the queue.

  3. 3

    Why are they not visible? The form does not capture billing category or urgency consistently.

  4. 4

    Why not? Customers and intake staff use a general form with optional fields.

  5. 5

    Why has nobody changed it? No one was assigned to own the billing intake rules after the support system changed.

The root cause is form design and missing ownership, not agent effort. Countermeasures follow from that: a required billing category, a queue view for urgent or uncategorized tickets, a named owner for intake rules and a 10-minute daily check of tickets at risk.

A3 template checklist

Draw the A3 by hand on an 11 x 17 inch or A3 sheet, or use a single landscape page in a document. Before you show it to a coach, check each box against these questions.

Title bar: does it name the problem, the owner, the coach and the date of this version?

Background: would someone from another department see why this matters now, in terms the business tracks?

Current condition: is there a picture of the process, and is every number something you saw or measured yourself?

Goal: is there one measure, a target value and a date?

Root cause: does the chain of causes rest on evidence, and was the main cause tested before acting?

Countermeasures: does each one link to a verified cause, with an owner and a due date?

Follow-up: is there a date to check results, and a plan for what happens if the goal is missed?

Common mistakes when writing an A3

Even a neat A3 fails if the thinking behind it is weak. These are the usual problems:

  1. 1

    Starting with the solution. 'we need new software' in the problem statement skips the cause.

  2. 2

    Vague words. 'inefficient', 'poor' and 'broken' need a measured explanation.

  3. 3

    Skipping observation. Reports show symptoms, while going to see often shows why.

  4. 4

    Blaming people. An A3 improves systems and standards, not personal performance.

  5. 5

    Symptoms as causes. 'tickets are late' is a symptom. The cause explains why they become late.

  6. 6

    Root cause without data. A cause nobody verified is a guess.

  7. 7

    Too many actions. A long list hides the few countermeasures that matter.

  8. 8

    No follow-up. Without checking results, the A3 is a plan, not a learning record.

  9. 9

    Working alone. An A3 filled in without a coach asking questions misses most of its value.

  10. 10

    Overfilling the page. The sheet should guide a conversation, not hold every data point. Keep backup data in a separate file.

For larger, data-heavy problems, a DMAIC project may suit better. Root cause analysis software can hold A3s for teams across sites.

Frequently asked questions

What is A3 problem solving?
It is Toyota's habit of working through a problem on one sheet of A3 paper, so the owner, the coach and the people affected can all read the same story. John Shook's Managing to Learn (2008) describes how Toyota managers used it to develop people, not only to fix problems. The format matters less than the conversations it starts.
What are the sections of an A3 report?
Problem-solving A3s use the six boxes in this guide. Toyota also uses other A3 types with different boxes: a proposal A3 asks for a decision, and a status A3 reports progress on an earlier plan. Pick the type before you start, because a proposal written in problem-solving boxes confuses readers.
Who writes an A3?
The person who owns the problem writes it, usually with a coach or mentor. The coach asks questions rather than writing it for them.
What are common A3 mistakes?
Beyond the mistakes above, watch for an A3 that never changes. If version one is also the final version, the owner probably filled in boxes without going to see the process or testing the cause. Another sign is a countermeasure list longer than the list of verified causes.

Choosing Root Cause Analysis Software?

Read the buying guide: what to look for, mistakes to avoid and questions to ask vendors.

Open the guide

Related guides

Sources

Books and papers show their publication year. Web pages show the month we last checked them.

  1. 1.John Shook, Managing to Learn: Using the A3 Management Process (Lean Enterprise Institute, 2008)
  2. 2.Durward K. Sobek II and Art Smalley, Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System (Productivity Press, 2008)
  3. 3.Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production (Productivity Press, 1988)
  4. 4.Mike Rother, Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results (McGraw-Hill, 2009)
  5. 5.Douglas S. Thomas and Brian A. Weiss, NIST, Economics of Manufacturing Machinery Maintenance: A Survey and Analysis of U.S. Costs and Benefits (NIST AMS 100-34) (nist.gov, checked October 2026)
  6. 6.Uptime Institute, Uptime Announces Annual Outage Analysis Report 2025 (uptimeinstitute.com, May 2025)

For vendors

Built a lean tool?

Submit it for review. Every tool is checked against our listing criteria and researched from public sources. Approved tools join their category in the next published batch.