Delivery and CRM integration: which data moves between the systems and how to set up the sync

What breaks when the CRM and delivery live apart

A CRM owns the relationship with the customer: deals, contacts, agreed timings and payment terms all sit there. A delivery management system owns execution: who is going out, in what order, and what proves the job was done. As long as those two loops are not connected, there is a person standing between them moving data by hand — and the cost of that transfer is about far more than the time it takes.

The usual consequences of the gap look like this:

• Double entry and typos. An address typed in a second time is an address with a chance of being wrong. The field worker drives to the wrong place, and it gets sorted out on site.
• Statuses lagging behind. The manager cannot see what is happening with the order and tells the customer "let me check" instead of giving them an answer. Every one of those checks is a call to the dispatcher.
• Lost orders. The deal moved to the "handed over to delivery" stage but never reached the dispatch desk — and nobody noticed until the customer rang.
• Reports that do not match. The CRM shows one number of shipments, the operational system another, and the only person who can explain the gap is the employee with a good memory for detail.

Integration removes that manual layer: the job appears on the dispatcher's screen the moment the deal reaches the right stage, and the outcome comes back into the customer's record without anyone retelling it. Everything else — notifications, analytics, nicer interfaces — is built on top of that basic exchange. Which is why the design work should start with "which facts need to travel, and in which direction", not with "which buttons do we press".

Which data moves between the CRM and the delivery system

The exchange is nearly always two-way, and it helps to describe it as two short lists — what leaves the CRM and what comes back. Going out to the delivery system, you would normally pass:

• the job or order: number, type of work, contents, the manager's notes;
• the service address with access details — entrance, floor, building pass, who to call on arrival;
• recipient contacts and the agreed time window;
• the amount and payment method, if the field worker collects money;
• an urgency or priority flag — so the dispatcher can see it cannot slip to tomorrow.

Coming back the other way, from delivery into the CRM, are the facts of execution:

• the assigned field worker and an estimated time of arrival;
• statuses: accepted, on the way, on site, completed, failed;
• the failure reason from a closed list — refused, no answer, address not found, rescheduled at the customer's request;
• proof: photo report, recipient's signature, the time and place the status was set;
• payment collected on site, where the field worker took it.

Customer and address directories deserve a separate agreement. If both sides can create records, duplicates will show up in the first month: "Acme Ltd" and "Acme Limited" become two entries with different histories, and any customer report has to be assembled by hand. It is far simpler to make one system the owner of a directory and the other one its consumer.

A practical move that saves weeks of back-and-forth: before any work starts, list the fields in a four-column table — name in the CRM, name in the delivery system, direction of travel, what to do when the value is empty. That single page is your integration spec.

Ways to sync: API, webhooks and file exports

Technically there are several routes to connecting the systems. The choice depends not on fashion but on how quickly you need the data and what your CRM is capable of.

• An API integration. The systems call each other directly. This is the most flexible option: any set of fields can move and the logic is entirely under your control. In exchange it takes configuration and a clear understanding of which method fires on which event.
• Webhooks. The CRM announces that a deal has reached the relevant stage, and the delivery system announces a status change. Data updates almost instantly with no polling, but you have to plan retries up front: if the receiving side was unavailable, the event must not simply disappear.
• File exports. Orders go over in batches on a schedule, from a spreadsheet for example. This is the fastest start: no development needed, and it works well when orders are ready by morning and rarely change during the day.
• A middleware connector. A separate bridging service reconciles formats and holds the mappings and rules. It earns its keep when there is more than one source: some jobs come from the CRM, some from your accounting system, some from a form on the website.

There is no universal answer, but there is a simple guide. If the customer expects a status the same day and your managers are fielding "where is my order" calls, you need event-driven exchange. If the flow is put together the day before and stays stable, a file export is enough — and it is only worth complicating once there is a specific job it cannot do.

itlogist integrates with AmoCRM, Bitrix24, 1C and Excel, so jobs enter the workflow from the source you already use, with no retyping. What happens to a job after that — assignment to field staff, live routes on the map, a mobile app with photo reports and checklists, a client portal showing statuses — is all set out on the What itlogist can do page.

Source of truth, matching key and error handling

Most integration problems are not technical, they are matters of agreement. Below are four questions whose answers decide whether the sync runs without daily supervision.

• The matching key. Which field links a delivery job to a CRM deal — the deal number, an internal identifier, the order number. There should be exactly one key, it should never change, and it should travel in both directions. Matching on a phone number or an address falls apart as soon as the same customer orders twice.
• A source of truth per field. Who owns the address, who owns the delivery time, who owns the amount. If the manager changes the window in the CRM and the dispatcher changes it in the delivery system, the winner should not be whoever clicked last but whoever the rule says it is.
• A single status model. Pipeline stages in the CRM and execution statuses are different things. You need an explicit mapping table: which operational status moves the deal to which stage, and which transitions are forbidden. Otherwise the deal will roll backwards on every re-attempted delivery.
• Behaviour on failure. What happens when the address is empty, the customer cannot be found or the receiving side does not respond. A workable pattern: the job is not silently lost but goes into a retry queue or onto a list for manual review — and somebody owns that list.

Two more things people remember late. First, a resend must not create a duplicate: if the same event arrives twice, the second attempt has to update the existing job rather than open a new one. Second, access rights — the integration account should see and change only what the exchange requires, and it should not be tied to one particular employee who will eventually leave and take their password with them.

How to roll it out: one scenario first, then the full flow

There is no need to launch an integration at full width. A sequence that works looks like this, and it usually fits into a few short iterations.

• Describe one scenario end to end. Take your highest-volume order type and follow it from the CRM stage all the way to the completion mark. Non-standard cases — returns, partial refusals, repeat visits — come in as a second step.
• Agree the field map. That four-column table. Until both sides have signed it off, it is too early to start configuring anything.
• Tidy up your data. Normalised addresses, current phone numbers, access notes. An integration speeds up the transfer of rubbish too: a bad address simply reaches the field worker faster.
• Test on a trial flow. A dozen jobs in both directions, including deliberately broken ones: no address, a duplicate, a cancellation after assignment.
• Remove the manual transfer. As soon as the exchange is running, the old method has to be switched off. Two parallel schemes always end in mismatched data and an argument about which one is right.
• Agree on support. Who watches the error queue, how quickly they respond, what they do when one of the systems is unavailable.

A few simple measures, recorded before and after, will tell you whether it worked: how long it takes from the deal reaching the relevant stage to the job appearing on the dispatcher's screen, how many orders are still entered by hand, how often managers call the dispatch desk to ask about a status. That last one usually moves first — it is where you can see that information has started flowing through the system rather than through people.

The barrier to entry is lower than people assume: launch takes 7 days with no long-term contract, and the platform is designed for teams of 5 to 100 field staff. In other words, you can test the CRM connection on your live order flow and compare it against your recorded baseline a month later.