# Sample workflow boundary map

> **Illustrative example — not a customer deployment.**
>
> This document is a synthetic sample authored by VeerOne to show what a
> workflow boundary map looks like. It does not describe a real organization,
> a real engagement, or any measured outcome. No customer approved, produced,
> or reviewed this document.

## Workflow being bounded

**Working name:** Service appointment change requests (synthetic)

**Why this workflow:** Requests arrive with partial details, staff time goes
to re-asking for the same missing information, and every change needs a
person's confirmation before it happens.

## In scope

- Reading an incoming change request and summarizing what it asks for.
- Checking the request against the required-details checklist.
- Preparing a short summary and a missing-details list for staff.
- Routing the prepared summary to the staff review queue.

## Out of scope

- Changing, canceling, or creating any appointment.
- Confirming anything to the requester without staff review.
- Reading systems outside the named request inbox.
- Any promise about response times or outcomes.

## Where a person decides

| Decision point | Who decides | What the system does |
| --- | --- | --- |
| Appointment reference is missing | Staff member | Flags the gap and lists it |
| Requester identity is unclear | Staff member | Marks the summary incomplete |
| The change itself | Staff member | Never acts; prepares only |

## Open unknowns a buyer would settle in scoping

- Which inbox or inboxes the workflow may read.
- Who is on the staff review rota.
- What the requester is told while a change is pending.

## How to read this sample

A boundary map is useful because of what it refuses to do. The out-of-scope
list and the decision table are the parts a buyer should inspect hardest:
they show where automation stops and where named people stay responsible.