1. Define the decision your tower must support
Choose an account portfolio, region or last-mile operation and a question: which deliveries need intervention now? The answer should include order, status, source, latest information time, owner and proposed action. Zild can connect ESL driver and delivery monitoring to work coordination.
The pilot must distinguish a late delivery from one lacking recent information. These are different problems: the first requires delay handling; the second requires checking the source before asserting what happened. Also define who may access location, recipient and proof of delivery.
2. Establish an event contract
Define delivery, pickup, route, driver or partner and incident identifiers according to available fields. Store event time, integration receipt time and query time separately. Preserve timezone, source system, event type, previous state and associated evidence.
GS1 describes visibility events through dimensions such as what happened, when, where and business context. We use that organization as a design reference; it does not mean the ESL connector or Zild deployment is EPCIS-certified. Map actual API fields before defining the contract.
3. Make freshness observable
Real-time operation depends on the frequency and quality of data produced by the connected operation. Show information age and last synchronization rather than presenting an old position as current. When the source is unavailable, mark the state as stale and notify the integration owner.
Define freshness requirements by use: monitoring an active delivery and checking closing documents may require different frequencies. Avoid querying a full report for every question. Plan filters, data volume, cadence and handling of provider limits.
4. Handle duplicates and out-of-order events
The same incident may arrive again after a communication failure. Use event identity or a validated business key to prevent duplicate tasks and messages. A later-received event is not necessarily the latest fact. Preserve operational sequence and route contradictions for review.
Synthetic example: delivery completed at 14:10, but an earlier attempt reaches the integration at 14:20. The system should not automatically revert to attempted delivery. Record both facts, retain validated completion and identify the late update. Test the rule against actual ESL status semantics.
5. Prioritize and coordinate exceptions
Define categories such as absent recipient, address mismatch, damage, missing proof and deadline risk. Combine contracted deadlines, impact and time without action to organize the queue. The agent gathers context and proposes routing; approved rules determine who can reschedule, negotiate or close an incident.
Drivers and contractors receive only information needed for the service. A field message must be linked to the order and relevant evidence before updating state. Redelivery, return, damage acceptance and financial compensation should not arise from an interpretation lacking defined approval.
6. Configure ESL for the pilot scope
The Zild guide separates the Data Export API token from the user token used for incidents. Request required access from the ESL administrator and configure the environment URL. Saving the connector does not prove a query or change is authorized; test permitted tools with test data.
For reports, inspect templates and structure before building filters. In the documented pickup-measurement feature, updates do not change status and reject pickups that already have measurements; derived values are calculated by ESL. Do not reuse this operation as an overwrite mechanism or delivery confirmation.
7. Build an operational benchmark
Reserve cases covering normal deliveries, duplicate events, delayed information, returns and unavailable sources. Compare current and assisted queues on the same set, including human review. Record event-to-detection time, time to first action, correct resolution, reopened incidents and false alerts.
Cost per correctly resolved incident = period API, processing and human-work costs ÷ incidents with validated resolution. Include failed attempts and checking effort. Also compare data freshness: apparent speed gains may conceal stale information. Do not compare portfolios of different complexity without disclosing that limitation.
8. Use research without transferring results improperly
LaDe, by Wu and coauthors, presents industrial last-mile data with package information and task events across different scenarios and cities. It illustrates why temporal context, location and scenario diversity matter in evaluation. The version consulted is a preprint revised in 2025.
The dataset does not represent your fleet, Brazilian networks or Zild results. Use the research to inform test design, not to import promised accuracy or savings. External data requires license and suitability checks; deployment criteria should come from authorized evidence within your own operation.
9. Expand with exit criteria
Before execution, document failures that block the pilot: cross-customer exposure, incorrect status changes, duplicate actions or missing ownership. Define manager-approved freshness and quality thresholds. The decision may be to expand one route, retain read-only queries or fix the integration and repeat.
Bring Zild an event sample, status dictionary, exception owners and ESL access scope. The design connects agents, tools and people to turn visibility into action with traceability through resolution.
Data and research references
- GS1 — EPCIS visibility events Checked on
- Wu et al. — LaDe, arXiv:2306.10675v3 (2025) Checked on
Connect one operational exception
Gather this information to scope the work with Zild. During the conversation, we assess integrations, owners and how to measure outcomes.
- A shipment or delivery with a resolved exception
- Events and systems showing progress
- The owner and deadline for the next action
Describe the process in the form; samples and documents can be prepared later without confidential data.
The form opens with this guide’s title. You can edit everything before sending.