Interactive example · fictional data
The delivery failed. The alternative needed a decision.
A logistics exception crosses an external event, policy, a decision, contact with the recipient and the carrier’s answer; acceptance of a new attempt is not delivery.
Conceptual demonstration. It does not represent a customer case or prove available features.
Video
Transcript
[Illustrative example · fictional data] [Carrier event · Day 1 · 18:40] [Delivery attempt failed] [Recipient absent] [PED-3190 · fictional] The carrier reported: the delivery failed.
[NebulaOS · Starya builds and connects within the scope of the operation · Exception policy] [Illustrative interface · Features and integrations depend on the deployment.] On NebulaOS, connected by Starya within the scope of the operation, the agent looks up order, incident and policy.
[The delivery did not happen · Day 1 · 18:50] [Proposal v1 · day 3, 8 am–12 pm · R$ 68] [Agent’s limit · R$ 40] [Blocked · above the limit] [NebulaWorks · Waiting for logistics management’s decision] [Without a new attempt, the day 3 date is missed.] [Approve proposal v1 · Reject proposal v1] It prepares an alternative at R$ 68, but the agent’s limit is R$ 40: the proposal is blocked. In NebulaWorks, logistics management sees the context and approves this version.
[Authorized · proposal v1 · Day 1 · 19:45] [Approving sends nothing to the carrier.] [Recipient · Channel with the recipient · Day 1 · 19:50] [18:55 · proposal v1 blocked] [Presence and address confirmed · 20:25] [Waiting for acceptance · Carrier system · Day 1 · 20:30 → 21:20] [A request sent is not acceptance.] Approving sends nothing to the carrier: first, the service desk contacts the recipient. The new attempt is requested. Requesting is not acceptance.
[New attempt accepted · delivery pending · Day 1 · 21:20] [Day 1 · 21:25] [Delivery to the recipient is still pending.] The carrier accepts; the customer is informed. The delivery is still pending.
[Who decides your exception, and how does the decision reach the system that executes it?] [Starya · We accelerate your AI strategy. NebulaOS is the operating foundation.] Who decides your exception, and how does the decision reach the system that executes it?
What confirms completion
The carrier confirms acceptance of the new attempt. Delivery to the recipient is a later event.
What NebulaOS supports in this scenario
In this scenario, NebulaOS receives the event from orders and tracking, compares the alternative with the exception policy, takes the decision to NebulaWorks and continues through the channel with the recipient and the carrier system, connected within the scope of the operation. The events the carrier sends and the policy limits depend on the deployment.
- NebulaWorks Brings together the work, owners, pending items and process artifacts.
- Starya / FDE Designs the flow, rules and integrations of the agreed scope with your team.
Try it yourself
Walk through the steps of this scenario and see what changes with each choice. Fictional data; no system is accessed.
Open the simulation
Illustrative simulation · no system is accessed
The delivery failed: who decides, who answers and what confirms the new attempt
Goal Handle a failed delivery without going beyond the agent’s authority, contact the recipient and get the carrier to accept a new attempt, without declaring the delivery done.
- 01Incident
- 02Rule and decision
- 03Contact
- 04Answer
- 05Request
- 06Acceptance
- 07Inform
Simulation clock Day 1 · 18:40
What we know now · v1 · Day 1 · 18:40 · In progress · step 1 of 7
The failure event arrived from the carrier.
Nobody opened a ticket: the event starts the work. The agent looks up the order and the incident before proposing anything.
Who answers now Operations agent
System Orders and tracking
Preserved history
Every event, deadline, decision and answer stays here, with the simulation time, in this session only. Starting over clears the simulation.
- v1 · Day 1 · 18:40Carrier event: delivery attempt failed, recipient absent. Order PED-3190 (fictional).
Systems and responsibilities
| System | What it answers for | How it takes part |
|---|---|---|
| Orders and tracking | Order, incident and the date promised to the customer | Receives the failure event. Looked up only |
| Exception policy (fictional) | The agent’s cost limit and who approves above it | Checked before any request. The decision above the limit stays in NebulaWorks |
| Channel with the recipient | Confirmation of presence and address | Receives the message and the call from the service desk |
| Carrier system | Acceptance or refusal of the new attempt | Receives the request and is the only one that confirms acceptance |
Questions to take to your team
- Systems and data Which order and incident data does the operation consult before proposing an alternative?
- Authority Which cost or deadline requires approval?
- Owner Who can authorize the new alternative?
- Result Which carrier response confirms the next step?
Use these questions with the guide What to ask about AI already in use
Related content
Steps
Owner, system, state and pending item of the experience’s 7 steps, with decisions and limits
Step 1 · Incident
Receive the incident
The failure event arrives from the carrier. Order and incident are looked up to understand the situation.
- Owner
- Operations agent
- System
- Orders and tracking
- State
- Incident looked up
- Pending
- The delivery did not happen.
Step 2 · Rule and decision
Check the limit and decide
An alternative is prepared and compared with the policy. Above the agent’s limit, the proposal stays blocked, and logistics management approves, rejects or asks for another version in NebulaWorks, knowing the deadline, cost and consequence. A changed version is checked again.
- Owner
- Operations agent and logistics management
- System
- Exception policy and NebulaWorks
- State
- Alternative authorized
- Pending
- The approval still needs to be carried out.
Step 3 · Contact
Contact the recipient
The service desk asks for confirmation of presence and address before contacting the carrier.
- Owner
- Service desk
- System
- Channel with the recipient
- State
- Contact sent
- Pending
- The recipient’s answer is still missing.
Step 4 · Answer
Wait for the recipient’s answer
The recipient confirms presence and address. With no answer on time, the service desk calls the recipient before contacting the carrier.
- Owner
- Service desk
- System
- Channel with the recipient
- State
- Recipient confirmed
- Pending
- The new attempt still has to be requested.
Step 5 · Request
Request the new attempt
The new attempt is requested from the carrier with the authorized parameters.
- Owner
- Logistics team
- System
- Carrier system
- State
- Waiting for acceptance
- Pending
- A request sent is not acceptance.
Step 6 · Acceptance
Confirm the acceptance
The carrier accepts the new attempt. With no answer on time, the team checks before repeating; a refusal goes back to the decision.
- Owner
- Logistics team
- System
- Carrier system
- State
- New attempt accepted
- Pending
- The customer still needs to be informed.
Step 7 · Inform
Inform the customer
The service desk informs the customer about the accepted new attempt, without declaring the delivery.
- Owner
- Service desk
- System
- Channel with the recipient
- State
- Customer informed
- Pending
- Delivery to the recipient is still pending.
Decisions to explore
- Cost within or above the authority limit
- Approval granted, rejected or with changed parameters
- Recipient answers on time or not
- Carrier accepts, refuses or does not answer
Pending items and limits
- The original block stays in the history.
- Approval is not a request sent; a request sent is not acceptance.
- Delivery to the recipient is a later event.
- Policy, amounts, days and references are fictional.
Text version
The main content, without depending on the video or the simulation.
Initial request Carrier event: the delivery did not happen. Nobody opened a ticket.
A failure event arrives from the carrier system. The agent looks up the order and the incident and prepares an alternative. Above the authority limit, the proposal stays blocked until logistics management decides, in NebulaWorks, on a specific version. The recipient is contacted before anything is requested, and the new attempt is accepted only when the carrier confirms it. The delivery is still pending.
The carrier system reports that a delivery failed. The agent looks up the order and the incident and prepares an alternative. Under the fictional policy, the agent authorizes up to R$ 40; the R$ 68 alternative is blocked and goes to NebulaWorks, where logistics management approves, rejects or asks for another version, which is checked again. With the proposal authorized, the service desk asks the recipient to confirm presence and address and, with no answer on time, calls. Then the new attempt is requested from the carrier; with no answer on time, the team checks before repeating. When the carrier accepts, the customer is informed, and the delivery is still pending. A refusal sends the incident back for a decision.