Group by the unit of work
Start with the store / installation / project. Tracking numbers support that job rather than define it.
Connected Logistics / Full use case
Connected Logistics overview Many shipments. One installation. A downstream readiness decision.
Redwood Logistics / Ready-to-Install
From Package Tracking to Installation Readiness
Every shipment could have a status and the store could still be unready for the technician.
IMPLEMENTED WORK · PORTFOLIO RECONSTRUCTION
Summary
A retail installation depended on equipment and materials arriving from multiple vendors and carriers. Individual tracking records could show where the pieces were, but not whether work could begin.
I reorganized the experience around the store/project, combining deliveries into one readiness view and exposing the exceptions that could prevent dispatch.
Explore in Connected LogisticsTracking the pieces did not tell us the job was ready.
15+ incoming deliveries
- Vendor A · equipment
- Vendor B · materials
- Vendor C · components
- Additional parcel + freight deliveries
Each with its own carrier, tracking number, ETA and exception.
One store / installation
Are all required dependencies present and usable?
Readiness summarizes the job. Shipment details explain the answer.
Generalized dependency model, not a production portal screenshot. Requirements and delivery counts vary by installation.
The tension
Shipment status answered the carrier’s question better than the installer’s.
A package could arrive while a missing or damaged component still prevented the installation.
Shipment status
Where is this delivery?
- Has it shipped?
- When should it arrive?
- Was it delivered?
Valid answers about one shipment.
Installation readiness
Can the next team begin?
- Are all required items here and usable?
- What is delayed, lost or damaged?
- What needs intervention before dispatch?
A decision across the whole installation.
The important status was not “delivered.” It was “ready for the next team.”
Research + system
One installation crossed several organizational boundaries.
A store could depend on 15+ deliveries. The missing layer was dependency-level understanding across the job.
Research → dependency model
- 01Vendor ordersEach vendor supplies part of the installation.
- 02Multiple carriersDeliveries move independently.
- 03Store / project receivingPhysical receipt is a separate event.
- 04HQ coordinationSomeone needs to assess all required dependencies.
- 05Technician dispatchThe installation can begin only when the prerequisites align.
Coordinators were piecing together statuses across carrier sites, spreadsheets and communication. Grouping by destination and project connected those fragments to the decision they actually needed to make.
How the problem changed
- 01Track individual deliveriesEach shipment has its own status.
- 0215+ deliveries, one locationIndependent vendors contribute to one installation.
- 03Delivery is not readinessThe next team still has to reconstruct the whole job.
- 04Group installation dependenciesMake project / location the unit of meaning.
- 05Understand blockers before dispatchThe next action depends on required pieces being usable.
The pattern
Organize around the downstream decision.
Readiness is the summary. Shipment-level evidence remains available underneath it.
Early design / decision model
- 01Shipment evidenceRetain the original carrier and tracking facts.
- 02Associate to project / locationConnect deliveries to the job they support.
- 03Validate required piecesReceipt and usability are different checks.
- 04Determine readinessAnswer whether downstream work can begin.
- 05Expose blockersMake the reason for the answer inspectable.
RECONSTRUCTION · ILLUSTRATIVE SCENARIO
Store 1842
Not ready for installation12 of 15 required deliveries confirmed usable
- 1 delayedExpected delivery outstanding
- 1 lostRequired component unlocated
- 1 damagedArrived, but not usable
Inspect the three blockers before considering dispatch.
RECONSTRUCTION · SAME ILLUSTRATIVE SCENARIO
What prevents readiness?
| Required delivery | Evidence | Coordinator follow-up |
|---|---|---|
| Installation materials | Delayed · expected arrival not met | Check carrier timing and installation plan. |
| Equipment component | Lost · current location unresolved | Contact carrier/vendor to resolve fulfillment. |
| Required assembly | Delivered · damage reported | Review usability and replacement with the vendor. |
Carrier, tracking number, timing and the associated requirement stay inspectable. These are example review actions, not automated replacement workflows.
Fictional store and example counts; no historical performance metric is implied. The damaged delivery is received but excluded from the 12 confirmed usable deliveries.
RECONSTRUCTION
Delivered is a shipment state. Ready is an operational state.
- Ready
- Required dependencies are present and usable; installation can proceed.
- Delayed
- A required delivery is expected later than planned.
- Lost
- A required item cannot be located through the expected shipment.
- Damaged
- An item arrived but cannot be assumed usable.
- Needs Review Reconstructed addition
- Incomplete or conflicting evidence requires human judgment.
Generalized state definitions. “Needs Review” is part of the portfolio reconstruction, not a verified shipped production label.
Design decisions
Design for readiness, not tracking density.
Make blockers easy to find without concealing the shipment facts behind the summary.
Emphasize blockers
Normal progress can recede. Missing, changed or unusable dependencies need attention.
Separate receipt from usability
Delivered + damaged is not equivalent to ready.
Preserve the evidence
Keep carrier, tracking, timing, exception and requirement details available for investigation.
Make uncertainty explicit
Needs Review invites judgment when the evidence cannot support a confident answer.
Detailed readiness workflow
- 01 · Entry point
Group the deliveries
Schematic view / evidenceVendor and carrier records associated with the installation location.
- User action
- Open the location / project.
- System / shared response
- The required deliveries share one operational context.
- 02 · Workflow state
Read the readiness summary
Schematic view / evidenceRequired dependencies present and usable, or blockers remain.
- User action
- Determine whether the next team can act.
- System / shared response
- The summary identifies the need for review rather than forcing manual aggregation.
- 03 · Workflow state
Open the blocker
Schematic view / evidenceA missing, delayed, lost or damaged required delivery.
- User action
- Choose the dependency preventing readiness.
- System / shared response
- The focused view retains the shipment and its associated requirement.
- 04 · Workflow state
Inspect shipment evidence
Schematic view / evidenceCarrier · tracking · receipt / condition · exception · timing.
- User action
- Review the evidence and coordinate with the relevant vendor or carrier.
- System / shared response
- Resolution stays connected to the dependency that blocked the job.
DecisionAre all required dependencies present and usable?
Yes → coordinate the next teamReady for the dispatch handoff
The coordinator passes the readiness decision into technician coordination; this does not schedule the technician automatically.
No / uncertain → resolve the blockerHold dispatch and continue review
Coordinate missing, delayed, lost or damaged items, then revisit readiness with updated evidence.
Resulting state / return to evidenceRecheck project readiness after resolution
The next action follows the dependency state. The reconstruction does not invent replacement ordering, guaranteed availability or prevented-trip metrics.
One project, fifteen dependencies
Inspect the delivery preventing readiness
Evidence → Decision → Tradeoff
- 01EvidenceScattered shipment states support one installation.
- 02DecisionOrganize by the downstream unit: project / location.
- 03TradeoffAggregation can hide a delivery’s source facts.
- 04ResponsePair readiness summary with shipment drill-down.
Impact in reality
What shipped, and what is reconstructed.
Location-level readiness shipped. The current prototype extends the pattern without rewriting implementation history.
Store / project-level readiness
- Multiple vendor deliveries grouped into a shared installation context.
- Delivery and exception states, including delayed, lost and damaged.
- Visibility into whether downstream work was ready to proceed.
A shipped coordination tool
The portal was used for headquarters coordination. It made blockers visible before dispatch.
No reliable quantified reduction in wasted trips, technician hours or missed windows is available.
A more connected handoff
Explicit Needs Review, richer cross-role state, notification/handoff logic and subsequent-exception handling are reconstruction directions.
They are not claims about a completed historical dispatching platform.
Implementation / outcome evidence
Implemented
Shipped Frito-Lay portal
A coordination tool for headquarters coordinators and dispatchers.
Product behavior
Multi-vendor deliveries grouped
Deliveries shared the context of the installation location / project.
Operational decision
Readiness visible
Shipment evidence informed whether the downstream job could begin.
Reality check · what the system could and could not do
What it could clarify
- Which locations were ready.
- Which requirements remained outstanding.
- Which exceptions needed attention before the handoff.
What remained outside the software
Incorrect shipments, physical damage, carrier delays, lost freight, receiving behavior, replacement lead times, technician availability and late or incorrect external data.
The system could make readiness visible. It could not make every dependency reliable.
From object status to operational readiness
- Identify the downstream action.
- Identify its required dependencies.
- Group evidence around the outcome.
- Separate normal progress from blockers.
- Preserve drill-down evidence.
- Make uncertainty explicit.
- Hand off to the next team.
Useful anywhere multiple independent dependencies must converge before the next team can act.