all articles
automation · 5 min read
A practical strategy for integrating business systems
Prioritize business-system integrations with a dependency map, accountable owners, a bounded pilot and measurable acceptance and rollback criteria.
A business with ten to fifty people usually runs on many separate apps: accounting, a CRM, a help desk, a project tool, a shared drive, payroll, a shop or booking system. Each one works on its own. The cost shows up between them, in copy-paste, retyped invoices and spreadsheets that reconcile one system against another.
The temptation is to connect everything at once. This article is about the opposite: choosing which integration to build first, who owns it, how to test it on a small scale, and how to undo it if it goes wrong.
Step 1: Draw a dependency map
List every system and, for each one, what data it sends out and what it needs in. Then draw arrows. A whiteboard photo or a simple spreadsheet is enough. Two columns per arrow help: "how it moves today" (manual export, email, retyping) and "how often".
You are looking for three things:
- Hubs: systems with many arrows in and out, usually the CRM or the accounting tool. Changes there ripple everywhere, so they need the most care.
- Manual bridges: arrows where a person moves data by hand on a schedule. These are your candidates.
- Hidden order: some flows depend on others. You cannot sync invoices to accounting reliably until customer records match between the CRM and the accounting tool.
That last point decides sequence. If two systems disagree about who a customer is, fix identity first. (If that is your situation with customer-facing tools, our guide to connecting CRM, support and feedback systems covers matching, consent and retention in detail.)
Step 2: Score the candidates
For each manual bridge, answer five questions with rough, honest estimates. You do not need precise figures; you need a ranking.
| Question | Why it matters |
|---|---|
| How often does this happen, and how long does it take each time? | Frequency times effort is the real cost of doing nothing |
| What goes wrong when it is done by hand? | Errors in invoicing or payroll matter more than errors in a reading list |
| Does it block other work or other integrations? | Upstream fixes make later ones cheaper |
| Do both systems have a usable API or a native connector? | Without one, the build gets slower and more fragile |
| Who would own it after launch? | No owner means it will quietly break |
Pick the integration with high frequency, real error cost, a clean technical path and a willing owner. It is often not the most impressive one.
Step 3: Name the owners before anything is built
Every integration needs two named people:
- A business owner, who decides what correct looks like, approves changes and signs off the pilot. Usually the person whose team does the manual work today.
- A technical owner, who holds the credentials, reads the error alerts and can pause the flow. In a small company this may be the same person, or an outside builder with a handover plan.
Write down which system owns each shared field. If both the CRM and the accounting tool can edit a billing address, decide which one wins. Two-way sync without a rule overwrites good data.
Step 4: Estimate the full cost
The build is only part of it. Before you commit, list:
- Build time, internal or external.
- Platform usage. Automation tools meter usage in different units, so a design that is cheap in one can be costly in another. Zapier counts a task for each successful action step; its help center says triggers and filter steps do not use tasks. Make counts operations and bills in credits; its help center says a trigger counts once per check, and each action module counts once per bundle it processes. Ask how a polling trigger is counted when it finds nothing new. n8n's pricing page defines an execution as a single run of a whole workflow, regardless of how many steps it has. Model your expected volume against the current plan pages rather than guessing.
- Connector and API access. Some apps only expose an API on certain plans. Check before you design.
- Maintenance. Apps change fields, tokens expire, rate limits apply. Budget a little time each month for someone to check the error log.
- Exit cost. If you outgrow the tool, how hard is it to move the logic elsewhere?
Step 5: Run a bounded pilot
Limit the pilot on three sides: scope, data and time.
- Scope: one flow, one direction. For example, new paid invoices in the shop create sales records in accounting. Not refunds, not edits, not historic data.
- Data: a subset you can check by hand, such as one product line, one region, or the first fifty records.
- Time: two to four weeks is usually enough to see a full billing or reporting cycle. Pick a length that covers at least one.
Run the old manual process in parallel during the pilot, so you can compare outputs record by record.
Step 6: Write acceptance and rollback criteria before launch
Agree these in writing with the business owner before the pilot starts, not after you see the results.
Acceptance criteria are checks a person can verify, for example:
- Every record in the source appears in the target, with matching totals, for the pilot period.
- No duplicate records were created.
- Every failure produced an alert that a named person saw within one working day.
- Re-running a failed record does not create a second copy.
Rollback criteria say when you stop, and how:
- Triggers. For example: any wrong amount in accounting, or more failures than the team can fix by hand each week.
- How to pause. Who switches the workflow off, and where. Write the exact steps.
- How to clean up. A list of records created by the integration (tag them, or log their IDs) so they can be found and reversed.
- Fallback. The manual process stays documented and usable until the integration has passed acceptance.
If you cannot describe how to undo it, the integration is not ready to switch on.
Step 7: Go live in stages, then pick the next one
After acceptance, widen scope one step at a time: more records, then a second direction, then edits. Keep alerts on. After a month or so of stable running, retire the parallel manual process and return to the dependency map to choose the next integration. Each one you finish usually makes the next cheaper, because identity and ownership are already settled.
Where automotif fits
Choosing, piloting and handing over integrations like these is what our automation builds cover: we work in your own n8n, Make or Zapier accounts, write the acceptance and rollback criteria with you, and leave the owner with documentation. To talk through your own systems, book a free call of 30 to 60 minutes.