A return looks simple on a process chart: request, approve, receive, refund. Ask a support agent, a warehouse operator, and a developer what “approved” means, however, and you may hear three different answers. One means the customer can send the item back. Another means the item passed inspection. The third means a payment instruction was accepted.
An EventStorming workshop helps people uncover those differences by building a shared story of meaningful business events. This guide uses a hypothetical retailer's returns process to show how a team can move from conflicting descriptions to a model worth discussing with the people who do the work.
Choose a process modelling scope
Alberto Brandolini's EventStorming Process Modelling format supports exploring an existing process or designing a new one. It is a useful starting point when the question concerns a particular business flow. A broader Big Picture session explores a larger domain; a Software Design session goes further into implementation concerns. Do not promise to accomplish all three in one short meeting.
For the retailer, write the scope as “a customer returns one purchased item and receives a refund or an explanation of rejection.” Keep exchanges, supplier reimbursements, and fraud investigations outside the first pass. They can be marked where they touch the process without taking over the board.
Invite people who can explain different parts of that story: customer support, returns operations, payments, and engineering. Someone with authority over the returns policy is especially useful. A room full of developers may accurately describe the software while missing what employees do around it.
Start with business events people recognize
Give participants space to add events before the group tries to agree on a sequence. A domain event describes something relevant that has happened, such as “Return requested” or “Item inspected.” Use past-tense labels on orange notes. “Inspect item” is an intended action; “Item inspected” records the resulting fact. The DDD Crew glossary explains this notation and the additional concepts used in process modelling.
Ask people for examples from their part of the work. The warehouse colleague might add “Parcel received,” while support adds “Return label sent.” Both may be missing from the developer's first description. Leave duplicates in place until you know whether they describe the same event.
Be careful with labels taken from screens or database fields. “Status updated” hides the business change. Ask what became true for the customer or the operator. Likewise, “Refund completed” needs a definition: was the instruction submitted, accepted by the payment provider, or confirmed as settled? Separate those events if people make different decisions after each one.
Tell the return story together
Arrange the events into a plausible story, then ask participants to walk through it aloud. For this example, the first pass might read: Return requested → Return authorized → Parcel received → Item inspected → Refund requested → Refund confirmed.
This sequence is a discussion model for the example, not a statement about every retailer's policy. If an actual team refunds before receipt, its map should show that. If inspection and another activity can happen independently, place them on separate tracks instead of implying that one always waits for the other.
Brandolini's Conversational System pattern cautions against forcing a fixed sequence onto behavior that is concurrent or can occur in different orders. The question is what depends on what, not how neatly the notes line up.
When people disagree, add a bright pink Hot Spot near the affected event. Write the disagreement as a question: “Does authorization guarantee a refund?” is more useful than “Policy problem.” Continue far enough to see the surrounding process, then return to the question with the right participants.
Connect events to actions and information
Once the event story is understandable, add the actions that make events possible. Use blue notes for commands or actions and identify the person or system initiating them. Add information needed for a decision only where it helps explain the behavior. Introducing every possible symbol at the beginning can make the workshop feel like a notation lesson.
The retailer's first detailed section could look like this:
| Event or situation | Action to examine | Information needed | Question to resolve |
|---|---|---|---|
| Return requested | Authorize return | Order, item, and applicable returns policy | Who may approve an exception? |
| Parcel received | Inspect item | Expected item and recorded reason for return | What happens when the parcel contains a different item? |
| Item inspected | Request refund | Inspection result and original payment reference | Does every inspection outcome permit a refund? |
| Refund requested | Check payment outcome | Provider response and transaction reference | How is an unknown outcome distinguished from a rejection? |
A policy describes a reaction to an event. In the example, the team might propose: “When inspection accepts the return, request the refund.” Capture that rule on a lilac note between the relevant event and action. Keep it marked as a proposal until the policy owner confirms it. A connector cannot supply missing business authority.
Notice the gap between requesting and confirming a refund. Treating them as the same event could hide delayed responses or duplicate requests. The workshop does not need to solve payment-system design immediately, but it should make the distinction visible.
Use one unusual return to test the model
After the straightforward case, choose an exception that changes the conversation. Suppose the parcel arrives without the expected item identifier. Support recognizes the customer's order, but the warehouse cannot match the contents confidently.
Ask the group to continue the story. Has “Item inspected” occurred, or only “Parcel received”? Who can request more information? What event tells support that the return needs attention? If the answer is “someone sends a message,” name the sender, the recipient, and the business fact the message communicates.
Do not invent a deadline or a refund entitlement to fill the gap. Put the unanswered policy question beside the relevant notes. Brandolini's Rush to the Goal pattern describes keeping objections and alternatives visible while working toward a baseline flow. That is more useful here than stopping every conversation until every exception is settled.
Once the business behavior is understood, a separate flowchart of exception paths can specify the operational branches. EventStorming first helps the people involved agree on the meaning of the events those branches depend on.
Build the returns model in Boardmix
Open Boardmix and create a blank board for the returns discussion. Add the scope above a wide working area. Place a small legend to one side so participants can distinguish events, actions, policies, and Hot Spots without relying on color alone.
For a mixed group, make the notation visible before anyone adds notes. A whiteboard legend with labels as well as colors helps participants read the same symbol consistently; keep the EventStorming meanings used here rather than borrowing another workshop’s color scheme.
- Add orange sticky notes for the six events in the initial story. Keep the labels large enough to read during the call.
- Leave gaps between events for blue action notes. Put “Request refund” before “Refund requested,” not in place of it.
- Add the proposed lilac policy beside the inspection result. Connect only the relationships the group has discussed.
- Place the pink question “Authorization = refund guarantee?” beside “Return authorized.” Keep unresolved questions close to the behavior they affect.
- Share the board with the appropriate editing permissions. Ask one participant from each part of the process to walk through the story while the others correct the notes.
For an online session, keep the same section in view while someone explains it. If several people are rearranging a disputed area at once, pause the editing and ask them to describe their alternatives. The board supports the conversation; rapid movement of notes is not evidence that the group agrees.
Keep the model useful without overstating it
A completed-looking board does not establish that the software implements the process, that a policy is approved, or that every important exception has been found. Separate observed behavior from proposed changes. If the group designs a new refund sequence, keep the existing sequence available so the change is visible.
For the retailer, the immediate result may be quite specific: rename an ambiguous event, confirm who can authorize an exception, and investigate how an unknown payment outcome is handled. Those questions give operations and engineering a shared starting point. The next discussion can begin at the unresolved pink note instead of repeating what “approved” means.
