What business boundaries should builders map before modelling the workflow?

Use this checklist to define the operational boundary before turning a support referral into agent actions.

- Identify the role that first hears the difficulty. - Define the event that creates specialist ownership. - Separate customer consent from internal queue acceptance. - Map information the receiving team actually needs. - Identify work that continues during the handover. - Record where the customer must repeat information. - Define who handles a rejected referral.

The map should describe responsibilities rather than reproduce an organisational chart. In healthcare administration, a reception team may recognise difficulty paying an invoice, while an accounts support team manages the policy-bound assessment. A referral can cross that boundary without transferring every responsibility for the patient's administrative enquiry.

Pay particular attention to gaps between actions. Sending a message, creating a case and having that case accepted can be separate events. If the environment collapses them into one successful action, agents never encounter the period when ownership is uncertain.

MirrorFirm could use the agreed map to structure generated roles and handover records. Builders gain a clearer specification for which transitions the simulator must represent and which organisational details can remain outside the initial environment.