The sync that runs at 2am
Your CRM is connected to something else: the website, the ERP, the accounts package or the order system. The connection runs as a nightly job. It was set up that way years ago because it was simple and nobody asked for more.
Now the cracks show. A lead fills in a form at ten in the morning and a salesperson does not see it until the next day. A customer places an order, rings to ask about it, and the account manager's screen shows nothing. Someone updates a phone number in the CRM, the nightly job overwrites it with the old one from the ERP, and nobody can work out why the change keeps undoing itself.
Or the opposite: someone built everything as instant triggers, and now the CRM hits its API limit every afternoon and silently drops updates.
Why one setting for everything goes wrong
The question is usually framed as real-time or batch for the whole integration. That is the mistake. Different data has different urgency and different volume, and the right answer changes record by record.
| Data | Typical need | Why |
|---|---|---|
| New web leads | Real time | Response speed affects whether you win the enquiry |
| Deal won | Real time | Triggers invoicing, onboarding or an order |
| Stock levels | Near real time | Sales quote from them |
| Invoice paid status | Hourly is often fine | Useful context, rarely urgent |
| Order history import | Batch | Large volume, nobody waits for it |
| Reporting totals | Batch | Read once a day or week |
Batch jobs also create a hidden problem with conflicts. If both systems can edit the same field and they only compare notes once a night, the last one to write wins, and the last one to write is usually the batch job, not the person who made the change.
What the wrong choice costs
- Leads that sit untouched until the next sync, while a competitor replies first
- Staff giving customers out-of-date answers about orders or stock
- Changes that mysteriously revert when the batch overwrites them
- API limits hit by chatty real-time triggers, with updates quietly lost
- Failures noticed days later, because a nightly job erroring at 2am alerts nobody
The last one deserves a mention. A batch job that fails without telling anyone can leave two systems drifting apart for a week before someone spots a missing customer.
How we design the integration
- Data inventory. We list every object that crosses between the systems, how often it changes, who acts on it and how quickly they need it.
- Ownership per field. For each field we decide which system is the source of truth, so a sync never overwrites a deliberate change with stale data.
- Event-driven where it matters. We use webhooks from HubSpot, Salesforce, Shopify or your web forms to push urgent events through a queue as they happen. The queue absorbs bursts and retries if the other side is briefly unavailable.
- Scheduled jobs for bulk. Large, low-urgency data runs on a schedule, sending only records that changed since the last run rather than everything.
- Rate limit handling. The integration tracks API limits for each system and slows down rather than dropping records.
- Monitoring. Failed messages land in a dead-letter queue with an alert to a named person, and there is a simple page showing when each flow last succeeded.
For simpler setups we build this in n8n, Make or Zapier. When volume, rules or conflict handling get heavier, we write a small integration service, usually hosted on AWS or Azure.
Day to day afterwards
A web lead appears in the CRM and on the right salesperson's phone as the form is sent, not the next morning. A won deal starts the order or invoice without anyone copying it. Reports still refresh overnight, which is all they ever needed.
Changes stop undoing themselves because each field has one owner. And when something does fail, a person hears about it that morning instead of a customer telling you next week.
Does this match what you see?
- Your CRM sync runs once a night and people complain about stale data
- Leads or orders take hours to appear where they are needed
- Edits in one system keep getting overwritten by the other
- You hit API limits and are not sure what was lost
- Nobody is told when the sync fails
- The integration was set up once and nobody has looked at it since