Practical guides for improving a business process.

1. 01

   Choose one start and end

   Name the event that starts the process and the evidence that shows it is complete. A process such as 'handle operations' is too broad; a process such as 'receive and approve a service request' can be mapped.

2. 02

   Record the real sequence

   Follow a recent sanitized example. List each person, tool, input, output, decision, and exception in the order it actually occurred, including workarounds.

3. 03

   Separate repetition from judgment

   Mark copying, routing, reminders, formatting, and recurring checks separately from decisions that need experience, authority, or context.

CheckpointReady to continue when a process owner can explain the same current flow and identify where exceptions go.

1. 01

   Name each source and destination

   For every field, record where it originates, where it should go, which system owns the final value, and who may authorize access.

2. 02

   Design for retries and duplicates

   Decide how the receiving system recognizes work it has already processed and how an operator can tell whether a retry is safe.

3. 03

   Make failures visible

   Define what happens when a vendor is unavailable, a field is missing, access expires, or the destination rejects the request. Include a review queue and a way to reconcile records afterward.

CheckpointReady to continue when ownership, access, duplicate behavior, failure handling, and rollback have named answers.

1. 01

   Check the tools already in use

   Review existing configuration, forms, reports, and supported integrations first. A better setup may solve the problem without custom software.

2. 02

   Define one operating job

   Describe the exact job the interface supports: reviewing exceptions, approving a change, finding a record, or seeing work that needs attention.

3. 03

   Specify every state

   Include empty, loading, error, unavailable, unauthorized, and completed states. The tool should help a person understand what happened and what action is allowed next.

CheckpointReady to continue when the tool has a named user, one clear job, authoritative data sources, and a defined failure path.

1. 01

   Choose a bounded language task

   Classification, extraction, summarization, and drafting are candidates when the input and expected output can be described clearly.

2. 02

   Constrain the output

   Require a known structure, validate every field, limit the information sent, and define what happens when the model refuses, times out, or returns an uncertain answer.

3. 03

   Keep authority outside the model

   Pricing, permissions, arithmetic, payments, contracts, external messages, production changes, and deletion should follow application rules and the required human approvals.

CheckpointReady to continue when the task has a safe fallback and a wrong answer cannot silently cause an external or high-impact action.

1. 01

   Define evidence of correct operation

   Choose the records, alerts, reconciliations, and reports that show whether expected work completed and whether exceptions received attention.

2. 02

   Assign response and change ownership

   Name who reviews failures, who may approve a change, how vendor updates are assessed, and which requests are outside the agreed scope.

3. 03

   Prepare disable and recovery paths

   Document how to stop new effects, preserve evidence, restore the last known safe configuration, and verify that recovery actually worked.

CheckpointReady to continue when normal operation, failure review, approved change, disable, and recovery each have an owner.