Illustrative workflow
A delivery-window change, coordinated end to end.
How Disponi handles a routine delivery-window change for a freight carrier — matching the shipment, checking the delivery policy, acting within it, and following through, with every step recorded.
The scenario
The scenario belongs to the freight carrier described above. A shipper’s coordinator emails the shared inbox with a change that touches the shipment, the dispatch system, and the delivery calendar at once.
- Shipper contact: Daniel Okafor, shipping coordinator at Cedar Ridge Retail.
- Request: Move Tuesday’s delivery for shipment SHP-5531 from the 9 AM window to the 2 PM window.
- Systems involved: The shared inbox, the transport-management system, the dispatch system, and the shared delivery calendar.
How the request moves
This is the safe path: a change request that satisfies the carrier’s configured delivery policy. Each stage is a step the agent takes, with the record it leaves behind.
Request received
Daniel Okafor, shipping coordinator at Cedar Ridge Retail, emails the shared inbox: “Could we move Tuesday’s delivery to the 2 PM window?” The agent classifies the message as a delivery-window change and checks that the sender is a known contact for an existing shipment.
Shipment matched
The request is matched to shipment SHP-5531, which has a Tuesday delivery scheduled in the 9 AM window. The agent pulls the shipment record, the assigned run, and the current window from the transport-management system.
Availability and policy checks
The agent checks that a 2 PM slot is available on the route and compares the request against the carrier’s configured delivery policy: allowed windows, notice periods, and the approval threshold for route and shipment changes.
Bounded action, within policy
The change is inside the configured boundaries, so the agent is permitted to act. It updates the delivery window on the shipment in the transport-management system and adjusts the run in the dispatch system — nothing outside the change request.
Affected-system updates
The shipment record, the dispatch system, and the shared delivery calendar are updated in one pass. Every update lists the source request and the policy rule that permitted it.
Stakeholder communication
The shipper contact is confirmed with the new window, and the assigned driver is notified of the change. Both messages are sent from the shared inbox so nothing hides in a private thread — or dies with a shift change.
Action record
The agent writes an attributable record: what was requested, which checks ran, which rule allowed the action, what changed, and when. The record names the request, not the agent, as the source of the change.
Follow-through
On delivery day the agent verifies that the shipment was delivered in the agreed window and closes the loop. Anything unusual is flagged to the operations manager rather than silently accepted.
Branch: when a change needs business approval
Not every request fits the configured rules. When a change exceeds a policy boundary or has no safe deterministic answer, Disponi pauses and brings the decision to the customer — it never invents a business decision.
Business exception — the customer decides
Request outside policy
Daniel also asks to raise the shipment from 8 to 12 pallets. The increase crosses the carrier’s threshold for route and vehicle changes, which sits above the configured approval limit.
Paused with context
The agent does not invent a decision. It pauses and presents the relevant context to the carrier’s operations manager: the shipment, the current run, the policy rule, and the options that fit within the rules.
Customer decides
The operations manager approves a variant or declines. While the request waits, no shipment record, run, or message is changed. The agent does not act on the request until an approval is recorded.
Resolution follows the decision
Once approved, the agent applies exactly what was approved, updates the affected systems, notifies the stakeholders, and records the approval alongside the action. If it is declined, the requester is told and the request is closed.
Branch: when a technical dependency fails
Sometimes the blocker is not a business question at all. An unavailable integration, an expired authorization, or an unexpected data format is a technical exception — it is owned and resolved by Disponi, and it is never portrayed as a successfully completed business request.
Technical exception — Disponi responds
Unavailable integration
The transport-management system is unreachable when the agent tries to update the delivery window. The agent marks the request as blocked by a technical exception, retries within configured bounds, and escalates to Disponi monitoring — the request is not marked resolved.
Expired authorization
A connection between systems fails because an integration credential expired. The agent detects the failure, pauses the request, and alerts Disponi operations. It does not attempt an unsupported workaround, and the request stays open until the integration is healthy.
Malformed source data
A carrier confirmation arrives in an unexpected format that cannot be matched to a shipment reliably. The agent flags the ambiguity and asks for clarification instead of guessing. The business request is not reported as successfully completed while the data is unsound.
Technical exception, owned by Disponi
Every technical failure above is a platform or integration incident: Disponi monitors, recovers, and communicates status. The customer is told the request is on hold and why. Business resolution happens only after the technical exception is closed and the work can be completed correctly.
Who owns what
The boundary that keeps this safe is simple: business decisions stay with the customer, technical operation stays with Disponi.
The customer owns
- Business objectives and what success means for each workflow
- KPI definitions and which numbers count as correct
- Access decisions: which systems Disponi may use and what it may do in them
- Business policy, including the boundaries that require approval
- Consequential approvals before Disponi takes bounded action
- Review of outputs, decisions about what the results mean, and final business accountability
- In this scenario: the operations manager owns delivery policies, shipper terms, and any change to a shipper’s shipment or the delivery schedule.
Disponi owns
- Platform operation and keeping the configured workflow running
- Maintenance of workflow configuration as systems change
- Integration health and connection monitoring
- Technical monitoring, alerting, and incident detection
- Technical incident response, recovery, and communication
- Honest status reporting when a technical exception blocks a request
- In this scenario: Disponi keeps the transport-management, dispatch, and calendar connections running and owns their technical incidents.
“Managed” means Disponi operates the system and the configured workflow. It does not transfer the customer’s business accountability, and it does not guarantee business outcomes.
Where this fits
Pickup and delivery coordination is not the first workflow this carrier would deploy. It is a later, more bounded step — the sample assessment shows the earlier, read-heavy freight reporting workflow that comes first. The progression is a path Disponi can follow, not a guarantee that every customer takes it.
- ObserveRead-only workflows that collect and prepare information.
- PrepareDrafts, checks, and follow-ups that stay inside the team.
- Coordinate with approvalCross-system coordination that pauses for customer approval at consequential points.
- Act within policyBounded, recorded actions inside rules the customer defines.