Reading from a CRM — pulling contacts, deals, activity, notes, emails — is a solved problem. HubSpot, Salesforce, Pipedrive, Zoho and the rest publish decent APIs, and a read-only integration can be live within days. Everything you might want to do with that data — scoring, summarising, drafting, flagging risk — is downstream of a connection that is not hard to make.
Writing back is a different exercise. A record in a CRM is not just data, it is what a salesperson looks at before a call and what a forecast is built from. Putting a machine-written value into that view changes the meaning of the whole screen, and if the value is wrong twice, the person stops reading the field — and then stops trusting the neighbouring fields too.
Machine-written fields are visibly separate. Their own properties, clearly labelled as generated, never quietly overwriting something a person typed. If the two must merge, the human value wins and the generated one sits beside it.
Every written value carries its source. A score with no reasoning is an opinion the rep cannot check. A score with the three signals behind it and a link to the email they came from is a tool. The second one gets used.
Narrow permissions, from the first day. A dedicated integration user with access to exactly the objects and fields it needs. Not an admin key because it was faster on a Tuesday. This also makes the audit trail readable.
Writes are reversible. Log what was written, when, and what was there before. When the logic changes — and it will — you need to find and correct the records the old version touched.
Rate limits are a design input. Every CRM has them, and a backfill across a hundred thousand records will find them. Queue the work, respect the limits, and never let a backfill degrade the CRM for people using it.
The valuable jobs are the ones that involve reading language, because that is the work reps skip when they are busy. Turning a call recording into a structured note and the next step. Reading an inbound enquiry and filling the fields a rep would otherwise type. Watching a deal's activity and flagging that the champion has gone quiet. Assembling a first-draft proposal from the account's own history.
The jobs that are not worth it are the ones a workflow rule already does. Stage transitions on a fixed condition, task creation, round-robin assignment, alerts on a threshold — every CRM ships this, and putting a model in front of it adds cost, latency and a new way to be wrong. Use the platform for rules and reserve the model for language.
A CRM that people fill in inconsistently will limit what any of this can do, and it is better to know that in week one. The usual pattern: contacts are fine, deals are roughly fine, and the notes field contains everything that actually matters in free text nobody can query. That last part is genuinely good news — free text is precisely what a model is for.
What is not recoverable is missing signal. If nobody logs calls, no system can tell you which deals went quiet. If outcomes are never recorded, nothing can learn what a good lead looked like. Before promising a scoring model anything, check that the outcome column exists and is filled in — this single check has saved several of our clients a quarter of wasted work.
We run this check as part of the free mini audit: which objects are populated, which fields are trustworthy, and what could be automated with the data as it exists today rather than as it should exist.
Pick one object and one job. The most common good first choice is inbound: an enquiry arrives, the system reads it, creates or matches the contact, fills the qualification fields, attaches a short summary and routes it to an owner. It is measurable within a fortnight — response time and the share of enquiries a rep has to retype — and it writes into fields that were empty anyway, so nothing is overwritten.
Run it in shadow mode first if the team is sceptical: the system writes into a staging property and nobody acts on it, while you compare its output against what reps produce. Two weeks of that ends most arguments in either direction. Then switch the write on for real, keep the reasoning visible, and only then add the second job.
We use cookies for analytics — to see which pages bring enquiries. Nothing else, and nothing before you agree. Cookie Policy