Operational detail, without hiding the limits.

Establish the tenant, operating defaults, staff access, driver identities, and least-privilege roles before customer work enters the platform.

Normal path

1. Create the isolated courier tenant and its accountable owner.
2. Configure the operating identity, defaults, hubs, zones, and commercial settings.
3. Invite staff and assign owner, administrator, dispatcher, driver, billing, or viewer access.
4. Link driver users to field profiles and review access before going live.

Self-service onboarding is not yet available. RouteHut enforces tenant-scoped roles and can provision an owner today, but team invitation and membership administration remain operator-assisted.

Publish controlled default or customer tariffs across the courier's service zones without changing prices already quoted or booked.

Normal path

1. Create hubs and bays, then draw effective-dated collection, delivery, pricing, remote-area, branch, or driver-territory zones.
2. Build an inactive default or customer-specific rate card with currency, volumetric divisor, fuel percentage, effective dates, and non-overlapping service, zone, and weight rules.
3. Test representative quote options across actual and volumetric weight, customer-card precedence, zone specificity, minimum charges, fuel, and remote-area surcharges.
4. Activate only a complete non-overlapping tariff; for the next period, duplicate its rules into a new inactive draft and archive retired pricing without altering historical shipment snapshots.

Map-backed zones; inactive configuration; default and customer-specific cards; effective periods; actual and volumetric chargeable weight; service, zone, and weight selection; base, per-kilogram, minimum, fuel, and remote-area charges; guarded activation; terminal archival; full-card duplication; quote options; and shipment pricing snapshots are available. Tiered contract matrices, tax policy, discount and surcharge governance, automatic tariff approval, load-based freight pricing, and pallet rating remain future depth.

Turn labels such as standard, express, or same day into controlled products that pricing, booking, operations, customers, and reporting interpret consistently.

Normal path

1. Define a stable service identity, operating days, booking and collection cut-offs, coverage, and network eligibility.
2. Set the transit target, delivery window, handling constraints, proof requirements, and exception policy.
3. Attach effective-dated pricing and customer eligibility without changing historical bookings.
4. Test representative quotes and bookings, publish the product, and measure execution against the promise captured on each shipment.

Rate rules currently provide normalized service-level labels, quote options derive eligible labels from active customer pricing, and shipments retain the selected service level and pricing snapshot. RouteHut does not yet maintain a first-class service-product catalogue, calendars, cut-offs, transit calculations, customer entitlements, proof policies, commitment snapshots, or computed SLA deadlines.

Define evidence rules once and apply the right collection, delivery, exception, and controlled-handover requirements consistently across staff, driver, and integration channels.

Normal path

1. Create an effective-dated policy for a collection, delivery, failed attempt, return, or controlled handover.
2. Choose required evidence combinations such as recipient or sender name, photo, signature, OTP verification, parcel scans, location, condition, notes, or reason codes, with explicit precedence across service, customer, and handling rules.
3. Test representative work, publish the policy version, and snapshot the resolved requirement onto each eligible shipment or stop.
4. Guide the field user through only the required capture, block incomplete completion, and route an impossible requirement through a reasoned supervisor exception rather than silently weakening it.

Not yet available as configurable policy. RouteHut currently stores one POD per shipment with a recipient name, one proof-type label, optional notes, capture time and location, and at most one attached evidence file; delivery requires only the recipient name and the mobile photo is optional. There is no tenant-, customer-, service-, handling-, or event-scoped proof policy, no required evidence combinations, no effective-dated policy snapshot, no capability negotiation, and no policy-driven completion or override gate.

Create an accountable operational profile, record dispatch constraints, and keep the driver unavailable until the checks required by the courier are complete.

Normal path

1. Verify the person's identity, contact details, employment or contractor relationship, and tenant membership.
2. Create the driver profile as unavailable and record vehicle registration, carrying capacity, and dispatch skills.
3. Review the courier's required licence, training, induction, and supporting evidence before approval.
4. Activate the driver, schedule eligible shifts, then connect an approved field device.

Driver profiles, contact details, active or unavailable status, vehicle registration, capacity, and skill-based dispatch eligibility are available. Staff-managed user linking, licences, training, document evidence, expiry reminders, approval gates, and suspension reasons remain planned compliance depth.

Create one accountable fleet asset, prove that it is legal and suitable for its work, and expose only eligible capacity to planning and dispatch.

Normal path

1. Register the vehicle's stable identity, registration, type, ownership, home depot, and operating dimensions.
2. Record payload and volume capacity, equipment, handling capabilities, and any work restrictions.
3. Verify roadworthiness, licence, insurance, permits, and required evidence with accountable expiry dates.
4. Approve the vehicle for service, assign it to eligible drivers or routes, and make its current capacity visible to dispatch.

Not yet available as a fleet lifecycle. RouteHut currently stores vehicle registration and weight capacity on a driver profile, checks that capacity during planning, and records append-only inspections with registration, odometer, checklist, defects, and safety outcome. It does not maintain an independent vehicle asset, volume or equipment capability, compliance expiry, driver-to-vehicle assignment history, maintenance state, or vehicle eligibility gate.

Bind an installed field app to the right RouteHut host, tenant, driver identity, and durable device record before assigned work reaches the phone.

Normal path

1. Provision the driver membership and linked field profile for the tenant.
2. Install the approved field build and enter the reachable HTTPS RouteHut server origin.
3. Sign in; the app stores rotating credentials in the platform secure store and registers its stable installation identity.
4. Synchronize the released manifest and refresh the same device record idempotently as app metadata changes.

Internal Android field enrolment, host selection, secure authentication, and device registration are available. Formal app-store distribution, staff-managed device inventory, remote revocation, and push-token lifecycle management remain production depth.

Remove a person's ability to act without losing the operational, financial, evidence, or audit history created while they were accountable.

Normal path

1. Inventory the person's tenant memberships, role, active work, driver profile, registered devices, sessions, and owned integration credentials.
2. Reassign live routes, approvals, customer responsibilities, and shared operational ownership before disabling access.
3. Disable the membership or user, revoke token families and devices, and revoke or rotate any exposed API or webhook credentials.
4. Verify that new authentication and command replay are denied, retain attributed history, and record who approved and completed the offboarding.

Authentication already denies disabled users and memberships; sign-out revokes the current session family; administrators can revoke API credentials; drivers can revoke their own devices; and tenant suspension can revoke active sessions. RouteHut does not yet provide staff user and membership administration, administrator-led session or device revocation, consolidated access inventory, ownership transfer, periodic certification, or a complete offboarding command.

Enter the correct courier workspace, continue through short-lived session renewal, and close access cleanly without exposing browser credentials to application storage.

Normal path

1. Enter the courier tenant, email address, and password on the RouteHut staff sign-in screen.
2. Verify active user membership and open only that tenant's authorized workspace and role.
3. Renew an expiring browser session through rotating secure cookies and a CSRF-protected refresh request.
4. Sign out to revoke the current token family, clear browser credentials, and return to the sign-in screen.

Tenant-bound sign-in, secure browser cookies, CSRF protection, automatic session renewal, refresh-token reuse defence, and explicit sign-out are available. Self-service password reset, MFA, SSO, administrator session inventory, remote session revocation, and user-facing sign-in history remain planned security depth.

Create the commercial account, reusable addresses, contacts, notification consent, and the pricing relationship that future work will use.

Normal path

1. Create the tenant-scoped customer account.
2. Add collection and delivery addresses with operational contacts.
3. Record consent for tracking notifications.
4. Associate the applicable rate card and funding arrangement.

Turn a reusable customer location into reviewed coordinates and service-zone context before operations relies on it for pricing, allocation, or navigation.

Normal path

1. Create or update the tenant-scoped address and associate it with the correct customer where applicable.
2. Queue provider geocoding and review the formatted result, confidence, status, timestamp, and coordinates.
3. Correct the source address and retry, or enter a verified latitude and longitude when provider output needs human resolution.
4. Resolve the point against active service, pricing, remote-area, branch, and driver-territory zones before using it operationally.

The address directory, asynchronous Mapbox geocoding, review states, retries, manual coordinates, search and filtering, and zone resolution are available when the provider is configured. Visual map-pin confirmation and tenant-enforced approval before booking remain planned depth.

Let each shipping customer manage its own people, locations, bookings, tracking, proof, and financial documents without granting access to the courier's internal operation.

Normal path

1. Invite a user into one tenant and customer account with an explicit role.
2. Let the customer administrator manage approved users, contacts, and reusable service locations.
3. Quote, book, import, cancel eligible work, and follow shipment progress within that account.
4. Retrieve authorized POD, invoices, statements, and integration credentials according to permission.

A dedicated customer identity, authorization boundary, and portal are not yet available. Today courier staff act on the customer's behalf, recipients use privacy-safe public tracking, and approved system integrations use tenant-issued scoped credentials.

Choose an explicit funding policy for each customer and preserve every reservation, release, settlement, and correction as auditable financial history.

Normal path

1. Set the customer billing mode to invoice or prepaid.
2. For invoice billing, configure the currency, credit limit, payment terms, and active or hold status.
3. For prepaid billing, configure a currency-specific wallet and reconcile a confirmed bank top-up using a stable reference.
4. Book against available funding, then settle, release, refund, or reverse value through controlled commands.

Staff-confirmed top-ups and wallet and credit controls are available. Automated payment-gateway top-ups and reconciliation imports remain planned.

Compare eligible delivery services, preserve the selected commercial basis, and turn a reviewed draft into funded operational work.

Normal path

1. Select the customer, collection and delivery addresses, quote and service dates, and parcel weights and dimensions.
2. Calculate every eligible service option and compare the price-ordered totals, actual and volumetric weight, resolved zones, and itemized charges.
3. Select an option and create a draft; RouteHut recalculates and freezes its tariff, rule, service, zone, weight, surcharge, and quote-date basis as the shipment pricing snapshot.
4. Review and book the draft. RouteHut applies configured credit or prepaid controls atomically, then appends the booked milestone and integration event.

Staff service comparison, rated or unrated draft creation, funding-aware booking, and scoped external quote and booking APIs are available. A persisted customer quotation with customer-facing presentation, explicit acceptance, versioning, expiry, and conversion history remains planned.

Create one reviewed draft in the staff workspace or accept hundreds of independent partner orders without making an API request wait for the whole batch.

Normal path

1. Create a single draft through staff entry, or use tenant-bound API credentials with shipment write access.
2. For bulk work, submit 1 to 500 JSON rows within 5 MiB, each with a unique partner row key, under one request idempotency key.
3. Receive an opaque import identity immediately while background processing validates and creates each draft in stable row order.
4. Poll queued, processing, or completed counters, then traverse the keyset-paginated row feed for each created shipment number or partner-safe failure.

The released bulk contract is asynchronous JSON intake limited to 500 rows and 5 MiB, and it creates drafts only. CSV or XLSX upload, downloadable correction files, in-place failed-row repair, bulk booking, labels, and route assignment remain separate or planned workflows.

Give every physical parcel one durable identity, print it in forms people and scanners can read, and verify the applied label before custody changes.

Normal path

1. Reconcile the packed parcel count, then retain a customer identifier or allocate a tenant-unique RouteHut parcel number; allocate an SSCC only where the configured trading process uses GS1 logistic labels.
2. Render the parcel identity both as legible text and a machine-readable symbol, with the shipment, service, routing, and handling information permitted by the tenant's label template.
3. Print and apply the label, then scan it back against the expected shipment before releasing the parcel for collection.
4. At collection or hub receipt, scan each physical item again and accept custody only when its identity and expected work agree.

RouteHut currently creates tenant-unique parcel numbers, defaults a blank barcode to the parcel number, preserves a supplied barcode, exposes both values to staff, and resolves hub scans by either value with retry-safe scan events. Label rendering and templates, print and reprint history, GS1 identifier validation, pack verification, and collection-side parcel reconciliation remain planned.

Offer branch counters, partner shops, and lockers as convenient handover locations while preserving the same parcel identity, tracking history, and accountable custody as a door service.

Normal path

1. Select a currently eligible point using its stable identity, location, opening hours, cut-off, capacity, accessibility, supported parcel sizes, and available drop-off or collection services.
2. For sender drop-off, scan the booking and every parcel, validate condition and eligibility, record acceptance into the point's custody, and issue a receipt.
3. For recipient collection, scan arrival into the destination point, start the configured holding period, and notify the recipient with the point details, deadline, and a short-lived collection credential.
4. At the counter or locker, verify the credential, permitted collector, and parcel; record release proof and the custody scan before marking the handover complete.

Not yet available. RouteHut has tenant-scoped internal hubs and bays, append-only parcel scans, current parcel custody, manifests, tracking, notifications, and POD. It has no public service-point directory or eligibility search, point availability or reservation, counter roles, partner or locker integration, sender receipt, pickup authority, holding-period automation, delegated collection, or service-point handover commands.

Turn fragile, high-value, temperature-controlled, dangerous-goods, or restricted-handover needs into enforceable controls that follow the goods from acceptance to final disposition.

Normal path

1. Select a versioned handling profile and declare the goods, quantity, value or risk class, required temperature or condition limits, recipient controls, and supporting documents before acceptance.
2. Validate prohibited or restricted goods, packaging and labelling, service and route eligibility, price, approvals, and the regulations configured for the operating region.
3. Snapshot the accepted controls, then allocate only trained people and qualified vehicles, containers, facilities, and service paths; present current instructions at every custody handoff.
4. Scan identity and capture the required seal, condition, temperature, custody, and recipient checks until compliant delivery, return, quarantine, or another approved final outcome.

Not yet available as a special-handling or compliance workflow. RouteHut currently records shipment priority and normalized free-form required driver skills; driver recommendation, assignment, and route planning check those skills, while manual assignment can record an override reason. It has no typed goods or handling catalogue, regional policy rules, declaration or document approval, expiring qualifications, vehicle or container capabilities, condition monitoring, compliance-safe override policy, quarantine custody, or restricted-recipient proof.

Request a correction or in-network action without rewriting history, and keep the original instruction in force until the team holding the goods accepts the change.

Normal path

1. Authenticate the requester, record the requested change and reason, and bind it to the shipment's current version, state, and custody owner.
2. Determine which tenant- and service-specific actions remain eligible: correct before handoff, reschedule, hold for collection, redirect, or return; then revalidate address, service, handling, risk, timing, and price.
3. Apply an accepted pre-handoff change as a new booking revision and refresh affected route, financial, and notification work. After handoff, send a pending instruction to the current custody owner and do not promise the outcome until it is acknowledged.
4. Append the accepted, rejected, expired, or withdrawn result, its effective time, the resulting route or return action, charges, and notifications to affected parties.

Not yet available as amendment or interception. RouteHut currently supports immutable draft creation, booking, idempotent pre-handoff cancellation, and explicit lifecycle transitions. Staff and external shipment routes expose no update command, and the product has no booking revision, hold, redirect, return instruction, custody acknowledgement, request expiry, or accepted-change repricing workflow.

Stop work before physical or dispatch handoff, preserve the cancelled record, and reverse its pending financial effect exactly once.

Normal path

1. Open the shipment, confirm the customer and reference, and verify that it remains a draft or an untouched booking.
2. Record the customer or operational reason, then confirm the irreversible cancellation instead of deleting the booking.
3. Cancel through the staff workspace or send an external request with the shipments:write scope and a stable idempotency key.
4. Atomically mark the shipment cancelled, void pending charges, restore prepaid value with compensating ledger entries, and publish the cancellation for tracking and integrations.

Available for staff and external integrations before operational handoff. RouteHut enforces draft or untouched-booked state, handoff and invoicing gates, and repeat-safe financial reversal. A cancellation reason remains optional, and tenant-specific cut-offs, approval rules, fees, customer self-service, and cancellation of an external carrier label or scheduled pickup remain planned.

Turn a standing customer agreement into individually controlled shipment drafts without repeatedly entering the same service pattern or committing work too far ahead.

Normal path

1. Define an effective-dated agreement with the customer, timezone, locations, service, collection and delivery windows, parcel forecast, handling needs, recurrence, holidays, cut-off, and end conditions.
2. Preview upcoming occurrences and generate independent shipment drafts only inside the tenant's planning horizon, using one stable occurrence key to prevent duplicates.
3. Revalidate the current address, service calendar, rate, handling eligibility, and available capacity for every occurrence before it can be booked and dispatched through the normal workflow.
4. Pause, end, or version the agreement for ungenerated work. Handle an already generated draft through ordinary amendment or cancellation so released and completed shipment history never changes.

Not yet available. RouteHut creates one-off staff and external shipment drafts and accepts idempotent asynchronous JSON imports of up to 500 rows within 5 MiB. Those paths produce dated, independently priced shipments but provide no recurring agreement, calendar or timezone rules, occurrence preview, planning-horizon generator, stable occurrence identity, pause or future-version command, or per-occurrence exception queue. Solid Queue recurrence supports internal jobs only; it is not a customer schedule.

Publish near-term availability and protected breaks so dispatch can test planned work against the roster without presenting a schedule as proof of hours worked.

Normal path

1. Select an active driver and schedule a bounded start and end time.
2. Add protected breaks and reject missing, reversed, out-of-shift, or overlapping break periods.
3. Where a matching shift exists, exclude the driver when the planned departure falls during a break or outside that shift.
4. Add overlapping break time to the estimated route finish and block release when the planned work exceeds the matched shift.

Individual scheduled shifts and breaks can be created and viewed in a 14-day feed today; the driver directory shows each driver's earliest upcoming shift. Dispatch applies departure, break, and estimated-finish constraints when a matching shift exists, but unscheduled drivers remain eligible. This is planning data, not a clock-in, duty, driving, break, or rest log. Recurring roster templates, shift-overlap detection, editing or cancelling an existing shift, roster-required availability, absence and leave, overtime approval, driver acknowledgement, and jurisdiction-specific hours-compliance reporting remain planned depth.

Turn eligible work into auditable, driver-linked route plans while keeping dispatch in control of allocation, stop order, and release readiness.

Normal path

1. Choose a service date and review eligible collection or delivery candidates, excluding conflicting active route stops and assignments.
2. Build a manual route or preview an all-or-nothing allocation across active drivers using priority, territory, travel time, shift availability, required skills, existing load, and weight capacity.
3. Sequence geocoded stops with road-network optimization or a deterministic fallback while preserving collection before delivery for paired work.
4. Review sequencing and constraint results, correct any blocker, then release the unchanged planned route to its driver.

Manual route building and automatic allocation of booked collection-and-delivery work are available. Mapbox v1 provides road-duration sequencing for at most 12 waypoints; deterministic sequencing and route metrics are used when that provider is unavailable, while missing stop coordinates block optimization. Current service-window checks compare the service date and planned departure with each window, but do not yet predict arrival and service time at every stop. Capacity is weight-based. Multi-dimensional capacity, per-stop service duration, predicted arrival windows, live traffic re-optimization, route versioning, and supervised release overrides remain planned depth.

Let each courier choose whether employed drivers receive a dispatch instruction directly or whether a driver or subcontractor must accept a time-bounded offer before departure.

Normal path

1. Freeze a versioned offer and notify the driver of its expected start, stop count, service area, duration, vehicle, handling constraints, and response deadline.
2. Let the driver accept that exact version or decline it with a structured operational reason.
3. On acceptance, claim the work once and continue into inspection, loading, and route-start readiness.
4. On decline, timeout, or material plan change, invalidate the offer and return the work visibly to dispatch for reassignment without presenting it as started.

Planned. Staff can assign a booked shipment to one active driver, reject unavailable drivers, and record a reasoned skills or weight-capacity override. Separately, a route plan names a driver and its released or in-progress manifest becomes visible to that driver's linked mobile account. The shipment assignment model reserves an accepted status, but no driver API or app action can enter it; shipment assignments and route ownership do not form one versioned offer, and route start has no acknowledgement gate. Response deadlines, decline reasons, offer invalidation, driver notification, and a dispatcher recovery queue are not available.

Bring the released route, roster constraints, and a recorded pre-trip check together before departure, with a supervisor retaining the safety decision until policy gates are automated.

Normal path

1. Release only a sequenced route whose active driver, required skills, planned shift, service windows, pickup-before-delivery order, and weight capacity pass the current dispatch checks.
2. Open the released manifest on the linked driver account and confirm the intended work and vehicle before movement.
3. Record the vehicle registration, optional odometer, notes, and every v1 pre-trip check; classify the result as safe, defects reported, or unsafe to operate.
4. After the operation's authorized safety decision, start the route online and enable foreground location sharing where required.

Available as a manual, configurable readiness process rather than an automated clearance gate. The current v1 inspection covers brakes, lights, tyres, mirrors, fuel, and bodywork and is retry-safe offline; staff can inspect the latest pre- or post-trip result for each driver. RouteHut has no managed vehicle or route-to-vehicle record, does not verify the entered registration against the driver's listed vehicle, and does not require a fresh pre-trip result before showing Start route. Inspection cadence, tenant-specific checklists, structured defect capture in the mobile form, repair and supervisor clearance, and an unsafe-result route-start block remain planned depth.

Carry the released stop sequence onto the driver's phone, identify the next collection or delivery, and hand its approved coordinates to road navigation.

Normal path

1. Open the synchronized route manifest and review its sequence, handled count, exceptions, and first non-terminal stop highlighted as next.
2. After route start, select Directions on any planned or arrived stop whose address has approved coordinates.
3. Launch Google Maps with that latitude and longitude as the destination and explicitly request driving navigation.
4. Return to RouteHut at the stop, record arrival and the collection, delivery, or exception outcome, then continue through the manifest.

Ordered manifests, advisory next-stop guidance, offline route visibility, reviewed per-stop coordinates, and a Google Maps driving-navigation handoff are available. Directions opens only while the route is in progress and the stop remains actionable. RouteHut does not embed turn-by-turn navigation, download offline maps, supply Google place or entrance identifiers, enforce strict stop order, recalculate the operational sequence from live traffic, or receive navigation telemetry from Google Maps; a driver can still choose a later actionable stop.

Give an assigned driver the minimum contact and instruction context needed to complete the next stop without exposing recipient data beyond the work that requires it.

Normal path

1. Attach current stop-specific access instructions separately from a purpose-specific collection or delivery contact, including any channel restriction or validity window.
2. Synchronize only the details needed by the assigned driver for actionable work, retaining them offline under the same device, tenant, and assignment boundary.
3. Let the driver call or message through an operator-approved direct or masked channel, follow the instruction, and record arrival or the resulting stop outcome.
4. Withdraw routine device access when the assignment changes or work becomes terminal while retaining the instruction snapshot and minimum auditable communication outcome required by policy.

Not yet available as a controlled field workflow. Address records can hold a contact name, phone, and email for staff and external API use, but the current driver manifest exposes only the stop address, approved coordinates, customer name, parcel count and declared weight, plus generic route-stop metadata with no defined instruction contract. It does not provide dedicated sender or recipient contacts, structured stop instructions, one-tap communication, contact masking, communication outcomes, expiry, or assignment-scoped disclosure and removal.

Turn a failed inspection into owned safety work, protected dispatch decisions, repair evidence, and an authorized return to service.

Normal path

1. Identify the vehicle and classify the reported defect; place it visibly off road when the defect may affect safe operation and block new release, assignment, or route start.
2. Open an owned defect case with reporter, accountable assessor, severity, evidence, repair target, and every affected route or assignment.
3. Reconcile work already in progress and replan it onto a qualified substitute vehicle when needed, preserving the original allocation, custody, and reason for change.
4. Record assessment and rectification evidence, then require the authorized person to accept the repair or declare it unnecessary before a fresh roadworthy state returns the vehicle to service.

Not yet available as a defect-resolution workflow. RouteHut currently derives safe, defects-reported, or unsafe-to-operate status from an append-only pre- or post-trip inspection, publishes the result, and shows the latest result and details to staff. Mobile now describes a safe result only as no defects reported, not as operational clearance. RouteHut does not yet maintain an independent vehicle or vehicle-off-road state, accept a separate in-service defect report, block route release, assignment, or start from an unsafe result, manage assessment and repair work, allocate a substitute vehicle, or record authorized return to service.

Review active-route, stop, workload, inspection, and last-known driver-location snapshots while the delivery day is still in progress, then act on explicit exceptions.

Normal path

1. Filter active routes by service date, driver, status, or search term and review each route's completed, outstanding, and exception counts.
2. Use the loaded snapshot, select Refresh on demand, or return focus to the staff window to fetch current values; then open the route preview and ordered stops to confirm planned movement, current stop states, service windows, and shipment identity.
3. Cross-check the driver directory for last accepted position and timestamp, active workload, and latest vehicle-inspection outcome without assuming that an open screen is continuously polling.
4. Apply only a valid in-progress stop outcome or move the work into its delivery-failure, return, redelivery, or customer-enquiry path.

Initial, on-demand, and focus-triggered route, workload, inspection, and last-location refresh; route preview; and authorized stop management are available without background polling. This is a request-driven operational snapshot, not continuous GPS tracking. A scalable push-backed command view, unified live dispatch map, explicit location-freshness classification, geofence or delay alerts, continuously recalculated ETAs, and dynamic in-progress reoptimization remain planned depth.

Protect people, goods, and customer promises when a breakdown, incident, illness, or device failure prevents an in-progress route from continuing.

Normal path

1. Confirm driver and public safety, record the disruption's time and exact position, secure the vehicle and load, assign an incident owner, and decide whether the route may resume or needs rescue.
2. Freeze further execution at an explicit cut-off, ingest or account for pending offline commands, and reconcile the last accepted stop outcomes with every parcel or handling unit physically in custody. Completed and failed work stays on the original route.
3. Choose a safe handover location and a suitable rescue driver and vehicle, then record item-level custody transfer and validate skills, shift, capacity, handling controls, and service-window impact.
4. Create a linked successor route for only the reconciled remainder, release its exact version to the rescue driver, and communicate revised promises or unresolved exceptions to operations, customers, and recipients.

Not yet available as a controlled rescue workflow. RouteHut exposes request-driven active progress, last-known driver location, idempotent offline stop outcomes, and pre-start route cancellation today. It cannot pause or deactivate an in-progress route, reconcile an incident cut-off, transfer outstanding custody, split or reassign remaining stops, link a successor route, or resume the original route. Active route stops also prevent duplicate replacement planning; marking a stop skipped closes that route exception but does not transfer goods or create recovery work.

Protect goods, people, and chain of custody when damage, leakage, tampering, loss, or a handling-condition breach is discovered before final handover.

Normal path

1. Protect people and the environment first: stop unsafe handling, isolate the vehicle or area when necessary, identify every affected parcel or handling unit, and record the discovery time, place, custodian, and immediate action.
2. Open an owned incident, snapshot the last accepted custody state, classify the condition and suspected cause, and capture packaging, contents, seal, location, temperature or handling data, and photographic evidence without advancing a shipment milestone.
3. Place the affected goods and retained packaging under an explicit hold in a controlled location; block loading, manifesting, delivery, or release while the accountable assessor determines inspection, repacking, partial release, return, salvage, disposal, and any safety or regulatory response.
4. Record an authorized disposition and each physical custody movement, release only explicitly cleared goods, notify the permitted parties, and open a linked commercial claim when loss or liability needs separate resolution.

Not yet available as an owned incident lifecycle. At a hub, RouteHut can append an idempotent exception scan with a damaged, missing, security-hold, or other reason; this publishes a shipment exception, appears in recent scan history and aggregate analytics, sets the parcel projection to exception, and leaves its last custody projection unchanged. RouteHut does not capture incident evidence, open or assign a case, distinguish an operational hold from a claim, quarantine an item or location, block its next scan or route action, manage assessment and authorized disposition, or reconcile related communication and claims. POD photos and notes belong to delivery proof today, not to a goods incident.

Guide the assigned driver to a collection stop, record arrival and basic completion, and reconcile the shipment transition after temporary network loss.

Normal path

1. Synchronize the assigned released route, start it while connected, and use the approved collection address for navigation.
2. At the sender, select Mark arrived; the mobile app saves that update locally and shows only the assigned shipment and stop details for confirmation.
3. After physically taking the expected goods, select Complete collection. The app records a distinct client event and immediately reflects the pending completion on the device.
4. Replay queued arrival and completion commands in order. The server verifies the assigned driver and in-progress route, then atomically completes the stop, marks the shipment collected, publishes its tracking event, and returns the reconciled manifest.

Basic assigned-route collection completion and idempotent offline replay are available. Route start still requires connectivity, and mobile requires arrival before showing Complete collection. Completion stores client time and source metadata, not event-specific GPS; separately shared driver location is not collection evidence. The server changes existing parcel projections to scanned in, but the driver does not scan or reconcile individual parcels and no parcel-custody record, sender acknowledgement, signature, photo, receipt, shortage, damage, or failed-collection outcome is created. Those controls remain planned chain-of-custody depth.

Establish exactly what entered courier custody, in what condition, and with whose acknowledgement before the driver leaves the sender.

Normal path

1. Load the versioned collection requirements for this customer, service, goods profile, and stop before work begins, including the expected items and evidence that policy requires.
2. Scan each parcel or handling unit and reconcile the actual identity, count, weight, packaging, and condition against the booking before accepting it into custody.
3. Let both parties review the accepted and rejected goods, then capture the sender or authorized agent plus any required signature, photo, notes, trusted timestamp, and event-specific location.
4. Atomically complete the collection, create first-class proof of collection and custody acceptance, retain queued evidence through idempotent offline replay, and issue an immutable collection receipt through the authorized channel.

Not yet available. The current mobile collection command creates the completed route stop and shipment.collected transition with client time, source metadata, and a retry-safe client event ID. It does not capture event-specific location, scan or reconcile individual items, create parcel-custody records, identify the sender, enforce a collection-proof policy, retain signature, photo, or notes, issue a receipt, or record an acceptance discrepancy. The existing one-per-shipment ProofOfDelivery requires a recipient and is created only by the delivered transition, so it neither represents proof of collection nor supports both collection and delivery evidence as currently modelled.

Explain why custody was not established, notify the right people, and reschedule the work without presenting unavailable goods as collected.

Normal path

1. After reaching the collection, select a tenant-configured failure reason that applies to that stop and complete any reason-specific contact attempt, notes, photo, timestamp, or location requirement.
2. Submit one idempotent failed-attempt event. RouteHut closes only that collection stop, leaves the shipment awaiting collection, and does not create parcel acceptance or a custody transfer.
3. Route the exception to an accountable dispatcher, who reviews the evidence and reason-specific playbook before correcting the address, time window, goods readiness, parcel details, or commercial disposition.
4. Cancel the booking or create a linked collection attempt with its own service window, assignment, and route history; notify consented contacts and retain the original attempt.

Not yet available. The driver app exposes Report delivery issue only for delivery stops. Although route stops can store a generic failed status, the transition service rejects every failed collection with 422 before changing the planned stop or booked shipment and before creating a route-stop execution event or outbox event. RouteHut has no collection-specific reason catalogue, evidence rules, exception owner, retry-attempt link, rescheduling command, failed-pickup notification, or attempt-fee decision; the existing delivery-failure reasons and shipment.failed transition are delivery-specific and must not be reused as collection custody history.

Record where each identified parcel was received, staged, dispatched, and received again without replacing its append-only movement history.

Normal path

1. At receipt, scan the parcel number or barcode into the selected hub and optionally its active bay; for an inter-hub arrival, select the closed inbound transfer manifest.
2. RouteHut validates the shipment state, hub, bay, manifest direction, manifest membership, and prior custody, then appends the scan with its occurrence time and unique client event ID.
3. Add at-hub parcels to a draft manifest, review its frozen membership when closed, and scan each expected parcel out at the origin to place it in transit against that manifest.
4. At the destination, scan each parcel in against the same closed transfer manifest, review rejected outcomes and discrepancies, and stage accepted parcels in the destination hub.

Parcel-level scan in, return receipt, bay assignment, reasoned exception, closed-manifest scan out, destination receipt, idempotent replay, current-custody lookup, and discrepancy review are available in the staff application and API. Mutations are limited to owners, administrators, and dispatchers; there is no dedicated hub-operator role yet. RouteHut does not yet model a linehaul vehicle or journey, dock loading and unloading, seal control, manifest departure and arrival states, handling-unit aggregation, whole-load expected-versus-actual closeout, offline scanner buffering, or scanner hardware integration.

Submit up to 100 parcel identifiers under one hub movement context and keep accepted, replayed, and rejected outcomes separate.

Normal path

1. Select scan in, return receipt, scan out, bay assignment, or exception and provide the bay, closed manifest, or reason required by that movement.
2. Enter or paste one barcode or parcel number per line. The staff screen trims blanks, removes repeated identifiers, and accepts between 1 and 100 unique values.
3. Submit one shared occurrence time with a newly generated client event ID for every identifier; RouteHut validates and commits each parcel independently rather than rolling back the accepted remainder.
4. Review recorded, already-recorded, and rejected counts, investigate the rejected identifiers, and reconcile any open custody discrepancies before the next movement.

The staff scan station and API support bounded lists of up to 100 identifiers across the five hub scan types. The browser shows aggregate counts and details for at most the first five rejected items. It creates fresh event IDs and one submission timestamp each time, so a manual browser retry is not a preserved idempotent replay or a record of each physical scan time. Continuous trigger capture, durable scan sessions, offline buffering, device attribution, audible, haptic, or LED feedback, handheld integration, exception export, and cage, bag, pallet, or wave-level aggregation remain planned throughput controls.

Move received parcels into a named working bay while keeping their physical location visible and every reassignment auditable.

Normal path

1. Configure the hub's active working bays for the operation's current sort and staging process.
2. Select the intended bay and scan one parcel or submit a bounded list of parcel identifiers.
3. Validate that each parcel is currently held at the selected hub, then append the bay-assignment scan without changing its shipment milestone.
4. Review current custody by bay, correct rejected items separately, and use the staged population to prepare the next manifest or movement.

Manual, tenant-configured bay assignment is available for individual parcels and bounded batches, with active-bay and current-hub validation. RouteHut does not yet recommend a destination bay from postcode, service, route, manifest, cut-off, capacity, or handling rules, nor does it manage conveyor or sortation hardware, chute capacity, or a wave closeout.

Stop an invalid physical movement from corrupting current custody, investigate the parcel's recorded location, and close the exception without rewriting scan history.

Normal path

1. Attempt the scan with a unique device event ID; RouteHut validates the parcel, eligible shipment state, hub, bay, manifest, and current custody.
2. Reject a contradictory movement, preserve the existing custody projection, and raise an open discrepancy for the known parcel and attempted scan.
3. Review open discrepancies alongside parcel identity, shipment, scan reason, recent scan activity, manifest membership, and current custody.
4. Perform any valid corrective scan separately, then have an owner, administrator, or dispatcher close the discrepancy with a required resolution note.

Known-parcel custody conflict detection, per-item batch outcomes, open and resolved filtering, role-controlled resolution, append-only scan history, required notes, audit records, and resolution events are available. Assigned exception ownership, SLA aging, structured resolution codes, evidence attachments, notifications, and scan-again guidance remain planned depth.

Compare what the system says is in each bay with what operators can physically find, then give every missing, unexpected, or aging parcel an owned outcome.

Normal path

1. Open a time-bound sweep for the hub or selected bays using the recorded custody population as the expected inventory.
2. Scan each parcel physically present, preserving already-counted responses without creating false movement events.
3. Close the count and compare expected, found, unexpected, missing, misplaced, and over-dwell parcels.
4. Correct a known location with an append-only bay scan, assign unresolved variances for investigation, and close the sweep only when every variance has an accountable disposition.

Not yet available as a counted reconciliation workflow. RouteHut currently provides a page-bounded current-custody list by hub, optional bay filtering, parcel, barcode, or shipment search, and the last custody event. It does not yet snapshot expected inventory, capture non-movement count scans, calculate dwell thresholds, manage sweep progress, classify variances, assign investigations, or require closeout approval.

Group parcels into a scannable bag, cage, tote, or roll container so the network can move one controlled handling unit while preserving every child's identity and custody.

Normal path

1. Create a uniquely barcoded container with its type, origin, destination, capacity, and intended movement.
2. Scan eligible parcels into the open container, rejecting custody, route, handling, duplicate-membership, or capacity conflicts independently.
3. Reconcile the contents, close the immutable membership snapshot, apply and record the seal, then add the container to the outbound manifest.
4. Scan the closed container through departure and receipt, project accountable custody to its children, then break it at the authorized destination and reconcile every expected parcel before reuse or retirement.

Not yet available. RouteHut currently models parcel identities, per-parcel custody, hub bays, bounded parcel scan batches, and manifests whose items are individual parcels. It has no reusable container aggregate, parent-child or nested handling-unit membership, container barcode and capacity, seal lifecycle, container-level manifest item, projected child custody, or break-and-reconcile workflow.

Turn a working list of eligible parcels into an immutable expected load for outbound or inter-hub scanning.

Normal path

1. Create a uniquely numbered outbound or transfer manifest from the origin hub, naming a destination hub for a transfer.
2. Add eligible parcels individually or in a bounded batch of up to 100 identifiers, and review each added, already-present, or rejected outcome.
3. Remove mistakes while the manifest remains draft and reconcile its visible item list before release.
4. Close the non-empty manifest to freeze membership, then use that expected load when parcels are scanned out and, for a transfer, received at the named destination.

Outbound and transfer manifests, individual and bounded batch membership, draft correction and cancellation, non-empty closure, immutable closed contents, and subsequent manifest-validated scan-out are available. Manifests are not yet assigned to a scheduled linehaul leg, local route, vehicle, driver, carrier, departure slot, seal, or printable transport document, and they do not yet provide whole-load expected-versus-actual closeout.

Move a controlled load between depots while preserving exactly what was expected, what departed, what arrived, and who owns every discrepancy.

Normal path

1. Select the origin and destination hubs and create the transfer manifest for the intended departure.
2. Add eligible parcels, resolve membership conflicts, and close an immutable expected-load snapshot.
3. Assign the linehaul movement, scan each parcel out against the closed manifest, and record departure custody.
4. Scan the load into the named destination, reconcile missing or unexpected goods, then release received parcels into destination sorting and separately planned local delivery rounds.

Transfer manifests with tenant-safe origin and destination hubs, immutable contents after closure, validated scan-out and destination scan-in, current custody, idempotent bounded batches, and discrepancy records are available. RouteHut does not yet maintain a scheduled linehaul leg, carrier or vehicle assignment, seal control, departure and arrival status, transfer ETA, or whole-load closeout.

Extend capacity or coverage through an approved transport partner while retaining a controlled offer, custody chain, service outcome, evidence, and payable amount.

Normal path

1. Select eligible work and an approved carrier service with the required coverage, capacity, compliance, and agreed rate.
2. Issue a versioned tender containing the operational requirements and acceptance deadline; record the carrier's acceptance before allocating the work.
3. Release only the necessary shipment and stop data, transfer custody at handover, and ingest milestones, exceptions, and proof through controlled partner access or staff operations.
4. Reconcile every allocated item as delivered, failed, returned, or unresolved, then compare the accepted rate and adjustments with the carrier charge before customer billing closes.

Not yet available. RouteHut currently assigns released routes and shipment work to tenant-owned driver identities and supports external API credentials, webhooks, manifests, custody events, POD, and billing records. It does not yet maintain a carrier master, qualification and compliance, service or rate agreements, tender and acceptance lifecycle, scoped subcontractor workspace, carrier custody handover, payable reconciliation, or partner scorecard.

Prove that the parcels physically leaving the hub match the released route, assigned driver, and vehicle before field execution starts.

Normal path

1. Open the released route and its expected outbound load against the assigned driver and vehicle.
2. Scan each parcel or handling unit into the vehicle and validate identity, route membership, custody, and capacity.
3. Resolve missing, unexpected, duplicate, damaged, or misrouted items; require an authorized reason for any controlled short load.
4. Close an immutable load snapshot, record the departure seal or handover where required, transfer custody to the driver, and permit route start.

Not yet available as a route departure workflow. RouteHut currently supports draft and closed outbound or transfer manifests, bounded parcel batches, scan-out against a closed manifest, custody projections, and discrepancy resolution. Manifests are not yet linked to a route, driver, or vehicle, and route start does not enforce a reconciled physical load.

Apply an explicit OTP or identity policy when a name, photograph, or signature alone is not sufficient authority to transfer custody.

Normal path

1. Apply the versioned verification policy at booking, including the permitted method, recipient authority, attempt limits, and approved fallback.
2. Create a shipment- and attempt-bound challenge, store only its protected verifier, and send the one-time code to the authorized recipient through an approved channel.
3. At the stop, let the driver validate the presented code or record the minimum identity-check result before exposing the completion action.
4. On successful verification, capture the required POD and transfer custody without retaining the raw code or unnecessary identity-document data.

Not yet available as recipient authentication. RouteHut's proof contract accepts an otp proof-type label, and staff can record that label on a POD, but the platform does not generate or deliver one-time challenges, store protected verifiers, enforce expiry or attempt limits, validate a code in the driver app, manage identity-check policy, or gate delivery completion on successful verification.

Execute a local delivery round and complete each stop with recipient details, photo or signature evidence, location, and retry-safe synchronization.

Normal path

1. Confirm arrival and select the delivery outcome.
2. Capture recipient details and required evidence.
3. Review the photo or signature before submission.
4. Upload evidence and complete delivery idempotently.

Catch unreadable, incorrectly framed, privacy-sensitive, or location-inconsistent proof while the handover can still be verified or photographed again.

Normal path

1. Guide the driver to frame the parcel or handover clearly without capturing unrelated sensitive information.
2. Check focus, exposure, orientation, file integrity, and policy-required metadata on the device; crop, rotate, or retake before submission where needed.
3. Compare capture time and location with the stop and flag material inconsistencies for an explicit decision.
4. Accept usable proof or send a reasoned exception to supervised review or recollection while preserving the original evidence.

Not yet available as a quality workflow. The driver app currently captures or selects a photo, previews its dimensions, supports retake and removal, preserves it for offline retry, records recent location, and enforces a 10 MiB limit. Automated image checks, guided crop or rotation, location-consistency policy, and staff approval or rejection remain to be built.

Record exactly which parcels or handling units the recipient accepted and keep every short, damaged, refused, or missing unit under explicit custody and recovery.

Normal path

1. Scan or confirm every expected parcel or handling unit at the stop.
2. Record an accepted, short, damaged, refused, or missing outcome and supporting evidence for each item.
3. Capture recipient proof for the accepted subset and close the attempt as partial rather than fully delivered.
4. Keep the remainder in custody for redelivery, return, investigation, claim, and any controlled billing adjustment.

Not yet available. RouteHut's current delivery transition marks every parcel delivered and stores one shipment-level POD, so a partially accepted consignment must not be completed through the existing command.

Preserve why the attempt failed and keep the shipment visible for an operational decision instead of presenting it as delivered.

Normal path

1. Select a structured failure reason and add useful notes.
2. Capture supporting location or evidence where policy requires it.
3. Synchronize the failed attempt and alert operations.
4. Decide whether to reassign, reschedule, return, or resolve the exception.

Failure capture is available. Richer tenant-governed redelivery and return orchestration continues to mature.

Bring failed goods back under hub custody, reconcile every parcel, and create a fresh delivery attempt without erasing the original failure.

Normal path

1. Retain the failed stop and its reason as completed history.
2. Scan every returned parcel into the receiving hub and manifest.
3. Confirm the shipment is eligible only after custody is reconciled.
4. Release a new route and complete the renewed delivery attempt.

Failure, hub return, and controlled redelivery are available; the permitted reason codes and recovery choice remain tenant-governed.

Create a controlled reverse movement from recipient to merchant or return facility, linked to the original order without rewriting its completed delivery.

Normal path

1. Create a return request linked to the original shipment or as a standalone movement.
2. Validate eligibility, collection window, item identity, and return destination.
3. Collect and scan the returned goods with condition evidence.
4. Track custody to the merchant or facility and record receipt or disposition.

Not yet available. Current return scanning covers undelivered goods after a failed attempt; customer-requested reverse logistics needs its own authorization, pricing, collection, and receipt lifecycle.

Finish the operating day only after every stop, parcel, exception, returned item, and vehicle concern has an accountable outcome.

Normal path

1. Synchronize all queued stop, POD, location, and inspection updates before accepting the route summary.
2. Reconcile every planned stop and parcel against delivered, failed, returned, transferred, or explicitly missing custody.
3. Scan returned goods into the hub, hand over documents or controlled items, and record a post-trip vehicle inspection and odometer.
4. Assign every discrepancy to a recovery workflow, then let the supervisor accept closeout and release the driver and vehicle.

Not yet available as an operational closeout. RouteHut automatically marks a route completed and emits a completion event when all stops become terminal, while route and performance views expose that result. The mobile app currently records only pre-trip inspections; return reconciliation, post-trip inspection, unresolved-custody gating, and supervisor sign-off remain to be built.

Answer “where is this shipment?” from the same operational record used by dispatch, hubs, drivers, tracking, proof, and billing.

Normal path

1. Search by shipment number, customer, status, service area, or active driver and open the matching shipment.
2. Confirm the latest state, collection and delivery plan, assigned driver, parcel identities, and current operational handoff.
3. Read the append-only tracking chronology and inspect POD, charge, or public-tracking details relevant to the enquiry.
4. Share the privacy-safe tracking link or explain the next action; route a real discrepancy into the appropriate exception, redelivery, dispute, or claims workflow.

Shipment search, detail, tracking, assignment, parcel, charge, POD, and public-link review are available. A formal customer-service case, conversation log, owner, response SLA, and escalation queue are not yet available.

Turn a complaint or complex enquiry into accountable work with one owner, a complete conversation, clear response commitments, and an auditable outcome.

Normal path

1. Verify the requester and capture the issue from an authorized channel without exposing another customer's shipment.
2. Link the relevant shipment, POD, invoice, notification, or route evidence; classify priority, category, and response SLA.
3. Assign an owner, record customer-visible and internal communications, and coordinate operational, claims, or finance actions.
4. Confirm the resolution, notify the requester, close with a reasoned outcome, and reopen the same case if the complaint recurs.

Not yet available. RouteHut currently provides tenant-scoped shipment search, tracking chronology, POD, notification, billing, exception, and audit records needed to investigate an issue, but it has no case aggregate, conversation log, ownership queue, response SLA, escalation, or reopen lifecycle.

Share a privacy-safe tracking page and consent-aware notifications derived from the operational record.

Normal path

1. Issue an opaque public tracking token.
2. Send tracking communication only to an opted-in contact.
3. Project customer-safe milestones from internal events.
4. Present delivery completion and authorized POD summaries.

Contact only the people who have agreed to receive operational updates, honour withdrawal before future milestones, and keep delivery history separate from current preference.

Normal path

1. Verify the contact and record an explicit operational-notification choice for the permitted purpose and channel.
2. Validate the destination, apply the current preference to future eligible shipment milestones, and avoid creating a delivery when consent or a usable address is absent.
3. Let authorized staff or an idempotent integration correct the contact or disable future tracking notifications without changing messages already attempted.
4. For mature channel support, retain consent source and time, synchronize provider suppression, and expose a scoped preference centre for the contact.

Tracking-email consent is configurable today. Staff and scoped external APIs can create or update a customer contact's tracking_notifications_enabled flag; enabling it requires an email address, and milestone delivery queries only opted-in contacts. RouteHut does not yet retain consent source or timestamp, distinguish purposes or shipment-specific recipients, support SMS or WhatsApp preferences, provide recipient self-service, or automatically reconcile unsubscribe, complaint, and provider-suppression state.

Follow a consented tracking email from committed shipment milestone through provider acceptance and final delivery outcome, then recover failures without creating duplicate notification records.

Normal path

1. Confirm that the customer contact has a valid email address and explicit tracking-email consent.
2. Commit the shipment milestone; RouteHut creates one durable notification for that contact and event, ensures a public tracking token, and queues delivery after the transaction commits.
3. Track each provider attempt separately from the delivery record, distinguishing provider acceptance from a signed delivered, bounce, or dropped callback.
4. Filter failed notifications, inspect attempt and provider-event history, correct a transient provider or configuration issue, and queue an authorized retry.

Consented milestone email, post-commit queuing, five-attempt provider recovery, SendGrid dynamic templates, signed outcome callbacks, callback deduplication, retained diagnostics, staff filtering, and failed-delivery retry are available. SMS, WhatsApp, recipient preference centres, suppression-list automation, address-correction resend, and campaign communication remain planned depth.

Turn route execution into a bounded arrival window and proactive delay update without claiming false precision.

Normal path

1. Derive an initial delivery window from the booked promise, route order, service durations, and provider travel metrics.
2. Refresh the projected arrival from completed stops and current position, recording when the estimate was calculated and how reliable it is.
3. Notify an opted-in recipient at tenant-defined milestones such as out for delivery, a bounded approaching window, or a material delay.
4. Publish a revised promise and reason after a meaningful route change, keeping staff, public tracking, and notification history aligned.

Not yet available as a proactive ETA workflow. RouteHut currently stores route-level planned duration, exposes an optional stop arrival estimate, compares estimated and completed stop times in analytics, and sends consent-aware emails for selected tracking events. Continuous recalculation, estimate confidence, delay detection, milestone policy, and ETA-specific communication remain to be built.

Let an authorized recipient request a safer time, access instruction, alternate recipient, safe place, or address correction before the delivery attempt.

Normal path

1. Authenticate the recipient through a shipment-scoped link and any risk-based verification required by policy.
2. Present only the preference types still allowed for the shipment, service, customer contract, and operational cutoff.
3. Validate address, price, service window, route capacity, and customer authorization before accepting the request.
4. Append the approved instruction, replan affected work, and notify operations, the driver, customer, and recipient.

Not yet available. Public tracking is read-only today, and staff can orchestrate return and redelivery after a failed attempt; recipient-initiated pre-delivery changes require their own authorization, policy, pricing, and replanning lifecycle.

Find the completed shipment, inspect its delivery evidence, and share only the level of proof appropriate to staff, integrations, or the public recipient view.

Normal path

1. Search the delivered shipment and open its POD history in the staff workspace.
2. Review the recipient confirmation, proof method, capture time, location accuracy, notes, and attached evidence.
3. Load staff evidence through the authenticated same-origin media path, without exposing the private object-store address as the product URL.
4. For an approved integration, use a pod:read credential to retrieve metadata and request an audited short-lived evidence download.

Authenticated staff viewing and scoped external retrieval are available. Evidence remains private in object storage; the staff browser receives it through the same RouteHut host, while external downloads are intentionally time-limited and audited.

Respond when a recipient denies receipt, reports a misdelivery, or challenges the recorded handover while preserving the original delivery event and evidence.

Normal path

1. Open a dispute linked to the shipment, delivery attempt, POD, claimant, and reported reason.
2. Preserve and review the route, location, custody scans, recipient confirmation, photo or signature, driver notes, communications, and evidence-access history.
3. Record a reasoned outcome such as confirmed delivery, misdelivery, insufficient evidence, recovery required, or escalation to a commercial claim.
4. Communicate the decision and create any retrieval, redelivery, credit, driver follow-up, or claims action without changing the original delivery history.

Not yet available. RouteHut retains immutable tracking and POD evidence and supports authenticated retrieval today, but it does not yet manage a delivery-dispute case, investigation ownership, decision, or corrective-action lifecycle.

Turn operational evidence into a controlled claim decision with clear ownership, liability, communication, and financial settlement.

Normal path

1. Open a claim linked to the shipment, parcel, claimant, and service terms.
2. Collect photos, POD, custody scans, declared value, correspondence, and supporting documents.
3. Assess responsibility and approve, partially approve, reject, or request more information.
4. Record settlement, credit, recovery, and customer communication without rewriting operational history.

Not yet available. RouteHut records damage, missing-parcel, custody, tracking, and POD evidence today, but does not yet manage the commercial claim and settlement lifecycle.

Carry an authorized amount-to-collect through delivery, driver cash custody, depot handover, and customer settlement without treating cash as an ordinary back-office payment.

Normal path

1. Record the authorized amount, currency, payment methods, and handover rule on the shipment.
2. Present the amount to the driver and capture payment before completing delivery.
3. Issue a receipt and place the collected value under driver cash custody.
4. Remit at the depot and reconcile the driver bag, shipment, customer liability, fees, and payout.

Not yet available. Staff can record cash against an issued invoice today, but RouteHut does not yet manage recipient collection, driver custody, remittance, or COD customer settlement.

Carry immutable booking charges into controlled invoice lines, payment recording, statements, and compensating adjustments.

Normal path

1. Review shipment charge lines and readiness.
2. Create and issue an auditable invoice.
3. Record payment or synchronize invoice status externally.
4. Use adjustments rather than rewriting posted financial history.

Billing is available; deeper profitability and automated reconciliation remain planned depth.

Resolve an incorrect charge, invoice, or payment through reasoned compensating records while preserving the original financial history.

Normal path

1. Verify the customer, invoice, charge lines, quote or pricing snapshot, service outcome, POD, statement, and payment history.
2. Record the reason and decide whether the source invoice remains valid, needs an adjustment, or has an eligible payment to reverse.
3. Issue a credit or debit note, void an eligible invoice or adjustment, or reverse the specific payment without editing or deleting posted history.
4. Review the recalculated balance and statement, communicate the outcome, and retain the decision and actor in the audit trail.

Reasoned invoice adjustments, voids, individual payment reversals, wallet reversal entries, statements, and audit history are available. A formal customer dispute case with owner, SLA, collection hold, correspondence, approval policy, and resolution lifecycle remains planned depth.

Turn invoice aging and live account exposure into a controlled payment, hold, and release decision without losing sight of work already booked.

Normal path

1. Review current and aged receivables by currency, then open the overdue invoice and customer account.
2. Confirm the invoice, adjustments, settled payments, pending shipment charges, credit limit, payment terms, and resulting available credit.
3. Record a partial or full payment, or place the credit account on hold when further postpaid bookings should stop.
4. Recheck the statement and exposure, then release the hold only when the tenant's credit policy has been satisfied.

Overdue filtering, aging summaries, partial and full payments, exposure-based available credit, manual hold or release, and booking enforcement are available. Automated dunning sequences, promise-to-pay records, collections ownership, staged hold policies, reminders, escalation, and customer correspondence remain planned depth.

Give finance and the customer a stable period view of invoices, payments, reversals, and adjustments rather than a balance that changes underneath the conversation.

Normal path

1. Select the customer, currency, and inclusive statement period.
2. Generate the immutable statement from invoices, invoice voids, payments, payment reversals, credit or debit notes, and adjustment voids.
3. Review opening balance, chronological source references, amounts, running balances, and closing balance against the customer's records.
4. Retain the generated statement in history and route any mismatch through payment reversal, billing correction, or credit-control handling.

On-demand generation, duplicate-period replay, line-level running balances, immutable history, and staff review are available. Branded PDF or spreadsheet export, scheduled generation and delivery, customer-portal retrieval, delivery acknowledgement, reconciliation sign-off, and automated follow-up remain planned depth.

Turn completed shipment, route, tracking, exception, and billing records into a daily operating review and a customer-ready performance view.

Normal path

1. Select the reporting period and review shipment volume, terminal outcomes, SLA performance, and exception trends.
2. Compare stored optimized stop ETAs with recorded execution timestamps.
3. Review route productivity, driver performance, and revenue signals against the underlying operational records.
4. Export the current tenant-scoped summary to CSV and turn material exceptions into operational follow-up.

Operational analytics and on-demand CSV export are available. Scheduled report delivery, deeper profitability, and a dedicated analytics warehouse remain planned depth.

Give each partner or system its own tenant-bound, least-privilege credential without storing recoverable API secrets in RouteHut.

Normal path

1. An owner or administrator names the integration, selects only its required read or write scopes, and optionally sets an expiry date.
2. Create the credential and copy its opk_ key once into the partner's secret store; RouteHut retains only its digest and identifying prefix.
3. Use the key as a bearer credential and monitor its status, scopes, creator, expiry, and last-used time in the credential register.
4. To replace access, issue and validate a separately named credential, update the partner, then revoke the old credential.

Scoped issue, one-time key reveal, digest-only storage, optional expiry, last-use monitoring, tenant isolation, and idempotent revocation are available. Atomic rotation, overlapping-expiry automation, expiry notifications, IP allowlists, and per-credential rate policies remain planned depth.

Move an order from a partner system into RouteHut, follow its commercial and delivery lifecycle, and reconcile the result without rekeying work.

Normal path

1. Issue a tenant-bound credential with only the customer, address, quote, shipment, tracking, POD, invoice, or webhook scopes the partner requires.
2. Create or update customer contacts and addresses, request a quote, then create and book one shipment idempotently or submit a bounded asynchronous JSON import with stable row keys.
3. Read shipment and tracking state, retrieve authorized POD and invoice records, and reconcile asynchronous import rows without exposing staff or tenant identifiers.
4. Subscribe a public receiver to selected versioned events, verify every signature, acknowledge quickly, and deduplicate by the stable event ID.

The released external API covers customers, contacts, addresses, quotes, individual and bulk shipment intake, booking and pre-handoff cancellation, tracking, POD retrieval, invoice reads, event discovery, webhook subscriptions, and delivery recovery. Dispatch planning, driver execution, hub scanning, billing mutations, labels, and shipment changes after operational handoff remain staff-controlled or planned rather than partner API promises.

Configure a tenant-scoped event feed so a commerce, warehouse, finance, or customer system can react to selected RouteHut changes without polling.

Normal path

1. Review the versioned event catalogue and select only the event names the receiver needs.
2. Name the subscription, register its public receiver URL, and create it through staff operations or an idempotent webhooks:write API request.
3. Copy the generated whsec_ signing secret once into the receiver's secret store; later subscription reads do not reveal it.
4. Activate the subscription, send a signed test through the normal delivery queue, verify the receiver, then monitor attempts and pause, update, or rotate the secret when operations require it.

Event catalogue discovery, staff and external subscription management, least-privilege scopes, idempotent external writes, one-time secret reveal, encrypted secret storage, signed asynchronous tests, pause or reactivation, rotation, delivery history, and tenant isolation are available. Receiver-ownership challenges, overlap-safe dual-secret rotation, and automated secret-expiry policy remain planned depth.

Recover a partner outage without losing the source event, bypassing endpoint safety, or turning a manual replay into duplicate downstream work.

Normal path

1. Let bounded automatic retries run, including a valid receiver Retry-After delay.
2. Filter delivery history by subscription or status and inspect the event ID, endpoint, cycle and attempt numbers, HTTP response, bounded response summary, next attempt, and error.
3. Pause the subscription while investigating if needed, correct the public endpoint, reactivate it, and send a signed test delivery through the normal queue.
4. Replay only the exhausted delivery; RouteHut opens a new delivery cycle using the current endpoint and signing secret while the receiver deduplicates the unchanged event ID.

Signed asynchronous delivery, endpoint safety checks, five-attempt bounded retry, receiver-directed delay, pause and reactivation, retained diagnostics, test delivery, exhausted replay, staff controls, and external recovery endpoints are available.

Extend the shared shipment and route foundation to typed handling units, pallet-aware vehicle capacity, loading, partial delivery, and quantity reconciliation.

Normal path

1. Create or import typed pallet handling units.
2. Validate weight, volume, pallet spaces, and special handling.
3. Load, collect, and scan custody by handling unit.
4. Deliver full or partial quantities and reconcile short, damaged, or rejected units.

Not yet available. Carrier procurement, multimodal freight, customs, and advanced load optimization are outside this planned slice.