QS QuoterInsights by AGMM
AI and automation14 July 2026·6 min read

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 CRM as the spine of the install CRM one record per job Email Accounting Project management Third-party software Internal databases Each spoke has a defined direction of flow, an owner, and a test before pilot.
Week three of an install: every spoke connected, tested, and flowing in an agreed direction.

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.

SystemShould flowCommon failure
CRMEvery enquiry, quote, job status and value figure lands here automaticallyCRM only holds what someone remembered to type
EmailEnquiries create records; quotes and follow-ups send from templates; threads attach to the jobThe real history lives in one person's inbox
AccountingWon quotes become draft invoices; payments update job statusQuoted and invoiced figures drift apart, unnoticed
Project managementWon jobs create projects with dates and scope pre-filledSite team works from a forwarded PDF
Internal databasesRate books, price lists, supplier terms feed quoting livePrices updated in one place stay stale in another
Third-party softwareTakeoff, scheduling or supplier portals exchange data, not screenshotsThe 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.

The failure-mode question: for every integration, ask "how will we know when this breaks?" Connections fail silently, and a sync that died in March is usually discovered in June, three hundred records too late. Every integration needs an alert, not just a hope.
One owner per fact, one direction per flow CRM owns customers, jobs, quotes Accounting owns invoices, payments, VAT Projects own programme, tasks, site notes flows out read-only to accounting, projects, email flows back read-only as paid and overdue flags in CRM flows back read-only as job status against the record Two-way editing of the same fact is where sync conflicts, and bad data, are born.
An ownership map: each fact has one home system, and everything else receives it read-only.

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:

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