Get three quotes for a Zoho implementation and they will look alike. A number of hours, a list of applications, a list of things called deliverables, and a date. Read the assumptions section at the bottom and the three quotes stop looking alike, because that is where each partner has written down what they are not going to do.
This post is a map of a Zoho implementation as we scope it: what is in, what is usually out, and the one thing that decides whether the implementation works and appears on almost no quote as a line item. If you are choosing a partner, it is the list to read the assumptions against. We wrote separately about how to choose the partner; this is what to expect once you have.
Configuration is in every quote, because it is the visible work. For a CRM, that is modules, fields, layouts, pipelines, roles and profiles, workflows, assignment rules and the reports the sales manager asked for. For Books, it is the chart of accounts, tax, templates, bank feeds and the approval flow. For Inventory, Projects, Desk and the rest, the equivalent list. This is the work most partners are good at, it is the work that is easiest to estimate, and it is between a quarter and a half of the real engagement.
Basic training is usually in, as a number of sessions. Basic data import is usually in, as a number of records from a spreadsheet you provide. Go-live support is usually in, as a number of days after the switch. Those are the four things a quote prices, and if the assumptions section stopped there, quotes would be comparable.
The assumptions section is where the rest of the engagement lives, and it is written as things you will do or things that are not included.
The import is in scope. The data is not. Your customer records are in two systems and a spreadsheet, with duplicates, with fields that mean different things in each, with history that has to be attached to the right record. Deciding what a clean record is, merging the sources, mapping the fields and carrying the history is the part that takes the time, and a quote that says "client to provide data in the template" has put that work on you. We wrote a CRM data migration checklist because the list of what goes wrong here is long and predictable.
Zoho connects to Zoho well. The quote will say so. Your business also runs on a shop, a shipping tool, a payroll system, an industry application and a bank, and the quote will list those as "available via marketplace connector" or "phase two". A connector is a start; the join that carries the right facts in the right direction with the right master is the work, and for most companies it is a third of the engagement. Ask which integrations are priced, and what happens to the order that fails to sync at two in the morning.
Every field, pipeline stage, approval rule and automation encodes a decision about how the business works. Who owns a lead. When a quote needs a manager. What happens to an order that ships short. Which customer record wins when two disagree. The configuration cannot be built until those decisions are made, and the quote assumes they have been. They have not. In most companies they have never been written down, and different departments hold different answers.
Go-live is the beginning. The three months after are when the sales team finds the pipeline stages do not match how they sell, the accountant finds the tax setup missed a case, the warehouse finds the pick list is in the wrong order, and the automations that looked fine in testing fire on real data. A quote with five days of go-live support has priced the first week of a ninety-day period.
The item that decides the implementation is the process decisions, and it is missing from quotes because it is hard to price and harder to sell. It looks like meetings. It is the work.
Here is why. A Zoho application, or any business application, is a set of opinions about how work flows, expressed as fields and rules. If the opinions match how your business works, people use it. If they do not, people work around it, the data goes stale, and eighteen months later someone says the implementation failed. The implementation did not fail. The decisions were never made, so the configuration encoded the partner's guesses, and the guesses were wrong in the fifty places where your business is not generic.
Making the decisions means putting the people who do the work in a room with someone who knows what the application can hold, walking each process from start to end, and writing down every fork. It takes days per process. It produces a document that the configuration is built from and that the training is built from and that the first ninety days are measured against. No quote we have seen prices it by name, and a quote that does not price it has either hidden it inside the configuration hours, where it will be squeezed, or assumed you will do it, which you will not, because nobody in your company has done it before.
We start with a no-risk discovery, which is the decisions work in miniature: a few days walking the processes that matter most, finding the forks, reading the data, listing the integrations. It ends with a written scope that names what is in, what is out and why, and a guaranteed estimate for what is in. The estimate is ours to hold, which is why the scope is precise. We would rather write "the shipping integration is out of scope and here is what that means for the warehouse" than leave it in an assumptions section for you to find in month four.
The scope has six parts, and each one is either in with a price or out with a reason: the process decisions, written down; the configuration built from them; the data, cleaned and carried; the integrations, with the master for each fact named; the training, built from the decisions document; and the first ninety days, with a named person and a weekly review. A quote that prices only the second and fifth is pricing a third of the engagement, and the difference will arrive as change orders or as an implementation nobody uses.
For a sense of what the numbers look like for the CRM alone, our honest picture of Zoho CRM implementation cost breaks the figure down. The suite-wide version is larger mainly because the integrations and the decisions multiply with each application.
We do not own your business processes; you do. We are accountable for getting them decided and written down before anything is built, for the configuration matching the document, for the data arriving clean, for each integration having a named master and a named failure path, and for the estimate holding. If a decision changes after go-live, that is a change, and it is priced as one, but it is priced against a document rather than against a memory of a meeting.
A Zoho implementation is six things. Quotes price two of them and put the other four in the assumptions. The one that decides the outcome, the process decisions, is the one nobody quotes for, because it looks like meetings and it is the actual work. Read the assumptions section first, ask which of the six is priced, and choose the partner whose scope says what is out and why.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
Before and After: A Real Zoho Implementation at an IT Services Firm (article)
Your Forecast Is Wrong Because Nobody Configured A Pipeline | Zoho CRM Stage Probability (video)
Nobody Is Allowed To Change Production | Zoho CRM Sandbox And Change Control (video)
More than most quotes say. Expect the process owners to spend several hours a week during discovery and design making decisions, the data owner to spend days cleaning and validating records, and every user to spend time in training and testing. A rough planning rule is that the client's effort is comparable to the partner's during discovery and testing, and smaller during the build.
Rewrite each quote into the same six lines: process decisions, configuration, data, integrations, training, and the first ninety days, and mark for each whether it is priced, assumed to be the client's work, or excluded. The cheapest quote usually has the most lines in the second and third columns. Then ask each partner what happens when an item in those columns turns out to be needed.
Typically a fixed number of days after cutover for fixing defects in what was built. It usually does not cover changes to the process, new reports the team discovers it needs, or the adjustments that come from running real data through the configuration for the first time. Ask for a named person and a weekly review through the first ninety days, priced as a line rather than left as goodwill.
The client owns the decisions about what a clean record is and which source wins when two disagree; the partner owns executing the cleanup, mapping, and import to that definition and proving the result. A quote that says the client will provide clean data in the template has moved the execution to you as well. Agree in writing who does the deduplication and the validation, and how the result is checked.
A change order is work added after the scope is signed, priced separately. Change orders are legitimate when a decision changes, and a symptom of a thin scope when they arrive weekly for things that were always needed. The protection is a scope that names what is out and why, a decisions document the configuration is built from, and a rule that a change is priced against that document.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
