Modeling the Customer as a First-Class Participant

Estimated reading: 8 minutes 7 views

Too many process models treat the customer as invisible—just a name in a message or a field in a form. But when you don’t make the customer explicit in your BPMN diagrams, you risk building systems that optimize internal efficiency while undermining experience. The real question isn’t whether the customer belongs in the model—it’s how to represent them so clearly that every stakeholder sees the journey through their eyes.

As someone who’s spent two decades translating customer journeys into BPMN, I’ve seen teams struggle with the same decision: should the customer be their own pool, a lane within a larger pool, or both? This chapter walks through the three main modeling patterns, their trade-offs, and when to use each—based on real projects, not theory alone.

By the end, you’ll know how to make the customer a visible, respected participant in every process, not just a footnote. You’ll learn how modeling the customer as a first-class citizen in process models changes the conversation—from “How fast can we process this?” to “How does this feel for the customer?”

The Three Ways to Represent the Customer in BPMN

1. Customer as a Separate Pool (Customer Pool in BPMN)

This is the most natural approach when the customer’s journey isn’t just a path through your system—it’s a distinct journey with its own logic, timing, and decision points.

Placing the customer in their own pool creates a strong visual separation, signaling that their actions and expectations are foundational. This works especially well when the customer initiates the process, such as in onboarding, purchases, or support requests.

For example: a bank onboarding process where the customer signs up, uploads documents, and verifies identity—each step is a sequence of actions initiated by the customer, with your bank’s systems responding. In this case, the customer pool clearly shows responsibility and ownership.

Pros:

Clear separation of customer and business responsibilities
Supports multi-channel journeys (e.g., web, mobile, call center) where the customer’s perspective remains consistent
Aligns with BPMN’s original intent: pools represent independent participants

Cons:

Can lead to larger diagrams with more swimlanes
May feel redundant if the customer only acts once or interacts minimally
Harder to reuse in other contexts without adjustment

2. Customer as a Lane within a Business Pool (Customer Lane in BPMN)

When the customer’s actions are tightly integrated with internal processes—like a customer signing a form during a live call with a service agent—you can represent them as a lane inside the business’s pool.

This approach keeps the model compact and avoids over-fragmentation. It’s useful when the customer is a role player rather than a separate entity, such as during a live interaction, a support call, or a co-creation session.

For example: a customer service agent guiding a customer through a billing dispute. The customer is not a standalone actor—they’re part of the interaction, and their input drives the next step.

Pros:

Keeps the diagram focused and less cluttered
Simplifies modeling for short, transaction-based interactions
Reinforces that the customer is part of the process, not separate

Cons:

Can obscure the customer’s perspective if not labeled clearly
Limits reuse across different types of journeys
May make it harder to track customer experience separately from internal performance

3. Both: Customer Pool and Customer Lane in Different Diagrams

This is the most powerful, yet often overlooked, pattern. Use a customer pool in high-level journey diagrams to emphasize the customer’s full journey. Then, in detailed operational models, use a customer lane within a business pool to show step-by-step execution.

For example: a high-level onboarding journey shows the customer as a separate pool—sign-up, document upload, verification, account activation. Then, in the detailed process model for document verification, the customer is a lane in the bank’s pool, showing how their actions interface with document validation, fraud checks, and compliance.

This dual approach respects both the strategic view and operational detail. It’s a hybrid that balances clarity with precision.

Pros:

Supports both customer-centric and operational perspectives
Enables reuse across different levels of abstraction
Aligns with enterprise architecture principles

Cons:

Requires consistent naming and labeling to avoid confusion
Increases the number of diagrams to manage
Can create inconsistency if not governed

When to Use Each Pattern: A Decision Tree

Choosing between a customer pool in BPMN, customer lane in BPMN, or both depends on context. Ask these questions:

Is the customer the primary initiator of the process? → Use a customer pool.
Is the journey long or multi-channel, involving multiple touchpoints? → Use a customer pool.
Is the interaction short, real-time, and part of a larger workflow? → Consider a customer lane.
Are you modeling for CX stakeholders and need to emphasize experience? → Use a customer pool.
Are you modeling for developers or automation, focusing on internal logic? → Use a customer lane.

In practice, I’ve found that most teams benefit from using both—high-level models with a customer pool, detailed ones with a customer lane.

Real-World Example: The Onboarding Journey

Let’s say a fintech company is modeling their account onboarding journey. The customer signs up via web, uploads ID, and verifies identity via video call.

In the high-level BPMN, the customer is a separate pool. The first task is “User signs up.” The bank’s pool responds with “Send welcome email,” then “Request document upload.” The customer uploads documents, which triggers the next step.

In the detailed process model, the customer is a lane in the “Onboarding Team” pool. The “Document Verification” task now includes the customer’s input: “Customer uploads ID,” “Customer confirms identity in video call,” and “Customer signs consent form.”

This dual view makes it clear: the customer is both the driver of the journey and a key contributor to execution.

Why It Matters: The Shift in Mental Model

When you model the customer as a first-class citizen in process models, you shift from a “process-first” mindset to a “customer-first” one.

Instead of asking, “How do we automate this step?” you ask, “How does this step feel for the customer?”

When a customer lane in BPMN is clearly labeled and visible, teams stop thinking in terms of “tasks” and start thinking in terms of “moments.” A “wait for verification” step becomes “customer waits while identity is confirmed”—and now, you can measure that wait time, ask about frustration, and improve it.

That’s the power of making the customer explicit. It changes how teams design, measure, and improve—because now, every process step has an emotional and experiential dimension.

Best Practices for Modeling the Customer in BPMN

Use consistent labeling: Always call the customer “Customer” or “End User,” not “User” or “Client” inconsistently.
Color-code for visibility: Use a distinct color for the customer pool or lane to make them stand out.
Include customer triggers: Show customer actions as events—e.g., “Customer submits form,” “Customer clicks confirm.”
Annotate experience cues: Add notes like “Customer feels anxious here” or “This step takes 3–5 minutes” to capture CX insights.
Link to journey maps: Reference the customer journey map in the BPMN model’s legend or notes.

These are not just design tips—they’re signals that the customer is not an afterthought.

Frequently Asked Questions

What’s the difference between a customer pool in BPMN and a customer lane in BPMN?

A customer pool treats the customer as a separate, independent participant in the process—ideal for journeys involving multiple touchpoints or actions. A customer lane integrates the customer into an existing business pool—best for real-time, co-dependent interactions like service calls or live form completion.

Can I use both customer pool and customer lane in the same model?

Not in the same diagram. But you can use a customer pool in a high-level journey model and a customer lane in a detailed process model. This is a common and powerful pattern for balancing visibility and operational detail.

Why should I make the customer a first-class citizen in process models?

Because if the customer isn’t represented, their experience becomes invisible. You’ll optimize for internal speed, not customer satisfaction. Making the customer explicit forces you to think about wait times, handoffs, and emotional states—leading to better design, faster resolution, and stronger loyalty.

Does modeling the customer as a BPMN participant add complexity?

It adds clarity, not complexity. Yes, you’ll have more swimlanes, but the trade-off is worth it: you’ll reduce misunderstandings between CX, IT, and operations teams. Clear ownership, better handoffs, and shared understanding are the real benefits.

How do I handle multiple customers in a single process?

Use a separate pool for each customer type if their journeys diverge significantly—e.g., a retail customer vs. a business customer. If the path is similar, use one customer lane with conditional logic or annotations to distinguish between types.

Can I model self-service and assisted journeys together?

Yes. Use a customer pool in the high-level model to show both paths. In detailed models, branch using gateways: one path for “Self-Service (web),” another for “Assisted (call center).” The customer lane can show the shared steps, like “Initiate request” or “Confirm identity.”