CRM INTEGRATION AND AUTOMATION
Most CRM problems are not CRM problems. They are the gap between the CRM and everything else, filled in by somebody typing. Here is what usually goes wrong, what you can buy off the shelf to fix it, and the narrow set of cases where something has to be built.
A CRM is a filing cabinet that is only as good as what goes into it. The software is rarely the thing that fails. What fails is the bit either side of it: getting information in without somebody retyping it, and getting it out to the systems that need it.
So the enquiry arrives in an inbox and somebody copies it across. The order is taken in the accounts system and never reaches the customer record. The business cards from Tuesday's event sit in a jacket pocket until Sunday night. None of this is anybody being lazy. It is a gap in the tooling, and the cheapest thing to put in a gap is a person.
The question worth asking your team. Not "is the CRM working", because it is. Ask what they type into it that already exists somewhere else in the business. The answer is usually longer than anybody expects.
These are the five we see most, and they are all the same shape.
Once from the website form, once from the import somebody did in 2021, once because a name was spelled differently. Reporting on any of it is guesswork.
Sales can see what was quoted but not what was actually invoiced or paid, so nobody in the room has the whole picture during a customer conversation.
Common with off-the-shelf connectors, and fine until somebody updates a phone number in the wrong system and the change is quietly overwritten overnight.
The integration stops at the weekend. Nothing errors visibly. You find out three weeks later when a report looks thin.
Cards, forms, emails and phone notes all have to be typed in by somebody. That is the step that gets skipped when things are busy, which is exactly when the data matters.
Most CRMs integrate with the popular things. If yours does not cover your particular case, no amount of configuration will conjure one.
In rough order of cost. Most businesses reading this should stop at the second one.
Check the marketplace before anything else. Most CRMs ship connectors for the common accounting packages, mail tools and form builders, and they are maintained by somebody else at no cost to you.
Verdict: always look here first. People skip this step and pay for something that already existed.
These sit between systems and move data on a trigger, without anybody writing code. They cover an enormous range of everyday cases and you can build something useful in an afternoon.
Verdict: if your need is "when this happens over here, create that over there", buy one of these rather than build anything. It will be cheaper and quicker than us.
A single piece of software doing one job properly: reading from one system, applying your rules, writing to the other, and telling somebody when it cannot.
Verdict: right when the off-the-shelf tools cannot reach the thing you need, or when the rules are yours.
Where the problem is getting information in at all: a phone app, a scanner, a form that knows your business. This is where the time actually goes in most sales teams.
Verdict: worth it when the manual step is daily and skipped under pressure.
We would rather say that here than at the end of a proposal. A large share of what gets described to us as a bespoke integration is a Zap somebody could build themselves in an afternoon for a monthly fee, and we will tell you when that is what you have.
Where those tools stop is worth knowing: when the volume makes per-task pricing silly, when the logic needs real judgement rather than a rule, when there is no connector for your system at all, or when a silent failure would genuinely hurt and you need something that shouts.
Your CRM has no connector for the thing you need. This is the most common honest reason. The tool is otherwise fine, and the one capability you want does not exist in it.
The capture step is the bottleneck. If data is not reaching the CRM because entering it is tedious, no amount of syncing between systems helps. The fix is upstream.
The matching rules are yours. Deciding whether two records are the same company, which address wins, what happens to a duplicate. Generic tools apply generic rules, and generic rules make a mess of specific businesses.
It has to be reliable rather than clever. Retries, a record of what was sent, a way to replay a failed day, and something that tells a human when it is stuck. That is unglamorous and it is the difference between an integration you trust and one you check.
Small, specific, and a good example of the "no connector exists" case.
Tony connects with hundreds of people, and after a long day at an event he faced an evening of typing every card into his CRM. Other CRMs auto-register from business cards. Spotler did not, so no amount of configuration was going to solve it.
We built an iOS and Android app that uses the phone's camera and the Spotler API. Point it at a card, front and back, and the contact details are read and pushed straight into the CRM. Live in three weeks, at a fixed price agreed before anything started.
Our own description of it at the time still stands: not complex, not ground-breaking, not a viral app that wastes your time. A no-nonsense way to save time, money and effort.
We price the job, not the day, and you see the price before anything starts. As a rough shape, using our current rate of £15 a token:
The number is agreed in writing before anything begins and it does not move afterwards. If we misjudge it, that is ours to carry.
Anything with an API, which in practice is all of them. We have worked with Spotler and Zoho directly, and the approach is the same whatever the name: read the documentation, build against it, handle the failures properly.
Sometimes, and we will say so. If you are fighting your CRM on several fronts rather than one, integration work is patching over the wrong problem and you would get more from moving.
It breaks, eventually, whoever built it. The thing that matters is that it tells you rather than failing quietly. Anything we build reports its failures somewhere a human will see them.
Yes, and that is often the sensible shape: leave the everyday moves in Zapier and build only the piece it cannot do. Replacing something that works is rarely worth paying for.
Describe the two systems and what should move between them. You get a straight answer on whether an off-the-shelf tool does it, and a real price if it does not.
Get a price