CRM and delivery service integration should remove repeated data entry while preserving control over fulfilment. A manager confirms an order once, the system creates the shipment, stores the carrier identifier and follows its state through delivery, refusal or return.
The work is not complete when a tracking number appears. Address changes, cancellation, multiple parcels, cash collection, redirection, storage and returns still affect the commercial order. Delivery events must therefore trigger the next business action, not merely change a label.
Define responsibility boundaries
CRM owns the customer, agreement and commercial state. The warehouse confirms actual packing. The carrier owns routing and physical movement. Integration should not force one system to guess another system's facts.
| Data | Source | Recipient |
|---|---|---|
| Recipient, contacts and payment method | Confirmed CRM order | Carrier |
| Parcels, weight and dispatch readiness | Warehouse | CRM and carrier |
| Shipment identifier and route | Carrier | CRM |
| Movement and delivery state | Carrier | CRM and notifications |
| Accepted product return | Warehouse after inspection | CRM and accounting |
If the warehouse calculates weight, a salesperson should not estimate it. If the customer confirms an address, an amendment after packing requires a controlled scenario. Record these rules before implementing calls.
Send only an approved order
A draft opportunity is not a shipment. Typical preconditions are confirmed contacts, delivery method, final order lines and permission to pick. Some businesses also require payment, credit approval or a manual check.
- CRM validates required data and the allowed transition.
- The warehouse confirms packing or provides actual parcels and weight.
- The request receives a unique internal operation identifier.
- The carrier returns its own shipment identifier and parameters.
- CRM stores both identifiers and prevents accidental recreation.
Do not copy every carrier state into the sales pipeline
Detailed technical states are useful for diagnostics, but managers need operational groups. Several transit events can belong to “in transit” while the original carrier code remains stored.
| CRM group | Delivery events | Action |
|---|---|---|
| Preparing | Shipment created but not accepted | Check physical handover |
| In transit | Accepted and moving | Monitor the agreed deadline |
| Awaiting recipient | At pickup point or out for delivery | Reminder under business rules |
| Delivered | Handover confirmed | Close fulfilment and schedule follow-up |
| Exception | Refusal, delay or invalid details | Task for the responsible employee |
| Returning | Moving back or returned | Receiving and financial review |
A state must trigger an action
If a created shipment is not accepted by the carrier within the control period, the warehouse receives a task. If the customer does not collect it, CRM schedules contact. If the carrier records refusal, the deal does not close automatically; it waits for product receipt and financial resolution.
Notifications must be idempotent because a carrier can repeat the same event. A duplicate callback must not create duplicate tasks or messages.
Amendment and cancellation need explicit paths
Before handover, an address or parcel may be changed through the original order and shipment update. After acceptance, only certain carrier operations may be available. The integration must show the external result rather than saving an unconfirmed new value in CRM.
Do not delete a cancelled shipment from CRM. Preserve the cancellation state, reason, request time and carrier response for audit and support.
A return ends after receiving inspection
A carrier state “returned” confirms physical delivery back to the sender, not product quantity or quality. The warehouse must receive and inspect the parcel before stock becomes available. Accounting separately records refunds, fees and delivery cost.
| Risk | Integration control | Owner |
|---|---|---|
| Duplicate shipments | Unique key and safe request retry | Integration |
| Invalid address | Validation and explicit error | Sales manager |
| Shipment never handed over | Deadline between creation and acceptance | Warehouse |
| State has stopped changing | Age threshold and assigned task | Logistics |
| Return not received into stock | Link carrier state to receiving document | Warehouse and finance |
Pre-launch tests
- create standard and multi-parcel shipments;
- retry after simulating a lost response;
- test amendments before and after carrier acceptance;
- handle an invalid address and unavailable service;
- complete delivery, refusal and return;
- send the same status twice;
- disable the carrier temporarily and confirm events are retained;
- reconcile shipment cost and collected payment.
A strong integration does more than produce a carrier document. It connects sale, warehouse, transport and return into one controlled process. Around the Business Reactor Core, this exchange can be organised around the shared order and its events so managers see the business state while technical detail remains available for investigation.
