Zoho CRM is the cheapest serious CRM most small firms will look at, and the suite around it is usually why they stay. Our Zoho CRM integration work is the part that comes after: making the phone, the calendar, Books and Desk share one customer record, and putting the automation where it actually belongs.
Wired to the rest of your stack
Zoho gets chosen for two reasons. It costs a fraction of the obvious alternatives per seat, and it arrives with everything else you might need attached to it: Books for invoicing, Desk for support, Bookings for appointments, Campaigns for email, Flow to wire it all together. The reasonable assumption is that because they carry the same logo they already share a customer record.
They share some of it. Each app is a separate product with its own data model, its own API and its own limits, and the joins between them were built to a fixed shape you cannot reshape. So the gaps turn up in ordinary places: a field in Books with no equivalent in CRM, a second Books organisation that only syncs one way, an invoice edited on the accounts side that never pushes the change back. None of it is broken enough to fix on a Tuesday, and all of it costs somebody an hour a week.
The suite is a good foundation, not a finished system. The work is deciding which app owns which field, building the joins Zoho does not make for you, and putting each piece of automation in the right place: Deluge inside the CRM when it has to be instant, Zoho Flow when a visual flow is enough, and outside Zoho when the job is too long or too heavy for either.
Every call, form and booking is written into Zoho as a Lead or Contact with a note and a next action, through the API rather than a bolt-on that drops a message somebody still has to read. We set the duplicate-check fields so a caller known only by their number updates the record you already hold, because out of the box Zoho treats email as the unique field and a phone number as just another column.
Zoho runs separate regions for the US, EU, India, Australia, Japan, Canada and others, each with its own accounts server and its own API domain. We authorise against the region your organisation actually lives in and use the API domain Zoho hands back at token exchange, so the integration still works if you are outside the US or if your org is ever migrated between regions.
Logic that has to run the moment a record saves goes into a Deluge function inside the CRM, where there is no third-party hop and nothing to wait for: a custom button, a blueprint transition, a field that must be correct on save. Work that is long, heavy or spread across several systems goes outside it, because Deluge functions run against statement and execution-time budgets and a loop spends one for every pass, not one for every line you wrote.
The native Zoho-to-Zoho syncs are real but fixed: only the first Books organisation gets a two-way sync, some Books fields have no CRM equivalent to map to, and an invoice edited in Books does not reliably push its change back to the deal. We build the joins those leave out, so nobody is entering the same customer twice into two apps you already pay for.
Zoho turns a Lead into a Contact, an Account and optionally a Deal, and it decides whether to create that Account from whether the Company field happened to be filled in. For anyone selling to individuals that quietly produces empty company records and a pipeline nobody trusts, so we set the conversion mapping, the layouts and the automation around your actual sales motion before anything starts writing.
Zoho meters the API in credits weighted by how expensive each operation is, not in flat calls, and the daily allowance is a base amount plus an amount per user licence you own. A chatty sync therefore runs a five-seat org dry long before it troubles a fifty-seat one, so we batch and page the writes, cache what does not change, and alert on climbing usage or a failed call before records stop arriving.
It matters more than anything else on this page. Zoho runs separate data centres for the US, EU, India, Australia, Japan, Canada and others, and each one has its own accounts server and its own API domain, holding only the organisations registered there. Code pointed at the US domain simply cannot see an EU org, and a client ID registered in one region does not carry its secret to another, so the classic symptom is an integration that authorises without complaint and then returns nothing at all. We take the accounts server and API domain Zoho returns during token exchange and use those, rather than hardcoding a URL, which also means the build survives if Zoho ever migrates your organisation to a different region.
All three have a job and choosing wrong is expensive in a different way each time. Deluge is Zoho’s own scripting language and it belongs inside the CRM, for the things that must happen the instant a record saves. Zoho Flow is the visual builder for app-to-app steps, and it bills by task, so a flow that fires on every record update costs you on every record update whether or not anything needed doing. Anything long-running, high-volume or reaching across several systems at once we build outside Zoho and call in, because Deluge functions are bounded by statements executed and by a timeout that differs depending on whether the function was triggered by a button, a workflow or a schedule.
Partly, and the gap between partly and fully is where most of our Zoho work comes from. The native integrations are genuine, but they are opinionated: CRM to Books syncs a fixed set of fields, only the first Books organisation you connect gets two-way sync, certain Books system fields have no CRM equivalent at all, and edits made on the accounts side do not always find their way back. You cannot reshape those mappings, only work around them. Worth saying plainly: Zoho One solves the licensing problem and roughly half the integration problem, and the half it leaves is the half people notice.
It depends far more on shape than on volume. Zoho does not count calls, it deducts credits weighted by how expensive each operation is, so a bulk write costs more than reading a record, and a lead conversion or a merge costs more again. Your daily allowance sits in a rolling 24-hour window and scales with the number of user licences you hold, which catches small teams out, since the same integration that is comfortable on a fifty-seat org can exhaust a five-seat one. There is also a cap on how many calls you can have in flight at once, which matters if a voice agent and a nightly sync happen to overlap. We design for it up front and alert on usage, rather than discovering the ceiling on the day a week of leads goes missing.
Sometimes, and we would rather tell you before you buy than after. Zoho gates capability by edition instead of selling it as add-ons, so custom functions, sandboxes and the deeper automation sit on the higher tiers, and each module has a cap on how many workflow rules can be active at once that rises as you go up. If you are on a lower edition and the job needs a function to run on save, the real choice is an upgrade or building the same logic outside Zoho and calling into it. We will work out which is cheaper over a year for your case, because the upgrade is per seat, per month, forever, and the external build usually is not.
Properly, only if your edition includes a sandbox, and that is a higher-tier feature, with a full copy of production reserved for the top tier. Below that there is no isolated copy of your organisation to work in, so we build against a separate free developer org, keep every change small and reversible, and schedule anything with teeth outside your working hours. That is a real weakness of Zoho at the lower editions and it is worth knowing before you commit to a plan. Even where a sandbox exists, deploying back to production does not carry everything across cleanly, since some layout properties are dropped and webhook URLs do not switch environment on their own, so the last step is always a human check.
Three things, honestly. Deluge is Zoho’s own language, it is written in a browser, and there is no native version control, so a change has no diff and no branch behind it unless we keep the source in a repository ourselves and treat the CRM as somewhere we deploy to. The pool of people who know Deluge is much smaller than for JavaScript or Python, which matters on the day you replace us, and it is one reason we keep as much logic as we sensibly can in portable code. And the breadth cuts both ways: every extra Zoho app is another data model, another API and another set of limits to keep aligned, so a firm that needs a CRM and an accounting package is often better served by two good tools than by a suite of adequate ones. If the only reason you are considering Zoho is the seat price, that is a weak reason on its own.
Send us your edition, your data centre and the list of Zoho apps you run. We will tell you what joins natively, what needs building, and what is not worth doing at all.
Book a Free Demo