Modeling Requests, Responses, and Waiting Time

Every customer interaction carries an unspoken expectation: responsiveness. When a customer submits a request, they’re not just waiting for a reply—they’re experiencing the rhythm of your service. The real challenge isn’t just capturing what happens, but how long it takes and how the customer perceives that delay. In BPMN, we can model this rhythm with precision—using send and receive tasks, message flows, and timers—not just for technical accuracy, but to reflect the emotional toll of waiting.

My rule of thumb: if the customer can’t see or feel the flow, the process model fails. Waiting time isn’t a gap—it’s a touchpoint. It shapes trust, frustration, and brand perception. By modeling requests and waiting time in BPMN, we transform abstract delays into observable, measurable, and improvable steps. This chapter will show you how to do it with clarity, empathy, and precision—so that every wait becomes a chance to reinforce reliability.

Understanding Customer Expectations in Waiting Time

Customers don’t experience delays in isolation. They perceive time through the lens of context: a 5-minute wait for a flight status update feels acceptable, but 5 minutes for a support ticket response feels excessive.

That’s why modeling waiting time in processes isn’t just about placing a timer—it’s about aligning timing with customer expectations. When modeling a request, ask: “What does the customer expect to happen next?” If they expect an acknowledgment, the model must reflect that.

Use this checklist when designing for waiting time:

• Identify the moment the customer submits a request.
• Define the expected acknowledgment or response time based on service level agreements (SLAs).
• Map whether the wait is internal (processing), external (third-party), or both.
• Consider whether the customer is actively waiting or can be temporarily disengaged.

These aren’t just operational questions—they’re empathy checkpoints.

Modeling Requests and Responses with Send and Receive Tasks

Every customer request begins with a message. In BPMN, that’s where send tasks and receive tasks come in. They’re not just technical constructs—they represent the customer’s voice entering your system.

Use a send task to model the customer’s submission. For example: “Customer submits support ticket via web form.” This is the first step in a service request flow. Then, a receive task captures the system’s acknowledgment or response.

Here’s how to structure it:

1. Start with a start event representing the customer’s action.
2. Add a send task to send the request to the backend system.
3. Link it to a receive task that waits for the system’s reply.
4. Use a message flow to show the communication between the customer and system.

Example:

Customer → (Send Task) → Support System → (Receive Task) → Customer

Notice that the message flow is bidirectional. The customer sends, the system receives and replies—this symmetry reflects the two-way nature of customer experience.

This structure makes it clear who initiates and who responds. It also makes it easy to add follow-ups, escalations, or timeouts later.

When the Customer Waits: Using Timer Events for Delays

Waiting is not passive—it’s a state. In BPMN, we use timer events to capture intentional delays. They can be scheduled, periodic, or time-bound.

For example, if your SLA says “respond within 24 hours,” use a timer event to model that expectation. Place a timer intermediate event after the send task, set to 24 hours. If the system doesn’t respond within that time, the event triggers an escalation.

This isn’t about making the model complex—it’s about making the expectations visible. Stakeholders, from CX leaders to IT teams, can see exactly where delays occur and whether they’re acceptable.

Here’s a practical example:

• Start: Customer submits a request.
• Send Task: Request sent to backend queue.
• Timer Intermediate Event: “Wait 24 hours” (SLA Timer).
• If no response, trigger escalation path.

This approach directly links process design to customer experience. If 24 hours is too long, the model forces a conversation: “Can we reduce this? Can we automate the acknowledgment?”

Modeling Queued Requests and Perceived Responsiveness

Not all waiting happens after the request is submitted. Sometimes, the customer waits because the system is queued. This is especially common in high-volume support, onboarding, or order fulfillment scenarios.

Model this with a task followed by a timer event:

1. Send Task: Submit request.
2. Task: “Wait in queue for processing” (e.g., “Pending staff review”).
3. Timer Event: “Wait up to 48 hours”.
4. If timeout, trigger escalation or auto-notify.

Use a parallel gateway to split the flow: one path for “processed in time,” another for “timeout.” This avoids clutter while keeping the customer’s perspective clear.

Pro tip: Don’t hide the queue. Name it clearly: “Support Queue – Tier 1.” This is not just a system state—it’s a customer touchpoint. If the queue is long, the delay becomes a pain point.

When modeling, ask: “What would the customer see during this wait?” If the system doesn’t send an acknowledgment or update, the model should reflect that gap.

Best Practices: Balancing Accuracy and Clarity

Modeling waiting time in processes is powerful—but it can become cluttered. Here are four grounding principles I’ve learned from working across banking, healthcare, and SaaS:

1. Start with the customer’s timeline. Don’t build a model that starts with “system receives request.” Start with “customer submits.” This keeps the focus on experience.
2. Use timers only when expectations exist. Not every wait needs a timer. Only apply them when there’s a defined SLA or business promise.
3. Keep acknowledgments visible. A simple “We’ve received your request” message—sent automatically—can reduce anxiety more than a fast resolution.
4. Group wait states under a single label. If multiple tasks involve waiting, group them under “Waiting for response” to avoid repetition.

Remember: The goal is not to model every millisecond, but to reflect the customer’s reality.

Common Pitfalls and How to Avoid Them

Even experienced modelers get tripped up. Here are three frequent mistakes—and how to fix them:

Pitfall	Why It’s a Problem	Solution
Using timer events on every task	Clutters the model and distracts from actual delays.	Only apply timers when expectations exist (e.g., SLAs).
Ignoring acknowledgment messages	Customers feel ignored when no response is visible.	Always include an acknowledgment step—use a send task to send a confirmation.
Overloading the model with multiple timers	Confuses stakeholders and obscures key delays.	Use a single high-level timer for SLA, and break down only if needed.

These aren’t just technical fixes—they’re empathy checks.

Frequently Asked Questions

How do I model waiting time in processes with BPMN?

Use a combination of send and receive tasks to represent the request and response. Insert a timer event (e.g., “Wait 24 hours”) after the send task to model the expected response time. If the system doesn’t respond within that time, trigger an escalation. This directly reflects service level expectations.

What’s the best way to represent send and receive tasks for customer requests?

Use send tasks to model the customer’s action (e.g., “Submit support ticket”). Use receive tasks to represent system acknowledgment or response. Connect them with message flows to show the direction of communication. Keep the flow clear: customer → system → customer.

Can BPMN timers be used to model customer experience delays?

Absolutely. BPMN timers are ideal for modeling SLAs, queue durations, and acknowledgment windows. They make customer expectations visible and measurable. Use them to highlight where delays exceed expectations and to trigger follow-ups.

Should I model every wait in the process flow?

No. Only model waits that impact the customer’s perception. Focus on times that are expected (e.g., SLA) or could cause frustration (e.g., long queues). Group similar waits under a single label to avoid clutter.

How do I make waiting time visible to stakeholders?

Use clear labels on timer events (e.g., “Wait up to 24 hours”), and annotate them with the business reason (e.g., “SLA for Tier 1 support”). Add notes to explain what happens during the wait. Keep the model aligned with the customer journey stage.

What if the wait time is unpredictable?

Use a timer event with a maximum limit (e.g., “Wait up to 72 hours”) and trigger a follow-up or escalation if the wait exceeds that. This models the uncertainty while still setting a clear expectation. Add a note: “If no response within 72 hours, notify customer.”