Operational Bottlenecks and Capacity
Make the delivery constraint specific enough to act on.
Inspect mapped operating evidence, review the exception and assign a follow-up with the source context attached.
Illustrative people · Actual app with sample data
The business situation
A milestone is late. Establish the constraint before changing the plan.
A delivery coordinator sees an overdue handoff while the team is reviewing capacity and assets. Before promising a new date, they need to check the source record, speak with the owner and establish whether the capacity context is actually related.
The worked example begins with a sample onboarding milestone. It ends with a request to confirm the owner and revised date—not a claim that the app diagnosed or removed the bottleneck.
Which delivery constraint needs attention, and what can we verify about it?
- Delivery coordinator
- Checks the commitment, source record and deadline.
- Resource or workstream owner
- Confirms the constraint and the feasible next milestone.
- Operations leader
- Agrees the response and reviews the updated evidence.
A worked example / Three product views
Move from an exception to a scoped operational request.
The delivery and capacity views use mapped sample records. Check the relationship between a capacity condition and the overdue milestone before deciding how to respond.
- 01 / INSPECT DELIVERY
Find the commitment that needs a response.
Open Operations Delivery and check the deadline horizon, current-state timestamp and data definitions. Review the overdue or upcoming milestone evidence before treating an aggregate count as the whole problem.
The sample has one overdue milestone. The underlying onboarding handoff is still open. Check its supporting source context and confirm with the workstream owner what was expected.
Between the screensThe coordinator opens the supporting evidence and asks the owner about the commitment. A late date alone does not explain the cause.
Product view · Sample data Read the horizon and availability labels with the overdue count. The sample points to a handoff that needs review; it does not establish why the work is late. - 02 / CHECK THE RELATIONSHIP
Use capacity context carefully.
Open Capacity & Assets to inspect available resources, capacity records, assets and maintenance context. Where mapped records support a relationship to the affected work, compare their definitions, period and units.
The counts shown are inventory and record counts. Three resources and one capacity record do not tell you how many hours are free. Ask the resource owner to confirm whether the suspected constraint affects this milestone.
Between the screensHuman review or configured mappings establish the relationship. Do not infer a link from the fact that two records appear in the same workspace.
Product view · Sample data Use mapped record counts alongside the relevant scheduling and resource evidence. Verify the relationship to the overdue handoff before drawing a capacity conclusion. - 03 / ASSIGN THE CONFIRMATION
Make the next request specific.
After reviewing the evidence, assign a request to confirm the milestone owner and revised date. Include the source context and the intended completion condition in Action Center.
The expanded task is a manually prepared example. Local operational exceptions can also support owner, due-date and review notes where available; neither path is an ERP transaction update.
Between the screensA person creates the task after review. The responsible team makes any approved source-system change through its own authorized workflow.
Product view · Sample data The request is to confirm the commitment and owner. It remains incomplete and does not change an external system or demonstrate that the delay has been resolved.
The human decision
Decide which commitment can be made with confidence.
The operations lead reviews the owner’s explanation and chooses whether to revise the date, change the plan or gather more evidence. Keep any suspected cause separate from the observed delay, and communicate the confirmed commitment to the affected commercial or delivery team.
An operational follow-up the owner can act on.
- Scoped exception
- The specific milestone and the available source evidence.
- Confirmed request
- An owner asked to validate the next commitment and required context.
- Review condition
- An agreed check of the updated record and remaining delivery risk.
Follow the outcome
Look for the updated source evidence, not just a closed task.
Revisit the milestone after the owner responds and the source refreshes. Compare the same scope, dates and units before assessing whether the constraint changed. An unavailable feed remains unavailable. The verified operational integrations are read-only and depend on customer-specific mappings; they do not provide ERP transaction write-back.
Supporting capabilities
The tools behind this workflow.
Before you begin
Practical questions about this workflow.
Do resource counts show available capacity?
Not on their own. Review the mapped capacity measures, definitions, units and relationship to the affected work. Missing or partial information cannot establish utilization or spare hours.
Will assigning the task update the ERP?
No ERP transaction write-back is established. The verified integrations provide read-only operational context; local tasks and exception notes coordinate the human response.
Your team’s next review
Bring a delivery commitment that needs a clearer plan.
We’ll examine the source context, capacity question and owned follow-up needed before your team confirms its next milestone.