WhatsApp for delivery marketplaces: a handoff model for customer, driver and dispatch updates

A customer messages the driver about a different pickup entrance. The driver agrees, but dispatch still sees the original instruction. Later, another colleague answers a delivery query using an outdated arrival window. The conversation moved quickly; the booking did not move with it.

Delivery marketplaces need a handoff model that connects customer and driver conversations to accountable dispatch decisions throughout the booking lifecycle. WhatsApp can be the communication layer. It is not the authoritative dispatch record or an emergency service. Keep confirmed assignments, instructions and outcomes in the designated booking system, with a person responsible for each transfer.

Why a quick reply can leave dispatch behind

Customer-driver chat is useful for immediate clarification, but it crosses an organisational boundary. A driver may fulfil bookings for several marketplaces. A customer may have more than one active delivery. Dispatch may change shift while a private conversation continues. A message such as “that works” does not identify the booking, the approved change or who must act next.

The gap is ownership, not just visibility. Reading a message is not accepting a task; acknowledging a request is not approving it. Forwarding a screenshot to dispatch does not establish that the booking changed. Give each live booking a dispatch owner and deputy, and require explicit acceptance whenever responsibility passes between people or teams.

Give each layer a distinct job

Use the following division whether updates are entered manually or supported by a separately configured workflow. These are operating principles, not a claim that any particular integration is already available.

Where fulfilment and billing use different systems, identify which owns each fact and link the records. Do not let a support note override an approved dispatch instruction. If the booking system is unavailable, use an agreed temporary log, named owner and reconciliation deadline rather than silently making chat the replacement record.

Carry a minimum handoff record

Every actionable handoff needs enough context for the next person to act without searching several conversations. Use a consistent internal template:

• Booking reference: a stable identifier checked against the customer, driver assignment and relevant pickup or delivery leg.
• Event and source: what happened, when, who reported it and an access-controlled source reference where appropriate. Separate a reported claim from a verified fact.
• Owner and acceptance: the accountable person or role, their deputy and when they accepted the action.
• Next action and deadline: a specific task, due time and time zone, plus what happens if it is not completed.
• Status and decision: the booking stage, exception state, approved instruction and any authorisation still required.
• Record destination: the exact booking or linked record to update, with the person responsible for checking the saved result.

Keep this operational detail internal. Customer and driver messages should contain only the information that recipient needs. Use booking references alongside verified identity checks; a reference alone is not proof that someone is authorised to receive an address or change an instruction.

Follow the booking through six handoffs

1. Booking confirmed: establish the baseline

Confirm the booking through the authorised process before presenting it as accepted. Check pickup and destination, service window, item or vehicle requirements, contact preferences and any approved access instructions. Give dispatch ownership of the booking and specify the next milestone, such as driver allocation.

A WhatsApp confirmation can explain the reference, agreed window and monitored reply route. Do not expose another customer's information or promise a driver before allocation is confirmed. Record undeliverable messages and customers needing a non-WhatsApp alternative as owned contact exceptions.

2. Driver assigned: connect the right participants

Dispatch verifies the driver and assignment in the booking record, then shares the necessary job details through approved channels. Ask for explicit acceptance by the operational deadline; delivered or read indicators do not demonstrate that the driver has accepted the job. Check availability, vehicle suitability and any subcontractor handoff through the marketplace's normal process.

Tell the customer how to contact the service and what the driver may decide directly. Before creating any shared conversation, check participant identity and number exposure. If a driver is replaced, update the assignment, remove obsolete access where supported and confirm the replacement's acceptance. An old chat must not continue issuing instructions for a reassigned booking.

3. Pickup change: distinguish a request from approval

A different entrance may be a clarification; a new address or time window may change scope, route, cost or feasibility. Capture the requested change against the correct booking and stop short of promising it. The dispatch owner checks the impact and obtains any required customer or operational approval.

Once authorised, update and verify the booking instruction, then communicate the same revision to the affected driver and customer. Obtain any necessary acknowledgements. If the driver cannot safely check a message, use the agreed operational contact procedure; do not expect them to read or reply while driving.

4. In-transit exception: give the report an owner

Traffic disruption, an inaccessible destination, an incorrect item or a vehicle problem should open an exception tied to the booking and delivery leg. Capture the impact, current safe position where necessary, next decision and owner. Avoid sharing continuous location data when a limited operational update is sufficient.

Dispatch decides the authorised next step: revised estimate, alternate access, reassignment, return or cancellation. Keep unverified estimates distinct from commitments and set a next-update time. The customer should know who will respond; the driver should receive one current instruction rather than competing messages from support and dispatch.

5. Delivery confirmation: verify the outcome

Agree in advance what evidence the service requires, who may receive the delivery and how failed or partial delivery is recorded. A driver's “done” message starts a verification task; it is not sufficient by itself to close every booking. Check that the evidence belongs to the right booking and stop, and use approved restricted storage for signatures, photos or other personal information.

If the recipient disputes receipt, retain an owned exception rather than overwriting the report or treating a customer's silence as acceptance. Tell the customer the verified outcome through the agreed channel. Internal comments about liability, charges or investigation do not belong in the shared conversation.

6. Reconciliation: close the record, not just the conversation

The responsible operator records the approved outcome, relevant evidence reference, timestamps and remaining actions in the authoritative booking record. Reopen that record and check the saved assignment, instructions and completion or exception state. Identify who checked it and when. If a permitted configurable integration is used, apply the same verification principle; a sent event is not proof of a successful update.

Failed writes, duplicate events, permission errors and conflicting changes remain visible as pending reconciliation, with an owner and retry deadline. Check the latest state before retrying so an old message cannot reverse a later authorised decision. Carry refunds, claims or returns into the appropriate linked workflow rather than pretending that delivery closure resolves them.

Keep exception states separate from delivery stages

A booking can be in transit while its access exception is resolved but not yet reconciled. Track the two dimensions separately, using an exception reference if several issues affect one booking:

1. Reported: capture the source, booking, impact and time. Assign triage responsibility immediately; do not leave the report in an unattended group.
2. Acknowledged: confirm receipt and the next-update expectation. This means someone has seen the report, not that the requested change is approved.
3. Owned: a named operator accepts the next action, deadline and escalation path. When shifts change, the incoming owner explicitly accepts the handover.
4. Resolved: the authorised action has been completed and its outcome checked with the relevant party. A proposed solution is not yet a resolution.
5. Reconciled: the outcome and supporting reference are saved and verified in the designated record, with any further work linked and assigned.

Reopen the exception if new evidence contradicts the resolution. For example, an approved alternative entrance may resolve an access problem, but the exception remains unreconciled until the revised instruction is verified in the booking. “Customer informed” and “record updated” are different checks.

Protect customers and drivers without obscuring accountability

Privacy and numbers: ordinary WhatsApp groups can expose participant phone numbers. Do not assume adding a marketplace representative hides customer or driver numbers. Explain the arrangement before connecting people and assess an approved mediated or business-managed alternative where direct disclosure is inappropriate. Verify any proposed privacy controls in the actual configuration rather than promising anonymity.

Access: restrict operational views to authorised roles and relevant bookings. Plan for subcontractors, replacement drivers, shared devices and staff departures. Remove access when the assignment or role ends, while recognising that removal does not erase messages already received, downloaded or copied. Avoid cross-booking groups that disclose unrelated customers' addresses or delivery details.

Retention: agree what belongs in the booking record, what source material needs to be retained, where it is stored and when it is deleted under the organisation's policies and applicable requirements. Do not retain all chats and attachments indefinitely by default. Review exports, device copies and approved evidence storage; a transcript alone is not a reconciled dispatch history.

Escalation: publish monitored hours, backup contacts and thresholds for missed acknowledgements, unassigned reports and overdue decisions. Keep an alternative for customers or drivers who cannot use WhatsApp. Immediate danger, injury or an unsafe vehicle requires the established emergency and safety procedures, not a chat queue. WhatsApp is not an emergency service, and silence is not evidence of safety.

A practical implementation checklist

• Map the lifecycle: define the six booking stages, decision rights and facts owned by each authoritative system.
• Name owners: assign dispatch coverage, deputies and explicit shift-handover acceptance.
• Standardise context: test booking identification, source references, next actions, deadlines and exception states.
• Control outbound updates: separate internal notes from customer and driver replies; check recipients and approvals before sending.
• Agree privacy arrangements: review numbers, group membership, addresses, evidence, device access and retention before connecting participants.
• Define alternatives: document failed-contact, accessibility, out-of-hours, driving-safety and emergency routes.
• Start with verified transfers: use named manual updates unless a suitable connection has been separately configured and tested. Define error handling and reconciliation for either approach.
• Rehearse exceptions: test reassignment, a late pickup change, disputed delivery, duplicate messages, a system outage and a failed record update.
• Review closure: check unresolved and unreconciled work, not merely whether somebody replied in WhatsApp.

For related workflows, see the removals guide for move-day changes and the automotive sales and delivery handoff guide. This model instead centres on marketplace dispatch responsibility from booking confirmation through fulfilment and final reconciliation, including bookings served by changing external drivers.

Keep the conversation convenient and dispatch accountable

Jely helps service teams coordinate WhatsApp conversations with internal operations. Start by agreeing who owns each decision and how its outcome reaches the booking record, rather than assuming an automatic dispatch integration. Book a demo to discuss whether Jely fits your customer, driver and dispatch workflow.