Article 4: Map the System Before Changing the Process
See the full customer-to-delivery system before redesigning one step.
Domain 1. Article 4.
By Edwin Angulo | Co-Founder, Angulo & Morsa Legacy Consulting LLC
Published July 27, 2026 | Last reviewed July 27, 2026
EXECUTIVE TAKEAWAY
An operational problem rarely exists inside one isolated task.
Customer outcomes are produced by a connected system of suppliers, inputs, decisions, roles, technologies, queues, handoffs, and downstream processes. A failure visible in one department may have been created earlier, amplified during a handoff, or left undetected by a missing control.
Before changing a process, leadership should map how the current system actually works.
A useful mapping sequence begins with:
The customer’s end-to-end journey
The system boundaries
A high-level SIPOC
The current-state process
Inputs and outputs
Internal and external suppliers
Internal and external customers
Decision points
Queues and waiting
Information handoffs
Rework loops
Known and suspected failure points
The purpose of mapping is not to create an attractive diagram.
It is to develop a shared and testable representation of how the organization currently converts customer demand, information, labor, technology, capacity, and decisions into an operational result.
Article 1 established the measurable performance gap.
Article 2 explained how to develop competing, testable explanations for that gap.
Article 3 established what counts as evidence and why several sources must usually be triangulated before root cause is accepted.
This article addresses the next requirement:
Where in the connected system could the performance gap have been created, amplified, transferred, or left undetected?
The diagnostic sequence is:
Define the measurable operational gap.
Develop competing hypotheses.
Identify and evaluate relevant evidence.
Map the system in which the evidence was created.
Locate decisions, queues, handoffs, rework, and failure points.
Determine which system conditions are sufficiently supported as causes.
Design and test a countermeasure.
Measure whether the original gap improves.
Establish ownership and controls.
Without a defined gap, process mapping can become an unfocused documentation exercise.
Without competing hypotheses, the map may be designed to support management’s preferred conclusion.
Without evidence, the map may reflect policy, memory, or opinion rather than the current operating condition.
Without a system map, evidence can be interpreted too narrowly because leadership sees the symptom but not the connected process that produced it.
The operating principle is simple:
Do not redesign one step until you understand the system that supplies it, constrains it, receives its output, and determines whether the customer ultimately succeeds.
A Process Is Part of a Larger System
A process is a connected set of activities that transforms inputs into outputs.
A system is the broader network of processes, people, information, technology, suppliers, customers, rules, capacity, and feedback mechanisms that produces an organizational result.
Consider a company experiencing delayed customer follow-up.
Management may define the affected process as:
An employee receives an inquiry and contacts the prospective customer.
That description may be technically accurate, but it is incomplete.
Before the employee can act:
The customer must find the business.
The customer must select a contact channel.
The inquiry must enter a system.
The system must capture usable information.
Someone or something must determine whether the inquiry is qualified.
Service area and service availability may need to be checked.
The inquiry must be assigned.
The assigned employee must receive and recognize the assignment.
The employee must have the information, authority, time, and capacity to respond.
After the employee acts:
The contact must be documented.
The customer must understand the next step.
Scheduling or another downstream process may begin.
Unresolved inquiries must be monitored.
Management must be able to distinguish completed work from overdue work.
A delayed response may appear at the employee-contact step.
The delay may have been created hours earlier during intake, qualification, capacity review, or assignment.
The same symptom could also be produced by several different system conditions:
The customer submitted incomplete information.
The website and CRM use incompatible fields.
Inquiries are reviewed in batches.
Assignment authority is restricted to one person.
Employees receive several conflicting notifications.
Service availability is unknown.
Follow-up occurs but is not documented.
The queue exceeds available capacity.
Managers review the wrong status measure.
The process step where the problem becomes visible is not necessarily the process step where it originated.
SYSTEM PRINCIPLE
Ask two different questions:
Where did the performance failure appear?
and:
Where in the connected system could that result have been created, delayed, distorted, amplified, or left undetected?
The first question locates the symptom.
The second begins the diagnosis.
The Customer Experiences One Connected Journey
Organizations divide work into departments, job descriptions, software platforms, budgets, and management responsibilities.
Customers usually do not experience those internal divisions.
A customer does not think:
Marketing completed its task successfully, but intake, operations, and scheduling are separate functions.
The customer experiences one business.
From the customer’s perspective, the journey may be:
Recognize a need → find the business → understand the offer → submit an inquiry → receive a response → determine fit → schedule → receive the service → understand the outcome → obtain follow-up or support
The customer may interact with:
A search result
A website
An advertisement
A contact form
A telephone line
An automated email
An intake employee
A salesperson
A scheduler
A service professional
An invoice
A follow-up message
The organization may own each touchpoint separately.
The customer experiences them as one connected journey.
This is the basis of Angulo & Morsa’s “one connected customer journey” model:
What the customer experiences and what the organization must do internally to deliver that experience are two views of the same operating system.
The customer-facing journey and the internal workflow should therefore be examined together.
A customer-journey map without the underlying operating process may identify frustration without explaining what produces it.
An internal process map without the customer journey may improve departmental efficiency while making the overall experience worse.
For example, an intake team may reduce its handling time by forwarding every inquiry immediately without checking completeness.
The intake metric improves.
Sales employees receive more incomplete records, clarification increases, customer response slows, and the end-to-end journey deteriorates.
The local process became faster.
The connected system became less effective.
Local Optimization Can Damage the Whole Journey
A department can achieve its own target while the customer outcome declines.
Examples include:
Marketing increases lead volume beyond the capacity of intake and sales.
Intake reduces handling time by forwarding incomplete information.
Sales closes inquiries quickly by marking difficult records as unqualified.
Scheduling maximizes calendar utilization but creates excessive customer waiting.
Service teams increase daily volume while documentation and follow-up fall behind.
Billing reduces outstanding accounts by requiring payment steps that increase abandonment.
Management reduces labor hours while queues and owner intervention increase.
Each local decision may look rational inside one functional boundary.
The total result may be:
More rework
Longer elapsed time
Greater customer confusion
Higher employee workload
Increased abandonment
Reduced conversion
More management escalation
Lower service reliability
A system map helps leadership see these relationships.
It shows that the output of one process becomes the input to another.
If one function improves its own performance by transferring incomplete, delayed, or defective work downstream, the organization has not eliminated the problem.
It has moved the problem.
CONNECTED-JOURNEY PRINCIPLE
A process change is not an improvement merely because one department becomes faster, cheaper, or easier to manage.
The change must improve the intended customer and organizational outcome without creating unacceptable downstream consequences.
Use Several Maps at Different Levels
No single mapping method answers every diagnostic question.
A useful operations diagnostic may use several related views of the same system.
1. Customer-journey map
Shows what the customer is trying to accomplish across time, channels, touchpoints, and organizational boundaries.
It helps identify:
Customer goals
Customer actions
Questions and decisions
Touchpoints
Channel changes
Waiting
Confusion
Repeated information requests
Abandonment
Moments of trust or frustration
Whether the customer understands the next step
2. SIPOC
Provides a high-level view of the process and its boundaries.
SIPOC stands for:
Suppliers
Inputs
Process
Outputs
Customers
It helps establish:
Where the process begins and ends
What the process requires
Who supplies those requirements
What the process produces
Who receives or depends on the outputs
3. High-level current-state process map
Shows the major activities and decisions through which work currently moves.
It helps leadership see:
The overall sequence
Major roles
Key decisions
Primary handoffs
Major queues
Where the process crosses functions or systems
4. Detailed current-state process map
Shows the process at a closer level.
It may include:
Individual steps
Decision criteria
Exceptions
Rework
Waiting
Duplicate entry
Parallel work
Informal communication
System interactions
Approval requirements
Failure points
Escalation paths
5. Evidence overlay
Connects the map to the findings from Article 3.
The map can be annotated with:
Transaction volumes
Completion rates
Elapsed time
Touch time
Error rates
Queue size
Rework frequency
Customer abandonment
Data-quality limitations
Interview findings
Observed workarounds
Known and suspected failure points
These views are related, but they are not interchangeable.
A practical metaphor is to think of them as different levels of a map application.
The customer journey is the regional view.
The SIPOC establishes the territory and major connections.
The high-level process map shows the main roads.
The detailed current-state map shows intersections, turns, bottlenecks, and detours.
The evidence overlay shows traffic volume, delays, accidents, and road closures.
Leadership should not redesign one intersection without understanding where the traffic came from, where it is going, and whether changing that intersection will create congestion somewhere else.
Begin With the System Boundary
A map needs a defined beginning and end.
Without boundaries, the team may attempt to map the entire business.
That produces complexity without necessarily improving the decision.
Article 1 established that a problem statement should define the initial scope in operational terms.
For example:
The initial scope begins when a qualified inquiry enters the website form, telephone line, or approved referral channel and ends when the first personalized follow-up is documented.
Article 4 uses that scope to build the map.
The starting boundary should identify the event that initiates the process.
Examples include:
A customer submits an inquiry.
A referral is received.
An order is placed.
An appointment is requested.
A work order is approved.
A complaint is recorded.
An employee accepts an offer.
An invoice becomes due.
Inventory falls below a defined level.
The ending boundary should identify the event or output that completes the scoped process.
Examples include:
First personalized follow-up is documented.
The appointment is scheduled.
The order is delivered.
The customer accepts the completed work.
The complaint is resolved.
The employee completes onboarding.
Payment is received.
Inventory is replenished and recorded.
The boundary should be broad enough to capture the process that could reasonably produce the performance gap.
It should be narrow enough to support focused investigation.
A boundary that is too narrow
Suppose the scope begins:
When the salesperson opens the assigned CRM record.
This excludes the intake, qualification, and assignment delays that may have consumed most of the response period.
The map may conclude that employees respond quickly after opening the record.
That conclusion would be accurate inside the narrow boundary but misleading about the customer’s actual waiting time.
A boundary that is too broad
Suppose the scope is:
Everything from marketing strategy through customer retention.
That scope may include:
Advertising
Search visibility
Website design
Intake
Follow-up
Sales
Scheduling
Service delivery
Billing
Retention
Referral generation
Those processes may be connected, but mapping all of them in detail would exceed the decision required for a defined follow-up problem.
Use nested boundaries
The solution is often to use two levels:
End-to-end journey boundary
Shows how the scoped process fits into the customer’s larger objective.
Diagnostic process boundary
Defines the process segment being investigated in detail.
For the qualified-inquiry example:
End-to-end journey
Customer recognizes need → finds the business → submits inquiry → receives response → schedules → receives service → completes payment → receives follow-up
Diagnostic boundary
Qualified inquiry received → inquiry captured → inquiry qualified → inquiry assigned → personalized follow-up completed and documented
This preserves the wider customer context without allowing the diagnostic to become unlimited.
SIPOC: Establish the High-Level System
ASQ describes SIPOC as a high-level tool for identifying the suppliers, inputs, process, outputs, and customers associated with a process before developing a more detailed flowchart.
SIPOC is useful early because teams frequently begin with different assumptions about:
Where the process starts
Where it ends
What the process is supposed to produce
Who supplies critical information
Who receives the output
What constitutes a complete input
Which customer requirements matter
A SIPOC should remain high-level.
It is not intended to show every click, message, exception, or decision.
Its purpose is to establish the operating landscape.
Suppliers
Suppliers provide the information, materials, technology, capacity, authorization, or demand required for the process to operate.
Suppliers may be external or internal.
External suppliers may include:
Prospective customers
Existing customers
Referral partners
Vendors
Insurance organizations
Government agencies
Lenders
Technology providers
Shipping carriers
Contracted service providers
Internal suppliers may include:
Marketing
Sales
Intake
Scheduling
Finance
Human resources
Information technology
Operations
Management
A previous process step
For the inquiry-follow-up process, suppliers might include:
The prospective customer supplying the request and contact information
Marketing supplying the contact channel and messaging
The website or telephone provider transmitting the inquiry
Management supplying qualification and routing rules
Operations supplying current service-area and capacity information
The CRM supplier providing the record and notification capability
A supplier is not necessarily a vendor.
Any person, function, process, or system that provides a necessary input can be a supplier.
Supplier questions
Ask:
Who or what provides each required input?
Is there one supplier or several?
Are the requirements communicated to the supplier?
Does the supplier know what “complete” means?
How often is the input missing, late, inaccurate, or unusable?
Can the process reject or correct a defective input?
Does the organization measure supplier performance?
Is the supplier internal, external, human, or technological?
Many downstream failures begin with an input that never met the process requirement.
The downstream employee may appear to perform poorly because the upstream supplier provided incomplete information.
That does not automatically excuse the downstream process.
It shows that the system must either improve the input or reliably detect and correct the defect.
Inputs
Inputs are the information, materials, resources, authorization, and conditions required to perform the process.
For the inquiry-follow-up process, inputs may include:
Customer name
Contact information
Requested service
Customer location
Preferred communication channel
Time of inquiry
Qualification criteria
Service-area rules
Service availability
Routing rules
Assignment authority
Response-time standard
CRM record
Employee availability
Approved communication templates
Documentation requirements
The organization should distinguish between an input and a complete, usable input.
A telephone number is technically an input.
An invalid telephone number is not a usable input for telephone follow-up.
A service request is an input.
A vague message stating “call me” may not contain enough information to support qualification or routing.
An assignment rule is an input.
A rule that employees interpret differently is not a stable operational input.
Input questions
Ask:
What does the process require before work can begin?
Which inputs are mandatory?
What makes each input complete and usable?
Where is the requirement documented?
Who verifies the input?
What happens when the input is missing or defective?
Does the process stop, continue, return the work, or create a workaround?
Are inputs stored in one system or several?
Do employees have access to the input when they need it?
Does the input arrive at the correct time?
An input can exist and still be operationally unavailable.
For example, service-capacity information may exist in a scheduling system that the sales employee cannot access.
The business possesses the information.
The process does not have the information at the point of decision.
Process
The process portion of a SIPOC usually shows approximately five to seven high-level activities.
For the inquiry-follow-up example:
Receive the inquiry.
Capture the customer and request information.
Determine whether the inquiry is qualified.
Review service area and capacity.
Assign the inquiry.
Complete personalized follow-up.
Document the outcome and next step.
This level is intentionally broad.
It gives the team a common view before the detailed map is developed.
If the SIPOC process section contains dozens of steps, the team has probably moved prematurely into detailed flowcharting.
Outputs
Outputs are what the process produces.
An output may be:
A product
A completed service
A decision
A record
An approval
A scheduled appointment
An assigned task
A customer communication
An invoice
A completed handoff
A report
A rejected or closed transaction
For the inquiry-follow-up process, possible outputs include:
A qualified or unqualified inquiry
A complete CRM record
An assigned owner
A documented personalized response
A scheduled next step
A closed inquiry with a reason
An exception requiring management review
The output should not be defined only as the completion of an internal task.
“Email sent” may be an activity result.
The intended process output may be:
The prospective customer receives a clear, personalized response and understands the next step.
Those are not always equivalent.
An email can be sent to an invalid address.
A voicemail can be left at an incorrect number.
An automated message can be delivered without answering the customer’s question.
The internal activity may be complete while the customer outcome remains incomplete.
Output questions
Ask:
What must the process produce?
What does a complete output look like?
What quality, timing, and documentation requirements apply?
How is the output accepted or rejected?
Can the receiving process use it without clarification or rework?
Is the output defined from the organization’s perspective, the customer’s perspective, or both?
What evidence shows that the output was actually achieved?
Customers
Customers receive, use, or depend on the output.
Customers may be external or internal.
External customers may include:
Prospective customers
Existing customers
Patients
Clients
Residents
Vendors
Regulators
Contracting agencies
Community partners
Internal customers may include:
Sales employees
Schedulers
Service-delivery teams
Billing
Managers
Compliance staff
A downstream process
Another location or department
For the inquiry-follow-up process:
The prospective customer receives the response and next step.
The salesperson receives a complete and usable assignment.
Scheduling receives accurate customer and service information.
Management receives reliable status information.
The downstream service team receives a properly qualified and scheduled customer.
An internal customer is not less important merely because the transaction remains inside the organization.
If one process provides a defective output to the next process, rework, waiting, and customer failure can result later.
Customer questions
Ask:
Who receives or relies on the output?
What does that customer require?
How quickly is the output needed?
What information must accompany it?
What makes the output usable?
How does the customer signal acceptance, rejection, confusion, or abandonment?
Does the internal definition of completion match the customer’s actual need?
Customer Journey and SIPOC Answer Different Questions
The customer-journey map asks:
What is the customer trying to accomplish, and what does the customer experience across the journey?
The SIPOC asks:
What high-level operating system supplies and produces the scoped process output?
They should inform one another.
For example:
Customer-journey view
The customer:
Finds the company.
Reviews the offer.
Decides whether the business appears credible.
Submits an inquiry.
Waits without knowing what will happen next.
Receives an automated confirmation.
Waits again.
Receives a personalized response.
Learns that no appointment is available.
Leaves the process.
Internal SIPOC view
The organization:
Receives the inquiry.
Creates a CRM record.
Reviews qualification.
Checks service area.
Checks capacity.
Assigns the record.
Contacts the customer.
Documents the outcome.
The internal map may show all steps completed according to procedure.
The journey map may show that the customer waited too long, received unclear communication, and discovered capacity limitations only after significant effort.
The connected diagnostic question becomes:
How does the internal process create the customer’s actual experience?
Map the Current State, Not the Intended State
A current-state process map should show how work is performed now.
It should not show:
How the policy says work should happen
How management believes work happens
How the software was configured to work
How the process worked before a change
How the team wants the future process to operate
This distinction is fundamental.
Suppose the written procedure says:
Inquiries are automatically assigned to the next available employee.
The actual process may be:
The CRM automatically creates a record.
A notification enters a shared inbox.
The intake coordinator reviews the request.
Missing information is researched or requested.
Service area is checked.
Appointment capacity is checked.
The coordinator manually changes the status.
The coordinator selects an employee.
The CRM creates an assignment notification.
The coordinator also sends an email because employees do not trust the CRM notification.
The employee contacts the customer.
The employee documents the contact later.
The phrase “automatically assigned” describes the system’s intended design or one technical event.
It does not describe the full current process.
A current-state map should include the extra work, waiting, informal messages, duplicate entry, and workarounds.
Those conditions are not side notes.
They are the process the organization is actually operating.
CURRENT-STATE PRINCIPLE
Do not clean up the process while drawing it.
Document the work as performed before designing the work as preferred.
An inaccurate current-state map produces an unsupported future-state design.
Validate the Map With Evidence
A process map should not be built from one conference-room discussion.
Article 3 established that one source rarely proves root cause.
The same rule applies to mapping.
Management interviews may describe the intended process.
Employee interviews may describe local variations.
System data may show digital events.
Transaction records may show individual cases.
Observation may reveal actual handoffs and workarounds.
Time studies may show where work waits.
Customer behavior may reveal where the journey breaks.
The current-state map should be developed through triangulation.
Useful validation methods include:
Walking through recent transactions
Comparing successful and failed cases
Observing the process during normal and peak periods
Reviewing system audit trails
Reviewing emails, forms, and call records
Interviewing employees from several roles
Reviewing the draft map with upstream and downstream participants
Asking employees to identify exceptions
Comparing the map with customer complaints and abandonment points
Testing whether the mapped sequence explains the measured performance pattern
The map should also distinguish among:
Confirmed current-state steps
Observed variations
Suspected but unverified steps
Rare exceptions
Unknown conditions requiring further evidence
The goal is not to force every transaction into one artificial sequence.
The goal is to represent the normal pathways, meaningful variations, and exceptions that affect the performance gap.
Show Roles and Handoffs
A useful current-state map should make ownership visible.
One way to do this is to organize steps by role, team, or system.
Possible lanes include:
Customer
Website or telephone system
CRM
Intake
Sales
Scheduling
Operations
Management
When work moves from one lane to another, a handoff occurs.
Handoffs deserve attention because responsibility, information, and timing can become unclear during transitions.
Examples include:
Website to shared inbox
Shared inbox to CRM
Intake to sales
Sales to scheduling
Scheduling to service delivery
Service delivery to billing
Employee to manager
One location to another
One software system to another
A handoff can fail when:
No owner accepts the work.
The receiving party is not notified.
Information is incomplete.
Information is transformed incorrectly.
The receiving party cannot access the record.
The sending party assumes the receiving party understood.
Different systems use different identifiers.
The work is sent to several people without one accountable owner.
The handoff occurs verbally and is not documented.
The receiving process lacks capacity.
No confirmation of receipt exists.
The organization may say:
Sales owns follow-up.
The map may reveal a period during which the inquiry is no longer actively owned by intake but has not yet been accepted by sales.
That unowned interval is a system condition.
It is not visible in a standard job description.
Map Information Flow Separately From Work Flow
In service organizations, the work often is information.
An inquiry, approval, appointment, case, order, or referral moves through the organization primarily as:
A form
A record
An email
A message
A status
A notification
A document
A decision
A verbal instruction
The physical customer may not move.
The information representing the customer moves.
A process map should therefore examine both:
Work flow
What task or decision occurs?
Information flow
What information is created, transformed, transmitted, stored, or lost?
For each step, ask:
What information is required?
Where does it come from?
In what format?
Where is it stored?
Who can access it?
Who changes it?
Which system is considered authoritative?
Is the information pushed or pulled?
How does the next person know it is ready?
What happens when systems disagree?
Is information re-entered?
Are timestamps preserved?
Are exceptions documented?
Can management reconstruct the transaction later?
A company may have a workflow problem that is actually an information-flow problem.
Examples include:
Employees cannot see service availability.
Customer preferences are stored in free-text notes.
Status definitions differ across departments.
The CRM and scheduling system do not share updates.
The assignment email and CRM record contain different owners.
Employees maintain private spreadsheets because reports are unreliable.
Management reports measure task closure rather than customer completion.
Technology is part of the system.
It is not the entire system.
Identify Decision Points
A decision point is where the process divides based on a rule, judgment, condition, or available information.
Examples include:
Is the inquiry qualified?
Is the customer inside the service area?
Is the information complete?
Is an appointment available?
Does the request require management approval?
Is the customer new or existing?
Is the transaction routine or an exception?
Was contact successful?
Does the issue need escalation?
Is the work complete?
Decision points matter because different paths may produce different outcomes.
A company may report an overall 69% timely-follow-up rate.
The map may show that performance differs substantially by decision path:
Complete inquiries: 88%
Incomplete inquiries: 42%
In-area requests: 81%
Requests requiring service-area review: 37%
Services with available capacity: 86%
Services requiring manual capacity confirmation: 29%
The overall average conceals where the process fails.
Decision-point questions
Ask:
What decision is being made?
Who or what makes it?
What information is required?
What criteria apply?
Are the criteria documented?
Are the criteria interpreted consistently?
Can the decision be automated reliably?
What happens when information is missing?
How are exceptions handled?
Is the decision recorded?
Can management later determine why one path was selected?
Does one decision create a queue for the next step?
Unclear decision criteria create variation.
Two employees may receive identical cases and select different paths.
That difference may later appear as an employee-performance problem when the underlying system never defined the decision consistently.
Identify Rework Loops
Rework occurs when work must be repeated, corrected, returned, clarified, reopened, or re-entered because the initial output was incomplete or defective.
Examples include:
Contacting the customer for missing information
Re-entering data from email into the CRM
Correcting an appointment
Reassigning an inquiry
Reopening a closed task
Returning an invoice for correction
Asking for a second approval
Repeating a customer explanation
Recreating a missing document
Reconciling conflicting records
A rework loop may look like:
Receive inquiry → review information → find missing service details → contact customer → wait for response → update record → resume qualification
The map should show the return path.
If the loop is omitted, leadership sees only the successful forward path.
The process appears simpler and faster than it is.
Rework affects:
Cycle time
Labor hours
Capacity
Customer effort
Employee frustration
Error risk
Queue size
Management visibility
A process may contain only ten minutes of productive work but require several days because transactions repeatedly leave and re-enter the flow.
Failure demand
Some work exists only because the process failed to work correctly the first time.
Examples include:
“Did you receive my inquiry?”
“Why has no one called me?”
“I already provided that information.”
“My appointment is incorrect.”
“Why did I receive two different instructions?”
“Who is handling my request?”
These contacts consume capacity without advancing the original customer objective.
They are demand created by a previous failure.
Mapping these loops helps leadership see that customer-service volume may be partly produced by defects elsewhere.
Identify Queues
A queue is work waiting for attention, information, capacity, approval, or the next process step.
Queues may be visible:
An inbox
A CRM queue
A call-back list
A backlog report
A waiting room
A work-order list
An approval folder
Queues may also be hidden:
Draft emails
Personal notes
Unread messages
Tasks assigned without due dates
Records waiting in an intermediate status
Work held until a batch is processed
Cases waiting for an employee to remember them
Customers waiting without an active internal task
In service operations, a queue functions like inventory.
It represents customer demand or incomplete work that has entered the system but has not yet been converted into an output.
Queue questions
Ask:
Where does work wait?
Why does it wait?
How much work is waiting?
How old is the oldest item?
How is priority determined?
Is the queue first-in, first-out?
Are some items expedited?
Are items ever lost?
Who owns the queue?
How often is it reviewed?
What demand level causes the queue to grow?
What capacity is available to reduce it?
Does batching create unnecessary delay?
Can management distinguish active work from abandoned work?
A queue may reveal that the problem is not task speed.
It may be flow.
For example:
Qualification touch time: four minutes
Assignment touch time: one minute
First-response touch time: eight minutes
Total direct work: thirteen minutes
Total customer elapsed time: more than one business day
The customer is not waiting because thirteen minutes of work is inherently complex.
The customer is waiting because the transaction spends most of its time in queues.
FLOW PRINCIPLE
Do not ask only how long the work takes.
Ask how long the work waits, why it waits, and what rule determines when it moves again.
Identify Failure Points
A failure point is a location where the process can produce an incomplete, delayed, inaccurate, confusing, or uncontrolled result.
Failure points may involve:
Missing inputs
Incorrect data
Unclear ownership
Unavailable capacity
Weak decision rules
System integration
Manual transcription
Duplicate records
Communication gaps
Uncontrolled exceptions
Missing approvals
Delayed detection
Inadequate recovery
A useful diagnostic distinction is to examine three types of failure:
1. Occurrence failure
The process creates a defect or delay.
Example:
The inquiry is not assigned until the end-of-day batch.
2. Detection failure
The process does not recognize that the defect or delay occurred.
Example:
The management dashboard begins measuring response time only after assignment, so the pre-assignment delay is invisible.
3. Recovery failure
The process detects the problem but does not correct it reliably.
Example:
An overdue inquiry appears on a report, but no role is responsible for contacting the customer or reassigning the record.
A process can tolerate some occurrence risk when strong detection and recovery controls exist.
A small mistake becomes a serious customer failure when the system neither detects nor corrects it.
Failure-point questions
Ask:
What can go wrong at this step?
What condition makes the failure more likely?
How would anyone know it occurred?
How quickly would it be detected?
Who is responsible for recovery?
Can the failure pass downstream?
Can the customer detect it before the organization?
What record would show the failure?
Does the current measure capture it?
Does the failure create rework or another queue?
Does the process depend on memory or individual heroics?
The goal is not to label every possible failure as a root cause.
The goal is to identify where evidence should be examined and where controls may be weak.
Map Normal Work and Exception Work
Many process maps show only the routine path.
Operational problems often occur in exceptions.
Examples include:
Incomplete customer information
A request outside the normal service area
A high-priority customer
Unavailable capacity
A system outage
An employee absence
A duplicate inquiry
A customer using several channels
A request requiring management judgment
A failed payment
A complaint involving legal or regulatory risk
The standard path may perform well.
The exception process may be undefined.
Employees then create local workarounds.
Those workarounds may vary by:
Experience
Shift
Location
Manager
Customer
Software access
Time pressure
The map should identify:
What creates the exception
Who recognizes it
Who owns it
What decision criteria apply
Where it waits
How it returns to the standard process
How the result is documented
Whether management can measure exception volume and outcomes
A process can appear inconsistent because ordinary work and exception work have been combined into one measure.
Mapping the exception pathways helps separate the populations.
Do Not Treat Workarounds as Employee Defects
A workaround is an unofficial method employees use to complete work despite a system constraint.
Examples include:
Maintaining a private spreadsheet
Sending a second email because notifications are unreliable
Copying information into personal notes
Asking a manager verbally for approval
Closing and reopening tasks to manage system rules
Using text messages because the approved system is too slow
Holding inquiries until appointment availability is confirmed
Some workarounds create risk.
Some are evidence that the formal process does not support the work.
A diagnostic should ask:
What problem is the workaround solving?
What would happen if employees stopped using it?
Why does the formal process fail to meet the need?
How frequently is the workaround used?
Does it improve the customer outcome?
Does it create documentation, privacy, compliance, or control risk?
Could the useful function be incorporated into the formal process?
Eliminating a workaround without correcting the condition that created it can make performance worse.
The employee may be holding the system together through invisible labor.
That does not mean the workaround should remain.
It means leadership should understand its function before removing it.
Connect the Map to the Evidence Hierarchy
Article 3 established that evidence should support, weaken, or overturn a specific explanation.
The system map organizes where that evidence belongs.
For each mapped step, decision, queue, and handoff, the diagnostic can attach:
Direct system data
Receipt timestamp
Assignment timestamp
Status changes
User activity
Queue history
Notification history
Completion timestamp
Transaction records
Inquiry form
Email
Call log
CRM note
Scheduling record
Approval record
Customer response
Direct observation
Actual sequence
Workaround
Interruption
Informal handoff
Duplicate entry
Exception handling
Time-study evidence
Touch time
Wait time
Queue time
Rework time
Variation
Customer behavior
Response
Abandonment
Conversion
Cancellation
Escalation
Complaint
Employee interviews
Perceived barriers
Decision logic
Workaround purpose
Information limitations
Capacity constraints
Management interpretation
Intended process
Required standard
Strategic priority
Risk tolerance
Approved authority
The map and evidence should challenge one another.
If the map shows automatic assignment but timestamps reveal long assignment delays, the map is incomplete.
If employees report a large queue but the system shows none, the work may exist outside the system.
If management reports strong completion but customers repeatedly ask for status, the internal completion definition may not reflect the customer outcome.
Worked Example: Mapping the Qualified-Inquiry System
Article 1 defined the problem:
During the 90 days ending June 30, 2026, 290 of 420 qualified inquiries—69%—received documented personalized follow-up within one business day, compared with the company’s target of 95%, creating a gap of 26 percentage points and an operational shortfall of 109 timely follow-ups.
Article 2 developed competing explanations:
Employees ignore assigned inquiries.
Inquiries are assigned too late.
Follow-up occurs but is not documented.
Peak-period demand exceeds available capacity.
Employees delay contact when service capacity is unavailable.
Article 3 examined system data, records, observation, time studies, customer behavior, interviews, and management interpretation.
Article 4 now maps the system in which those conditions occur.
Step 1: Map the Connected Customer Journey
The broader customer journey is:
Customer recognizes a need.
Customer searches for a provider.
Customer reviews the website, reputation, services, and availability information.
Customer chooses a contact channel.
Customer submits an inquiry.
Customer receives an automated acknowledgment.
Customer waits for a personalized response.
Customer explains the need or provides additional information.
Customer learns whether the service is available.
Customer schedules or leaves the process.
Customer receives the service.
Customer completes payment and follow-up.
The diagnostic scope remains narrower:
Qualified inquiry received through first documented personalized follow-up.
The broader journey remains visible because upstream messaging and downstream availability may influence the scoped process.
Step 2: Build the SIPOC
Suppliers
Prospective customer
Marketing and website content
Website-form provider
Telephone provider
Referral partner
Management
Operations or scheduling
CRM provider
Employees supplying labor capacity
Inputs
Customer contact information
Requested service
Customer location
Preferred communication channel
Qualification criteria
Service-area rules
Appointment availability
Routing rules
Assignment authority
Response-time standard
CRM access
Employee availability
Documentation requirements
Process
Receive inquiry.
Capture information.
Qualify inquiry.
Check service area and capacity.
Assign responsible employee.
Complete personalized follow-up.
Document outcome and next step.
Outputs
Qualified or unqualified decision
Complete inquiry record
Assigned owner
Personalized customer response
Documented outcome
Scheduled next step or closed reason
Exception requiring management action
Customers
Prospective customer
Assigned employee
Scheduling
Service-delivery team
Management
Any downstream function relying on the record
The SIPOC reveals that customer follow-up depends on more than sales effort.
It depends on the completeness and timing of several inputs supplied by several parties.
Step 3: Map the Current State
The current-state process is reconstructed as follows:
The customer submits a website form, calls, or enters through a referral.
Website submissions generate a CRM record and shared-inbox email.
Telephone inquiries are written in a note or manually entered.
Referral inquiries may arrive directly to an employee or manager.
The intake coordinator reviews the shared inbox.
The coordinator determines whether the request contains enough information.
If information is missing, the coordinator searches other records or contacts the customer.
The inquiry waits for the customer’s response.
The coordinator checks service-area requirements.
The coordinator checks appointment or service capacity in a separate system.
If capacity is uncertain, the coordinator contacts scheduling or management.
The inquiry waits for confirmation.
The coordinator classifies the inquiry.
The coordinator manually assigns an employee in the CRM.
The CRM sends a notification.
The coordinator sends a separate email because employees do not consistently rely on the CRM notification.
The employee opens the assignment.
The employee checks whether a response has already occurred through another channel.
The employee contacts the customer.
The employee records the contact in the CRM immediately or later.
If the customer does not respond, the employee creates or informally remembers a follow-up task.
Management reviews an overdue report based on CRM documentation.
The current-state map is substantially different from:
The CRM automatically assigns the inquiry and the salesperson calls the customer.
The simplified description omits:
Multiple intake channels
Manual data entry
Incomplete inputs
Qualification decisions
Capacity review
Several queues
Restricted assignment authority
Duplicate notifications
External communication
Delayed documentation
Weak follow-up controls
Step 4: Identify Decision Points
The mapped decisions include:
Is this a valid inquiry?
Is it a duplicate?
Is the requested service offered?
Is the customer inside the service area?
Is enough information available to assign the inquiry?
Is appointment capacity available?
Which employee should receive the inquiry?
Has another employee already responded?
Was contact successful?
What next step is required?
Should the inquiry remain active, be closed, or be escalated?
Each decision requires information and criteria.
The map shows that several criteria are informal or stored in different places.
Step 5: Identify Queues
The inquiry may wait:
In the shared inbox
For intake review
For missing customer information
For service-area confirmation
For capacity confirmation
For coordinator assignment
For employee response
For customer response
For documentation
For management review
The time study from Article 3 showed that most elapsed time occurred before employee assignment.
The map explains where that waiting is created.
Step 6: Identify Information Handoffs
Information moves:
From the customer to the website form
From the website to the CRM
From the website to the shared inbox
From a telephone call to a handwritten or digital note
From intake to the CRM
From scheduling to intake
From intake to sales
From sales to the customer
From sales back to the CRM
From the CRM to management reporting
Each handoff presents an opportunity for:
Delay
Loss
Duplication
Misclassification
Conflicting ownership
Incomplete information
Different timestamps
Different status definitions
Step 7: Identify Rework Loops
Rework occurs when:
Intake contacts the customer for missing information.
Records are created twice.
The inquiry is reassigned.
Employees verify whether someone else already responded.
Sales requests updated capacity information.
Contact performed outside the CRM is entered later.
Management investigates records that appear overdue but were handled elsewhere.
Customers contact the business again because they do not know the status.
These loops consume capacity that could otherwise process new demand.
Step 8: Identify Failure Points
The map identifies several possible failure points:
Input failure
The inquiry lacks sufficient service or contact information.
Integration failure
The website, inbox, CRM, telephone records, and scheduling system do not provide one consistent record.
Decision failure
Qualification, routing, and capacity rules are not sufficiently standardized.
Queue failure
Inquiries wait for batch review or limited assignment authority.
Handoff failure
The assigned employee receives an email and CRM notification that may not communicate the same urgency or status.
Documentation failure
Customer contact occurs outside the system or is entered later.
Detection failure
Management measures time after assignment rather than total customer waiting time.
Recovery failure
Overdue records are reported, but no consistent escalation or reassignment process exists.
Step 9: Connect the Map to the Hypotheses
Hypothesis: Employees ignore assigned inquiries
The map and evidence show that employees usually open records soon after usable assignment.
This hypothesis may explain some individual cases.
It does not explain most of the total delay.
Hypothesis: Inquiries are assigned too late
The map shows multiple pre-assignment decisions and queues.
The timestamps and time study support this explanation.
Hypothesis: Follow-up occurs but is not documented
The map shows several communication channels and delayed entry.
This explains part of the measured gap but not all of it.
Hypothesis: Demand exceeds capacity
The map shows intake and assignment dependencies concentrated in limited roles.
Volume analysis is needed to determine when queues exceed available capacity.
Hypothesis: Service availability delays customer contact
The map shows that employees depend on capacity information before providing a useful response.
Customer-conversion evidence also varies based on appointment availability.
The most defensible explanation is therefore systemic:
The follow-up gap is produced by the interaction of incomplete inputs, manual qualification, batch processing, restricted assignment authority, fragmented capacity information, inconsistent documentation, and measurement that begins too late in the customer journey.
That explanation does not claim that every factor contributes equally.
It identifies the system conditions that should be prioritized and tested.
The Map Changes the Improvement Question
Before mapping, management’s improvement question may be:
How do we make sales employees respond faster?
After mapping, the question becomes:
How can the company reduce total elapsed time from qualified-inquiry receipt through useful personalized response while preserving qualification quality, managing service-capacity constraints, maintaining reliable documentation, and avoiding unacceptable employee workload or customer confusion?
The second question is more complex.
It is also more likely to produce an effective change.
Possible countermeasures may include:
Improve required inquiry fields.
Clarify qualification rules.
Separate simple from complex inquiries.
Replace batch review with continuous or more frequent routing.
Expand appropriate assignment authority.
Make service-capacity information available at the point of decision.
Establish one authoritative status record.
Standardize which notification requires action.
Integrate or simplify contact documentation.
Create visible queue ownership.
Establish an overdue escalation rule.
Measure customer waiting from receipt rather than assignment.
Pilot changes during defined periods and transaction types.
A full CRM replacement may or may not be needed.
The map prevents technology from being treated as the automatic answer.
Current State Comes Before Future State
Once the current system is understood, the organization can begin designing a future state.
The future-state map should show how the process is intended to operate after the proposed changes.
It may define:
Simplified inputs
Fewer handoffs
Clear decision criteria
Reduced queue time
Standard ownership
Improved information availability
Better exception handling
Integrated documentation
Earlier detection
Reliable escalation
Customer communication at each stage
Measures and controls
But the future state should not be built from preference alone.
It should respond to the causes supported by the evidence.
If delayed manual assignment is a supported cause, the future state should reduce or remove that delay.
If unavailable service information is a supported cause, the future state should make that information usable at the point of contact.
If documentation is incomplete, the future state should simplify and control documentation without creating excessive administrative work.
If the current map is wrong, the future map will solve the wrong system.
Do Not Confuse a Map With a Diagnosis
A map is a model of the system.
It is not the system itself.
It can be:
Incomplete
Outdated
Oversimplified
Biased
Based on the wrong population
Accurate only for one location or employee
Focused on the formal process rather than actual work
Missing exception pathways
Missing customer behavior
Missing time and volume
A process map can identify where to investigate.
It does not automatically establish root cause.
For example, a map may show three handoffs before customer follow-up.
The existence of three handoffs does not prove they cause the delay.
Evidence must show:
How long each handoff takes
How often information is incomplete
Whether failures concentrate at a handoff
Whether changing the handoff improves the result
Mapping and evidence therefore operate together.
The map gives the evidence a system context.
The evidence gives the map analytical credibility.
Common Mapping Errors
1. Mapping the policy instead of the process
The team documents what should happen rather than what occurs.
Result:
The map cannot explain actual performance.
2. Beginning with the proposed solution
The team maps only the steps affected by a desired software, staffing, or automation change.
Result:
The scope is biased toward confirming the solution.
3. Stopping at departmental boundaries
Each team maps its own work but no one maps the handoffs.
Result:
The most important ownership and information failures remain invisible.
4. Ignoring the customer journey
The internal process is optimized without examining what the customer must do, understand, repeat, or wait for.
Result:
Internal efficiency improves while the customer experience deteriorates.
5. Omitting queues and waiting
Only active work is shown.
Result:
A process with minutes of touch time appears fast even when the customer waits several days.
6. Omitting rework
The map shows the normal forward path but not returns, corrections, clarifications, or reopened work.
Result:
The process appears simpler and consumes less capacity than it actually does.
7. Treating all transactions as identical
Routine work, complex work, exceptions, and invalid transactions are combined.
Result:
Variation and failure concentration remain hidden.
8. Using job titles instead of actions
The map states “sales,” “operations,” or “management” without showing what each role does.
Result:
Ownership and decision criteria remain unclear.
9. Mapping only the software
Screens, fields, and notifications are documented while telephone calls, emails, verbal decisions, customer actions, and workarounds are excluded.
Result:
The technical workflow is confused with the operating system.
10. Creating excessive detail before establishing the boundary
The team documents every click and keystroke without knowing which process or decision matters.
Result:
The map becomes difficult to use and expensive to maintain.
11. Treating the map as permanent
The organization creates a diagram once and assumes the process will remain unchanged.
Result:
The map becomes a historical artifact rather than a management tool.
12. Redesigning during current-state mapping
Participants replace inconvenient steps while the map is being built.
Result:
The distinction between actual and proposed work disappears.
Use the Map to Determine What to Measure
A useful map should expose where measurement is needed.
Possible measures include:
Customer measures
Total elapsed response time
Customer effort
Abandonment
Conversion
Complaints
Repeated contacts
Understanding of the next step
Process measures
Intake completion rate
Qualification time
Assignment time
First-response time
Documentation completeness
Reassignment frequency
Rework rate
Queue age
Exception volume
Outcome measures
Timely-follow-up rate
Scheduled-appointment rate
Conversion
Customer retention
Contribution margin
Owner intervention
Balancing measures
Employee workload
Error rate
Incorrect qualification
Customer complaints
Service overbooking
Overtime
Documentation burden
Downstream rework
The original outcome measure remains important.
The map identifies the upstream process measures that may explain and control that outcome.
Mapping Should Produce Management Decisions
A completed map should not end with:
The process is complicated.
It should help leadership decide:
Which process segment requires deeper analysis
Which evidence is missing
Which hypothesis is strongest
Which handoff requires ownership
Which queue requires capacity or flow changes
Which input requires a clearer standard
Which decision requires documented criteria
Which rework loop should be reduced
Which failure needs detection or recovery controls
Which customer touchpoint requires better communication
Which countermeasure should be tested first
Which metrics will determine whether the change works
The map should narrow the decision.
It should not merely expand the list of problems.
The Eight-Question Management Test
Before approving a major process, staffing, software, AI, training, or policy change, leadership should be able to answer these questions in writing:
What end-to-end customer or organizational journey contains the defined performance gap?
What are the explicit start and end boundaries of the process being investigated, and which adjacent processes remain visible but outside the detailed scope?
Who supplies the critical inputs, what makes those inputs complete and usable, what outputs must the process produce, and who receives them?
Does the current-state map reflect how work is actually performed across roles, channels, systems, normal cases, and meaningful exceptions?
Where are the key decision points, what criteria govern them, and is the required information available at the time the decision must be made?
Where does work wait, change ownership, move between systems, require clarification, or return through a rework loop?
Which confirmed or suspected failure points could create, amplify, transfer, or conceal the measured performance gap, and what evidence supports each one?
What proposed change follows from the mapped and evidenced causes, and how will the organization determine whether the entire customer journey improves rather than merely shifting the problem downstream?
If leadership cannot answer these questions, it may be preparing to change a process it does not yet understand.
Conclusion: Change the System That Produces the Result
Customers experience one connected journey.
Organizations operate a network of processes, people, information, technology, suppliers, decisions, queues, handoffs, and controls.
A failure visible at the end of the journey may have been created much earlier.
A customer who does not receive timely follow-up may appear to be the responsibility of one salesperson.
The actual result may depend on:
What the customer submitted
What the website captured
What intake understood
What capacity information was available
How assignment occurred
Which system was authoritative
Whether an employee recognized ownership
How contact was documented
Whether management could detect the delay
Article 1 defined the measurable gap.
Article 2 developed competing explanations.
Article 3 established the evidence required to evaluate those explanations.
Article 4 places the gap, hypotheses, and evidence inside the operating system that produces the customer result.
The diagnostic chain is now:
Defined gap → competing hypotheses → evidence and triangulation → system map → supported failure points → tested countermeasures → measured results → operational control
A SIPOC establishes the high-level suppliers, inputs, process, outputs, and customers.
A customer-journey map shows what the customer is trying to accomplish and where the experience breaks.
A current-state process map shows how work actually moves.
Decision points show where different paths are selected.
Queues show where work waits.
Information handoffs show where context can be lost.
Rework loops show where capacity is consumed correcting previous failures.
Failure points show where defects can occur, remain undetected, or fail to recover.
Together, these views help leadership see the business as a connected operating system rather than a collection of isolated departments.
The objective is not to create a perfect diagram.
It is to understand enough of the real system to change the right condition, at the right point, for the right reason.
OPERATING RULE
No major process, staffing, software, AI, training, or policy change should be approved until leadership has mapped the current customer-to-delivery system, defined its boundaries, identified its suppliers, inputs, outputs, and customers, and examined the decisions, queues, information handoffs, rework loops, and failure points that could produce the measured performance gap.
When Structured Diagnosis Becomes Appropriate
When an established organization has a recurring operational problem with a meaningful customer, financial, employee, capacity, service-delivery, or management impact—and the process crosses several people, departments, channels, systems, decisions, or handoffs—Angulo & Morsa’s Operations Diagnostic examines the connected customer journey, current-state workflow, system boundaries, evidence, constraints, queues, rework, information flow, and potential failure points before recommendations are made.
[Learn about the Angulo & Morsa Operations Diagnostic]
Related Reading
[Read Article 1: How to Write an Operational Problem Statement]
[Read Article 2: Stop Guessing at Root Causes]
[Read Article 3: What Counts as Evidence in an Operations Diagnostic?]
[Return to The Legacy Perspective Knowledge Library]
Educational and Professional Disclaimer
This article is provided for general educational and informational purposes.
It does not constitute legal, tax, accounting, financial, investment, human-resources, cybersecurity, regulatory, engineering, statistical, audit, investigation, quality-certification, or other professional advice.
Examples are illustrative and may not apply to a specific organization.
Process and system maps depend on scope, data quality, definitions, observation, employee and customer input, technology configuration, operating conditions, privacy requirements, and organizational context. Mapping a process does not independently establish causation, compliance, safety, financial impact, or the effectiveness of a proposed change.
Certain matters may require legal counsel, licensed professionals, regulatory specialists, auditors, cybersecurity professionals, engineers, statisticians, human-resources professionals, or other qualified experts.
Use of this article does not create a consultant-client or other professional relationship with Angulo & Morsa Legacy Consulting LLC.
References
American Society for Quality. (n.d.). SIPOC+CM diagram.
American Society for Quality. (n.d.). Quality glossary of terms, acronyms, and definitions.
GOV.UK Service Manual. (2017). Creating an experience map.
GOV.UK Service Manual. (2019). Map and understand a user’s whole problem.
GOV.UK Service Manual. (2019). Getting the scope of your transaction right.
Institute for Healthcare Improvement. (n.d.). Flowchart.
Institute for Healthcare Improvement. (n.d.). Model for Improvement: Selecting changes.
International Organization for Standardization. (2015). The process approach in ISO 9001:2015.
Lean Enterprise Institute. (n.d.). Value-stream mapping.
NIST Organization of Scientific Area Committees for Forensic Science. (2022). OSAC’s Seized Drugs Subcommittee develops process map.
© 2026 Angulo & Morsa Legacy Consulting LLC. All rights reserved.