A three-week Zoho CRM build for a startup and a fourteen-week multi-plant Zoho Books rollout look nothing alike from the outside. Internally they run through the same sequence. The difference is not which phases happen — it is how much each phase needs, and which ones you are allowed to compress.
This is the flow we run, why each phase exists, and the failure that shows up when it gets skipped.
1. Discovery
We sit with the people who do the work, not only the people who sponsor the project. Front-desk staff, warehouse supervisors, and field reps know where the current process actually breaks, and that is rarely where the org chart suggests.
The output is a current-state map: how a lead, an order, a patient, or a shipment actually moves today, including the undocumented workaround everyone relies on.
What goes wrong when it's skipped: the system is built for the process as described in a meeting, not the process as performed, and adoption stalls in week two.
2. Requirement Analysis
Discovery tells you what happens. Requirement analysis decides what the system must do about it — and, just as importantly, what it will not do in this phase.
The deliverable is a written scope with an explicit "not now" list. That second list matters more than the first. A scope without one has no defence against the requests that arrive halfway through the build.
3. Solution Design
This is where the money is decided. Which Zoho apps, which modules, what the data model looks like, and — the question that quietly determines everything else — where each piece of information will live and which system owns it.
For a multi-branch or multi-plant business, the design decisions made here are the ones you cannot cheaply reverse later: one chart of accounts or several, one patient record or one per branch, units as records or units as a text field on a deal. In our multi-plant manufacturing engagement, the unified chart of accounts and item master were settled before a single row of data moved, precisely because reversing that decision post-migration would have meant doing the migration twice.
4. Configuration
Now the system gets built out of what Zoho already provides: pipelines, stages, fields, layouts, roles, approval rules, templates. This is the phase people picture when they imagine an implementation, and it is usually shorter than they expect — because good design makes configuration fast.
A useful discipline here is to justify every required field. A field that is mandatory but not used in a report, a rule, or a decision is pure adoption tax on your reps.
5. Customization
Everything the standard configuration cannot express: custom modules, Deluge functions, Zoho Creator applications, custom buttons and related lists.
Custom work is not a failure of planning — some processes genuinely have no out-of-the-box equivalent, like the credit-limit enforcement at the point of sale in our frozen foods distributor engagement. But custom work is code, and code needs an owner, documentation, and a plan for who maintains it in two years. If you are commissioning customization, ask that question before it is written, not after.
6. Integration
Connecting Zoho to the other systems the business runs on: the storefront, the marketplace, the payment gateway, the messaging channel, the legacy ERP nobody is ready to retire.
Integrations fail in production far more often than configuration does, because they depend on systems you do not control. Every integration we build gets three things that are easy to skip and painful to add later: retry handling, failure alerting, and a way to replay a failed sync without re-entering data by hand.
7. Testing
Not "does the button work" — does the business scenario complete end to end, including the ugly ones. A partially paid invoice. A split shipment. A customer who exists twice. An order that breaches a credit limit on a public holiday when the approver is away.
The right people to run this phase are the ones who will use the system, working through their own real scenarios. A test plan signed off by a project manager who will never touch the system afterwards proves very little.
8. Training
Role by role, in the system, with real data. Counselling staff, warehouse floor staff, and finance staff need different sessions, not one long generic walkthrough, because they care about different screens and will only retain what they will use on Monday.
Training is also the last honest chance to catch a design mistake. If three people in a session ask the same "but what about…" question, that is not a training gap; it is a requirements gap surfacing late. Take it seriously rather than answering it away.
9. Go Live
A phased cutover wherever the business allows it: smallest branch first, a few clients at a time, one billing cycle in parallel. Each wave carries its fixes into the next, so the biggest and least forgiving part of the business goes last, on the most-tested build.
Where a clean parallel run is possible — accounting, billing, reconciliation — run it. In our omnichannel retail engagement, automated payout reconciliation ran alongside the manual spreadsheet for two complete settlement cycles before finance was asked to trust it. That is two cycles of apparent duplication that bought a cutover with no argument attached.
10. Support
The first month after go-live generates more useful information about a system than the entire build did. Automations fire too often or not often enough. A validation rule that seemed reasonable blocks a legitimate order. A report everyone asked for turns out to be read by nobody.
Plan for a tuning window rather than treating post-launch changes as failures. Every engagement in our case studies includes one, because the alternative is a system that is technically live and quietly worked around.
How the phases compress
For a small, urgent project, phases do not disappear — they collapse into each other. Our early-stage SaaS engagement ran the whole flow in three weeks by scoping ruthlessly on day one: discovery and requirements in a single session, no customization at all, training as a founder walkthrough.
What you cannot do is compress by skipping the writing-down. The two-page scope still got written. The "not now" list still existed. That is what made three weeks achievable rather than reckless.
If you are planning a Zoho implementation and want a realistic read on which phases your situation actually needs, tell us what you're working with — we will be straight about where the time will go.