# Measure external waiting with a response boundary

Illustrative planning brief; no automatic product import.

Synthetic case: A request is sent 09:00, acknowledged 10:00, and a usable input arrives 15:00. The report labels the one-hour acknowledgment as full resolution.

## Decision

Record one-hour acknowledgment and six-hour usable-input wait as separate measures with separate ending events.

## Owned work

- Define the needed input
  - Owner role: Receiving owner
  - Acceptance evidence: The required usable input is written before timing starts.
- Retain response events
  - Owner role: Coordinator
  - Acceptance evidence: Acknowledgment and usable receipt are separately timestamped.
- Name the measured interval
  - Owner role: Report owner
  - Acceptance evidence: One-hour first response is not called six-hour input resolution.

## Workflow

1. State what ends each wait measure.
2. Keep acknowledgment separate from usable received evidence.
3. Flag still-open input waits at a named checkpoint.

## Judgment

This local policy does not assert a supplier SLA or contractual obligation. An acknowledgment may contain no usable input.


## Filled review note

Wait note: acknowledgment after 1h; usable input after 6h. These are separate observed response boundaries.


## Workflow questions

### Can we report both response times?

Yes if both endings are named and evidenced. They answer different questions.

### What if the input is still unusable?

The usable-input wait remains open under this policy; record the checkpoint instead of inventing an end.

## Product connection

Bring this manual reporting policy and its owned checks into your TeamBoostAI work discussion. Native report/export fields and historical reconstruction depend on your account and implementation; this worksheet does not import or change product records.

Confirm account availability before adopting this manual outline.

## Decision workshop

Synthetic examples only. Manual worksheet; no automatic import or product writes.

### Synthetic reporting records

Event | UTC time | Meaning
--- | --- | ---
Request sent | 09:00 | Start
Acknowledgment | 10:00 | First-response end
Usable input received | 15:00 | Input-wait end

### Version changes

Boundary | Draft | Revised
--- | --- | ---
End event | Acknowledgment used as usable receipt | Separate acknowledgment and usable-input events
Promise | Supplier assurance counted as delivery | Receiving owner checks actual usable input

### Draft or earlier version (review its limits)

Draft: resolved in one hour because the request was acknowledged.

### Revised example

Wait note: acknowledgment after 1h; usable input after 6h. These are separate observed response boundaries.

### Decision situations

- The receiving owner confirmed usable input: Close the usable-input interval at that receipt.
- Only acknowledgment exists: Report first response; keep usable-input wait open.
- The required input is unspecified: Define usable input before reporting resolution.

### Evidence dependencies

- Required input → Acknowledgment: first response
- Required input → Usable receipt: input fulfilled

### Method references

- The Kanban Guide, May 2025: https://kanbanguides.org/the-kanban-guide/2025.5/ — Clock and work-item definitions; examples and local rules are our own.