Mission

Coordinating on-site logistics: what changed this cycle on Mission

Fixing the physical handoff: how pre-flight manifests, geo-anchored dispute windows, and Mia’s site parser reduced late-start friction on Mission jobs.

Fourteen percent of all billing disputes on Mission during the previous quarter originated not from poor craft, but from a four-minute gap at the front door. A contractor arrives in a courtyard in Berlin’s Neukölln district; the gate code provided in the chat is two digits short; the client is in a meeting; the clock is ticking on a fixed-rate booking. By the time access is resolved, the schedule has collapsed, and the debate over who pays for the wasted thirty minutes begins.

Legacy service directories treat communication as an unmonitored sidecar, offloading logistics to unrecorded phone calls or external messaging apps. When friction occurs, the platform inspects a void. In this deployment cycle on Mission, we overhauled how on-site logistics are captured, structured, and synchronized with our transactional escrow.

The Anatomy of On-Site Friction

Coordinating physical labor requires three distinct variables to align simultaneously: spatial access, asset readiness, and dynamic scope verification. When any single variable fails, disputes follow predictable lines:

  1. Unverified Arrival: The provider claims they arrived on time; the host claims they were an hour late.
  2. Prerequisite Deficits: The provider arrives to assemble wall-mounted shelving, but the host bought hollow-core drywall anchors for a concrete wall.
  3. Undocumented Scope Creep: The client verbally asks for two additional light fixtures to be rewired while the electrician is on-site, leading to post-completion friction over the final bill.

To solve this without turning the platform into a surveillance apparatus, we deployed three specific mechanisms this cycle: Pre-Flight Manifests, Geo-Anchored Dispute Windows, and Mia’s Site Parser.

Mechanics: Pre-Flight Manifests and Site Parsing

Before this release, a Mission job moved directly from bid acceptance to the calendar. Now, job activation requires a two-sided structural sync.

When a service request is created, Mia’s context memory ingests the client’s description, cross-referencing it with historical category requirements and, where applicable, short-term rental access rules from Nest. If a client requests an end-of-tenancy deep clean on Nest, Mia extracts structural constraints—such as square footage, hot water valve locations, and parking restrictions—and auto-populates a structured On-Site Manifest.

Forty-eight hours before the scheduled arrival, the provider receives a prompt to review the manifest. If specialized tools or materials are required, the provider checks them off in the manifest interface. The transaction escrow remains in a 'pending-validation' state until both parties confirm these baseline requirements. If the host fails to confirm parking access or door codes twelve hours prior, the booking window shifts automatically, protecting the provider’s calendar without penalizing their contribution score.

Geo-Anchored Dispute Windows

Arrival tracking on Mission does not rely on continuous, battery-draining background GPS monitoring. Instead, we implemented single-point cryptographic check-ins.

When the provider arrives within a 50-meter radius of the job site coordinates, their device generates a localized proof-of-presence token. This token logs the precise timestamp to the Mission universe ledger and opens a 15-minute 'Prep Window.' During this window, the provider verifies that site conditions match the manifest (e.g., power is running, the site is accessible).

If the provider cannot enter the premises, tapping 'Access Blocked' triggers an immediate automated prompt to the host via SMS and push notification. If the host does not respond within the 15-minute window, the dispute protocol activates automatically: the provider is freed from the site, a standardized travel compensation fee is released from the locked escrow to the provider, and the remainder of the funds return to the host. Neither party needs to file a manual support ticket.

Worked Example: Commercial Kitchen Hookup

A practical case illustrates the end-to-end execution of these updates during our beta testing phase in Lyon.

  • 09:00 AM: A restaurant owner (host) books an emergency repair for a commercial refrigeration unit on Mission. The agreed price is 240 WEVAR, currently held in the WEVONE transactional escrow.
  • 09:12 AM: Mia’s Site Parser flags that the refrigeration model requires a three-phase electrical outlet and a specific refrigerant type. The system prompts the technician to confirm they carry this refrigerant before accepting the job.
  • 10:15 AM: The technician arrives at the venue. The localized proof-of-presence token registers on the ledger. The 15-minute Prep Window begins.
  • 10:22 AM: The technician discovers the rear delivery gate is padlocked, preventing equipment drop-off. They flag 'Access Blocked' in the app.
  • 10:28 AM: The host receives the high-priority override alert, opens the gate remotely, and confirms site access on their device.
  • 11:45 AM: Job completed. The technician uploads a photo of the running pressure gauges. Mia verifies the photo metadata against the site location, and the escrow releases 240 WEVAR to the technician’s account, closing the ledger entry.

How the WEVONE Platform Ledger Handles Logistics Data

Logistics data on WEVONE is not stored in isolated database rows; it is anchored directly to the transaction state machine. The Mission universe ledger records state changes sequentially:

Booking InitiatedManifest ValidatedEscrow LockedPresence ProvedScope ConfirmedEscrow Dispersed

By tying Mia’s context memory to these state transitions, the platform builds an immutable record of reliability. If a provider consistently experiences access issues that are confirmed to be client-side errors, their contribution score remains protected. Conversely, if a host repeatedly fails to provide accurate entry manifests, Mia flags future service listings created by that host with a logistics risk notice, adjusting required deposit parameters accordingly.

Known Limitations and Open Questions

While this cycle resolved significant doorstep friction, two structural edge cases remain open:

  1. Sub-Basement Offline Dead-Zones: In deep subterranean service areas (such as underground boiler rooms or concrete parking structures), mobile cellular signals frequently drop out. When a provider cannot establish network connectivity, the localized proof-of-presence token cannot be broadcast to the ledger in real time. We are currently testing an offline cryptographic handoff using Bluetooth Low Energy (BLE) peer-to-peer verification between the client’s and provider’s devices, but this requires both parties to be physically adjacent.
  2. Mid-Task Material Price Fluctuation: If a plumbing repair requires an unforeseen €80 hardware fitting mid-job, updating the escrow currently requires the host to manually approve an adjusted quotation mid-service. In 8% of test cases, host delay in responding to mid-task price updates stalled work in progress. We are evaluating a pre-authorized contingency buffer (up to 15% of total job value) that providers can draw against by submitting scanned material receipts directly to Mia for real-time validation.