Identifying Actors: Customers, Frontline Staff, and Back Office

Every journey begins with a person — and every process is shaped by those who touch it.

When I work with teams who say, “We don’t know who’s doing what,” I start by asking: “Who’s actually responsible for the next step?”

That question cuts through the fog. In customer journey BPMN, identifying actors isn’t just about labeling lanes — it’s about clarifying ownership, accountability, and the human element behind every step.

This chapter shows you how to distinguish between customers, frontline staff, and back-office teams — not just in theory, but in the way you draw them in BPMN.

You’ll learn how to map roles clearly, avoid common confusion between internal and external actors, and design diagrams where the customer stays visible — even in complex operations.

By the end, you’ll be able to translate real-world roles into BPMN pools and lanes with confidence, using patterns that reflect how people actually work — and how customers experience it.

Why Actors Matter in Customer Journey Modeling

Too many BPMN models start with a blank canvas and an abstract “process.” But a customer journey isn’t abstract. It’s lived — and felt — by real people.

When you fail to define actors, you lose accountability. You end up with a diagram where “someone” handles the next step — and no one takes ownership.

Clarity around roles isn’t just about structure. It’s about empathy. It means knowing: who’s on the frontlines? Who’s behind the scenes? And who’s actually experiencing the journey?

Here’s a truth I’ve learned after 20 years: the most broken processes aren’t the ones with poor logic — they’re the ones where roles are ambiguous or invisible.

With that in mind, let’s look at the three core types of actors in customer journey BPMN.

1. The Customer: The Heart of the Journey

The customer is not a role — it’s the reason the journey exists.

They’re the only actor who must always be visible in the model, even if they’re not directly interacting at every step.

Always represent the customer as a separate pool or lane. This is non-negotiable.

If the customer isn’t in the diagram, you’ve already lost the experience perspective — and that’s why so many process improvements fail.

2. Frontline Staff: The Face of Service

These are the people who interact directly with customers — call center agents, retail associates, support reps, sales consultants.

They’re often the first point of contact when a customer reaches out. Their actions — whether it’s resolving a query or escalating a complaint — shape the customer’s perception of quality.

In BPMN, frontline staff should be in their own lane, within the same pool as the customer or in a separate pool for internal operations.

They act as intermediaries — carrying customer requests forward, relaying feedback, and managing expectations.

Remember: frontline staff are not just executors. They are decision-makers in real time — and their role should reflect that.

3. Back Office Teams: The Hidden Engine

Behind the scenes, back office teams handle what frontline staff can’t — account setup, policy checks, fraud validation, billing, data entry.

These roles are often invisible to customers, but they’re critical to whether a journey succeeds.

In BPMN, back office teams should be in a separate lane — typically under a “Back Office” pool or within a subprocess.

They don’t need to be labeled “admin” or “support.” Be specific: “Credit Risk Analyst,” “Policy Validation Team,” “Invoice Processing Unit.”

Why? Because ambiguity breeds delay. If a step says “backend checks,” who’s doing it? What are the rules?

Clear role definition ensures that handoffs are precise and expectations are shared.

Mapping Roles to BPMN Pools and Lanes

Now that we’ve defined the roles, let’s turn to the model.

Use pools to represent major organizational entities. The customer is always in a pool of their own.

Internal teams — frontline and back office — belong in pools or lanes within a larger process pool.

Here’s a simple but powerful pattern:

• Pool 1: Customer — always visible, always primary.
• Pool 2: Frontline Operations — includes call center, retail, or service agent roles.
• Pool 3: Back Office — includes systems, validation, processing, and data teams.

Each pool can have multiple lanes — for example, “Call Center Agent,” “Field Technician,” or “Document Review Team.”

Use this structure to show not just what happens, but who is responsible for it.

Let’s take a real example: a customer service request via phone.

The customer initiates the journey by calling. That request lands in the Frontline Operations pool. The agent logs the issue and decides: is it simple? Can it be resolved now?

If yes — done. If no — the request moves to the Back Office pool, where a specialist reviews the case. Once approved, the solution flows back to the frontline, who communicates it to the customer.

This structure makes responsibilities clear — and makes it easy to spot where delays happen.

Patterns for Distinguishing Internal vs. External Actors

Not all actors are internal. Some are partners, vendors, or third parties.

To maintain clarity, use consistent visual cues:

• Customer: Always outside the organization — typically on the left.
• Frontline Staff: Inside the organization — in the first internal pool.
• Back Office: Deeper into the organization — often in a separate pool.
• External Partners: Represented with a dashed border or a different color — e.g., “Third-Party Payment Processor.”

Why does this matter? Because when a customer waits for a payment to be approved by an external partner, that wait isn’t on your team’s clock — but it’s on the customer’s.

Make that visible.

Defining Roles for Customer Journeys: A Step-by-Step Guide

Here’s how I help teams define roles with precision:

1. Start with the journey narrative. What does the customer do? What triggers each step?
2. Ask: Who does this step? Don’t assume. Interview the people who do it.
3. Group roles by function: frontline, back office, partners, or customer.
4. Label lanes explicitly: Use job titles — not “Team A” or “Department B.”
5. Map handoffs clearly: Use message flows to show communication between pools.
6. Validate with stakeholders: Ensure no one says, “That’s not my job.”

This process isn’t about perfect labeling — it’s about removing ambiguity.

When you can answer, “Who will do this next?” with confidence, you’ve made progress.

Common Pitfalls and How to Avoid Them

Even experienced modelers fall into traps. Here are the most common:

• Blurring frontline and back office: Don’t mix “agent” and “manager” in the same lane. Keep them separate.
• Overloading lanes: Don’t list every job in one lane. A “Support” lane with 10 roles is unreadable. Split into sub-lanes or use a subprocess.
• Ignoring the customer’s role in handoffs: If a customer must confirm something — show it. Even “waiting for customer response” is a state.
• Using vague labels: “Someone,” “the system,” or “the team” are not roles. Be specific.

Remember: a clear lane is not a busy lane.

Frontline vs Back Office in Processes: A Practical Comparison

Understanding the difference between frontline and back office roles is key to modeling experience accurately.

Here’s how they differ — and why it matters in BPMN:

Aspect	Frontline Staff	Back Office Teams
Interaction with Customer	Direct: phone, chat, in-person	Indirect: via system or request
Decision-making Speed	Real-time: resolves issues on the spot	Delayed: may take hours or days
Visibility	High: customer sees them	Low: customer rarely knows
Role in BPMN	Executes steps directly; often in a separate lane	Handles complex, non-urgent work; often in a subprocess

Use this table to guide your modeling decisions.

When you see a step like “verify identity,” ask: is this handled by a frontline agent who sees the customer, or a back office team who reviews documents?

That distinction changes how you model it — and how the customer experiences it.

Case Study: Resolving a Delayed Refund

Let’s say a customer reports a wrong charge on their account.

Step 1: Frontline agent receives the complaint. They verify the transaction and determine it’s a billing error.

Step 2: The agent submits a refund request to the back office.

Step 3: The back office team validates the claim, checks policy, and approves or denies.

Step 4: If approved, the refund is processed and notified back to the frontline agent.

Step 5: The agent contacts the customer with the update.

Without clear roles, this model would show “someone approves the refund.”

With clear roles? You see the delay — not in the process, but in the handoff.

The back office team is swamped. The customer waits. But now, the bottleneck is visible — and measurable.

That’s what happens when you model customers and staff in BPMN with intention.

Frequently Asked Questions

Why can’t I just use “Customer” and “Team” as lanes?

Because “Team” is not a role — it’s a label. You need to know who’s actually performing the work. If you don’t, handoffs become black boxes, and accountability vanishes.

Should the customer be in their own pool or in a lane?

Always in their own pool. It preserves their journey as a first-class participant. If you put them in a lane within a business pool, you risk making them part of the process — not the driver.

How do I represent a self-service journey with no frontline staff?

Still include the customer as a pool. Represent the self-service system as a lane within the customer pool or a separate “Digital Channel” pool. Use message flows to show interactions — like “user submits form” → “system validates” → “response sent”.

Can one person hold multiple roles in a BPMN model?

Yes — but only if it’s accurate. A call center agent who both receives the call and submits a refund request can be in two lanes. But never label a lane “Agent” and assume it covers everything. Break it down by responsibility.

What if the back office is outsourced?

Treat them as an external partner. Use a separate pool with a dashed border. Label clearly: “Third-Party Fraud Reviewer.” This keeps the flow visible and avoids confusion.

How do I handle roles that change during a journey?

Use a subprocess or a message flow to show the transition. For example, “Customer submits form → Frontline reviews → Back Office validates.” The role changes — but the ownership stays traceable.