A B2B delivery does not need either delivery notice, tracking or proof of delivery. It needs the right sequence: notice before the event, tracking during execution, proof after handover. That tells the recipient when staff, dock space or carrying help must be ready; dispatch sees deviations early; and after delivery there is a record that can be checked.
This matters most for bulky goods, spare parts, store deliveries, direct runs and recurring routes. A parcel status alone does not answer whether dock 3 is staffed, whether the goods must be brought into a practice room, or whether a later complaint can be resolved with a photo and signature.
The short answer
Use the three building blocks for different questions.
| Building block | Answers | Timing | Typical content |
|---|---|---|---|
| Delivery notice | Who must be ready? | before pickup or delivery | window, contact, dock, packages, special requirement |
| Tracking | Where is the delivery now? | during execution | status, driver location, ETA, stop sequence, deviation |
| Proof of delivery | What happened at handover? | after pickup or delivery | time, place, name, photo, signature, damage or acceptance note |
When one block is missing, a different failure appears: without notice, the driver waits. Without tracking, dispatch keeps calling. Without proof, support, billing or claims lack a shared basis later.
When delivery notice should be mandatory
A delivery notice is worthwhile whenever the recipient must actively prepare something. That may be a dock, goods-in team, building manager, technician, customer working from home or a second person for carrying support.
Typical cases:
- pallets or bulky goods go to a warehouse with a dock slot.
- furniture or a large appliance is not just arriving, but must be handed over at a defined point.
- acceptance is only possible within a narrow time window.
- there are access codes, gate notes, contacts or security procedures.
- an exchange runs in both directions: new part outbound, old part or return item inbound.
- a direct run must protect a production, service or installation appointment.
The notice is more than "arrives today". A useful message is closer to: "Expected 10:20-10:40, dock 3, two packages, recipient: goods-in, signature and photo required." The driver can execute that, and the recipient can plan around it.
Why tracking does not replace notice
Tracking shows movement. Notice creates readiness. The two should not be mixed.
DHL describes live tracking as a real-time view with delivery window, location and updated shifts for selected shipments (DHL Live Tracking). Cargoboard shows shipment status through a link, customer portal or service contact (Cargoboard Track & Trace). Uber Direct documents tracking URLs and status webhooks in its delivery API (Uber Direct API).
The shared market standard is clear: recipients and shippers expect visibility. For operational B2B deliveries, visibility is useful only when it is connected to the order reality:
- ETA without a time window does not say whether the delivery is still acceptable.
- Location without a contact does not say whom the driver should call on site.
- Status without package data does not say whether everything was collected.
- Tracking without proof does not say in what condition the goods were handed over.
Maxmove therefore keeps these layers separate inside the order: time windows, contacts, driver status, live tracking and digital proof of delivery belong together, but they do different jobs.
The operating flow
A reliable process follows the delivery sequence, not the technology.
| Phase | Decision | System data | Risk if missing |
|---|---|---|---|
| Order intake | Can this order be executed as promised? | address, packages, dimensions, weight, window, reference | wrong vehicle, wrong driver, wrong promise |
| Lead time | Who needs to be informed? | recipient, contact channel, gate, floor, access, required proof | waiting time, failed acceptance, second attempt |
| Tour start | Which forecast is realistic? | driver, route, stops, traffic, service time | ETA becomes a guess |
| On the road | Does someone need to react? | status, location, deviation, new ETA | support keeps chasing the driver |
| Handover | What was actually confirmed? | photo, signature, name, time, place, note | dispute about quantity, condition or timing |
| After delivery | Who needs the record? | customer, support, billing, return, claim | proof lives in chats, email or paper folders |
For one-off transports, the flow can start with a structured booking. For recurring deliveries, it belongs in a TMS, so recipients, drivers and dispatch do not rebuild the same information every week.
Decision: what does this order need?
Not every delivery needs the same depth. Use this matrix before committing to the customer.
| Order situation | Minimum process |
|---|---|
| Small, low-risk parcel to staffed goods-in | status and simple proof of delivery |
| Bulky goods, large appliance or furniture | delivery notice, tracking, photo or signature |
| Dock with fixed slot | notice with time window, contact and ETA update |
| Spare part for downtime or technician appointment | direct run, live tracking, proactive deviation notice |
| Return or exchange | pickup and delivery proof with reference and photo |
| Delivery to office, practice, construction site or store | contact, access note, handover point and proof |
| Recurring route | stored recipient data, route planning, proof per stop |
The key point: the process must be decided before the customer promise. Missing contacts or missing carrying scope are expensive to repair after dispatch.
What good proof of delivery should contain
Digital proof of delivery is not a decorative PDF. It must answer a later question: who accepted what, when, where and in what condition?
For B2B deliveries, these fields are especially useful:
- Order or customer reference: so goods-in, support and billing find the same case.
- Timestamp: record pickup, arrival, handover or failed attempt separately.
- Place or stop reference: for campuses, factory sites, stores or construction sites, not just the main address.
- Recipient name or role: person, goods-in, reception, warehouse, site manager.
- Photo: goods, packaging, handover point or damage, without unnecessarily documenting private interiors.
- Signature or PIN: when the shipper requires stronger confirmation.
- Reservation: damaged packaging, missing package, refused acceptance, waiting time.
Uber Direct lists signature, barcode, photo, identification and PIN among possible proof-of-delivery verification methods (Uber Direct Proof of Delivery). Lalamove tells drivers in a FAQ not to take photos of customer faces or private interiors for POD photos (Lalamove FAQ). The practical conclusion for German B2B workflows: proof should evidence the transport, not collect more personal or private information than necessary.
Example: a store delivers a large appliance to a practice
An online store sells a large medical refrigerator to a practice. The goods are valuable, bulky and must go into a treatment room. A normal parcel workflow is too coarse.
The clean process:
- Before checkout or support confirmation: capture product dimensions, weight, destination room, floor, lift and contact.
- Create the order: define "delivery to room of use", time window, practice reference, photo proof and signature.
- Send notice: the practice receives the planned window, contact and instruction to keep access clear.
- Execute: the driver sees address, contact, packages and handover point in the app.
- Share tracking: the practice or store sees the current ETA without calling dispatch.
- Capture proof: photo of the packaged goods at handover, recipient name, signature and timestamp.
- Afterwards: support and billing use the same record.
If the order recurs, product data and recipient requirements should not live in free-text notes. They belong as reusable data in the delivery process.
Common mistakes
Sending only a tracking link. The recipient sees movement, but no instruction. That is rarely enough for docks, stores and large appliances.
Handling notice by phone and storing nothing. Nobody can tell later whether a time window was promised, estimated or changed.
Saving a photo without context. A picture in a driver chat is weak proof when order, time, place and recipient are missing.
Treating every exception as free text. "Customer absent", "gate closed" and "goods damaged" must be analysable, otherwise the operation learns nothing from repeated failures.
Leaving service scope undefined. Tracking and proof do not solve carrying, assembly, disposal or special equipment. Those points must be booked and planned as services.
Where Maxmove fits
Maxmove fits transport teams that do not want to run B2B deliveries through phone chains, private chats and scattered PDFs. One order can connect addresses, time windows, contacts, vehicle requirements, driver status, live tracking and digital proof of delivery.
For one-off transports, the process starts through booking or the right small transport. For recurring routes, multiple drivers or fleet workflows, Maxmove TMS is the right context: dispatch, driver app, tracking and proof work from the same order.
The limit remains important: Maxmove does not replace missing product data, unclear delivery scope or legal assessment of damage. The system makes the operating facts visible, so teams can decide better and document cleanly afterwards.
Checklist before the next B2B delivery
- Is the handover point clear: dock, curb, first door, room or room of use?
- Are time window, contact, access and parking notes stored on the order?
- Does the recipient know in advance when and with what effort the delivery arrives?
- Is there a tracking link or other clear status view for shipper and recipient?
- Is it defined whether photo, signature, name, PIN or damage note is needed?
- Can support and billing find the proof later through reference or order?
- Are exceptions structured enough to reveal repeated causes?
The best delivery communication is not the loudest. It separates preparation, live visibility and evidence cleanly. That is what reduces follow-up calls, waiting time and disputes.
