The integration checklist: CRM, email, accounts, projects
Automation projects rarely die in the build. They die in the gaps between systems, where a quote exists in one tool, the customer in another, and the invoice in a third, and a human with a keyboard is the only bridge. Integration is the unglamorous week that decides whether the whole thing works.
Why integration is the make-or-break week
A workflow is only automated if information moves through it without being retyped. The moment a person has to copy a customer's details from an email into the CRM, then from the CRM into the quote, then from the quote into the accounting package, you do not have automation, you have expensive software connected by a tired human. Every manual hop is a place where errors breed and hours vanish.
This is why, in AGMM's installation timeline, integration owns the whole of week three, after the build in week two and before the pilot in week four. It gets its own week because it is the hardest part to do well and the most common thing providers skip. A system demonstrated in isolation always looks good; the question is what happens when it meets your inbox, your accounts package and your five years of customer records.
The checklist, system by system
For each system, the questions are the same: what flows in, what flows out, and what breaks quietly if the connection fails.
| System | Should flow | Common failure |
|---|---|---|
| CRM | Every enquiry, quote, job status and value figure lands here automatically | CRM only holds what someone remembered to type |
| Enquiries create records; quotes and follow-ups send from templates; threads attach to the job | The real history lives in one person's inbox | |
| Accounting | Won quotes become draft invoices; payments update job status | Quoted and invoiced figures drift apart, unnoticed |
| Project management | Won jobs create projects with dates and scope pre-filled | Site team works from a forwarded PDF |
| Internal databases | Rate books, price lists, supplier terms feed quoting live | Prices updated in one place stay stale in another |
| Third-party software | Takeoff, scheduling or supplier portals exchange data, not screenshots | The bridge is a person with two windows open |
One-way or two-way: decide deliberately
Not every connection should be two-way. A two-way sync sounds better and is often worse: when two systems can both edit the same fact, you eventually get conflicts, and conflicts resolved automatically are conflicts resolved wrongly somewhere. The safer pattern for most trade firms is a single source of truth per fact with one-way flows out of it. Customer details live in the CRM and flow to accounting; invoice status lives in accounting and flows back as a read-only flag. Decide which system owns which fact, write it down, and let every integration follow that map. This is most of the answer to the mess described in connecting your business software into one workflow.
Writing this map down takes an hour and prevents months of confusion. It also makes every future tooling decision easier: when a new tool arrives, the first question is simply which facts it owns and which it merely reads, and the integration design follows automatically from the answer.
Testing integrations before they carry weight
An integration is not done when data flows once in a demo. It is done when it has survived contact with your real, messy records. Before the week-four pilot, each connection should be tested against:
- Volume: last month's full enquiry list pushed through, not three tidy examples.
- Mess: the customer with two email addresses, the job with a revised quote, the invoice that was part-paid.
- Failure: disconnect one end deliberately and confirm the error is visible, queued and recoverable, not silent.
- Duplicates: run the same record through twice and confirm you get one record, not two.
Only after that does live work touch the system, in the pilot structure described in the month-one playbook.
One more test worth insisting on: history. A new system that starts empty forces the team to live in two worlds, old jobs in the old tools and new jobs in the new one, for months. Migrating at least the active jobs and recent customer records during integration week means the system is useful from its first day, which quietly does more for adoption than any training session.
Who owns what, afterwards
Integrations are living things. Tools update their interfaces, passwords rotate, a subscription lapses, and a connection that worked in month one dies in month five. Someone must own each connection by name, and the monthly rhythm should include a glance at the sync health. In an AGMM install this is part of what the month three optimisation review checks, and the value-tracking model creates a blunt incentive: since the fee is ten percent of value measured in your own CRM, the installer has skin in keeping data flowing into it correctly. The full installation structure, week by week, is on the QS Quoter Commercial page.
Integration will never be the exciting part of an automation project. It is merely the part that determines whether the exciting parts work.
Week three is where installs earn their fee
AGMM installs dedicate a full week to connecting your CRM, email, accounting, project management and third-party tools, then test everything against your real records before the pilot.
Book a discovery call