Second attempt. Eleven apps, 500 users, no surprises.

At a glance

Scale: 500 users across sales, delivery, finance, HR and support
Context: A previous ERP implementation had not landed
Industry: Professional services — advisory, research and programme delivery
Zoho products: Zoho One — CRM, Books, Projects, People, Payroll, Expense, Desk, Sign, WorkDrive, Bookings and Analytics
Custom & integration work: Custom CRM–Projects–Books sync replacing the native integration, Microsoft 365 and Teams integration, Tally migration, project migration from a legacy custom application, and an entity-tagging structure built for the group's later country rollouts
Engagement: Six-month retainer with a dedicated Absoft team — senior Zoho developer, solution consultants across each application, and a project manager

Zoho One Zoho CRM Zoho Books Zoho Projects Dedicated Team

Been through an implementation that didn't land? The second one is a different conversation. Get a free automation audit

The Challenge

Five systems that didn't talk, and an organisation with every reason to doubt that the sixth would fix it.

A failed implementation behind them. An earlier ERP rollout had not landed. That changes everything about how a project like this has to be run. Nobody was taking a capability claim at face value, every timeline was read as optimism, and the internal sponsors had already spent their credibility once. The trust problem had to be solved before the systems problem was worth starting.
Sales, delivery and finance never met. A deal closed in one system, the project was delivered in a separate custom application, and the invoice came out of Tally. Nobody could see what a project had cost against what it billed without assembling it by hand.
Delivery data lived outside the business. Projects, timesheets and budgets sat in a legacy custom app with no route into finance. Utilisation and project profitability were quarterly exercises rather than a report.
Five hundred users, no shared process. Different teams worked differently because nothing enforced a process. Quotes were raised inconsistently, project dates moved without control, and timesheets didn't reliably tie to the project they belonged to.
The group had more countries coming, and Microsoft 365 wasn't moving. Email, calendar, Teams and SharePoint were embedded and staying. Anything built without room for other legal entities — or that demanded the communication stack change — would have to be torn up later.

What We Built

Eleven Zoho One applications, delivered as one system rather than eleven projects. Zoho One is the backbone. The custom work is the chain that connects sales to delivery to finance, and the structure that lets the rest of the group join later.

Sales, delivery and finance as one chain

Zoho CRM configured from the ground up — organisation setup, domain mapping, shift hours, email authentication, fiscal year and currencies, with leads, contacts, accounts, deals and activities enabled and a defined deal pipeline.
Closing a deal creates the project, with field mapping preserved, so delivery starts from the sale rather than a re-keyed brief.
Project creation flows through to Zoho Books, so financial tracking follows delivery instead of being reconstructed at month end.
Customers sync from CRM into Books with duplicate prevention.
Existing customer data imported, de-duplicated and cleansed before go-live.

Delivery, with governance built in

A four-level project structure — project, milestone, task list, task and subtask — on a coded numbering format, with project templates for the main delivery types.
Timesheets synced to projects only, with custom fields where different programmes need different data captured against the same task.
Controls that hold the process: project managers can't change project dates, quotes convert from draft to actual under control, and no quote is raised without a contract behind it.
Delivery data migrated out of the legacy custom application into Zoho Projects.

Finance off Tally

Zoho Books configured with chart of accounts, tax setup and compliance, including three GST registrations held under a single organisation.
Migration from Tally for the current financial year, with balances validated before cutover.
Entity-wise expense categories and policies, two levels of approval, and expense claims routing to the correct place in Books based on selection.
Zoho Analytics connecting CRM, Books, Projects and Expense for dashboards across finance, sales and operations, including custom SQL reporting.

People and support

Zoho People with org structure, departments, leave policies, holidays and working hours, employee database imported, and an employee self-service portal.
Payroll configured natively with statutory compliance, tested through a full payroll cycle before going live.
Resignation routing through Zoho People to the relevant departments, plus survey forms and training resources for staff.
Zoho Desk with departments for support, advisory and training, SLAs and workflows.

Documents, contracts and calendars — around Microsoft 365, not instead of it

Zoho WorkDrive with team folders, access rules and versioning, integrated with CRM so a deal opens a folder already structured as a proposal template.
Zoho Sign for contract generation and sending directly from the deal.
Zoho Bookings with staff calendar sync, integrated with Microsoft 365 calendar and Teams.

Built for the countries that come next

A legal-entity tag designed into leads, deals, accounts, projects, tickets, expenses and folders from the start, even though this deployment covered one operation.
Entity-based views and filters, and a data structure that lets additional Books organisations and entities be added as a rollout rather than a rebuild.

Results

One system for 500 users. Sales, delivery, finance, people and support connected instead of five tools and a spreadsheet between them.
Finance can see delivery. A closed deal becomes a project becomes a tracked financial record, without a re-key at any step.
Process is enforced, not requested. Controlled project dates, a real quote-to-contract sequence, and timesheets that tie to the project.
Off Tally and off the legacy app, with current-year balances and delivery history migrated and validated.
Microsoft 365 stayed exactly where it was.
The next country is a rollout, not a rebuild.

Why It Worked

We built the entity structure before anybody needed it.

This deployment covered one operation, and it would have been quicker to model it that way. We didn't, because the group has other countries and the entity tag has to exist on the lead before it can ever exist on the invoice — everything downstream inherits it. Retrofitting that later is not a configuration change, it is a migration. One field, decided at the start, is the difference between the next country being a rollout and the next country being a rebuild. The client paid nothing extra for it and it is the most valuable decision on the project.

But the decision that actually mattered came earlier, and it was about the last implementation rather than this one. A client who has been through a rollout that didn't land is not a harder client to sell to. They are a harder client to sell to badly. They ask what happens when it goes wrong, they want the limitations before the contract, and they have learned to read a confident timeline as a warning. So we wrote down what Zoho could not do while we were still quoting. Payroll isn't available in every country the group operates in. Foreign remittance has to be logged manually. Budgeting and timesheet automation stayed manual in this phase, deliberately, so they could judge from real use whether automating it was worth paying for. Every one of those is uncomfortable to say during a sales conversation. All of them are cheaper to say then than in month five, and for this client they were the only things that made the rest of the proposal believable. Putting the plan in writing before changing anything is also what got a stalled telehealth rollout moving again.

The third decision was refusing to touch Microsoft 365. Email, calendar, Teams and SharePoint were staying, and there is always a version of this conversation where a Zoho partner suggests consolidating those too. It would have been more revenue and a worse outcome. A 500-user rollout succeeds or fails on adoption — and a workforce that has already survived one implementation that didn't land has a lower tolerance for disruption, not a higher one. Asking them to change where they read their email on the same day you change how they log a timesheet is how you lose the room twice.

The retainer is what let all of that hold. Eleven applications and a scope that sharpens as you learn the business is not a fixed-price shape. A dedicated team — senior developer, consultants per application, a project manager — meant priorities could move between streams without renegotiating anything, and running the streams in parallel rather than one after another took the realistic duration from around thirty weeks to roughly fifteen. Two embedded developers carried the build for a global travel membership club the same way.

Frequently asked questions

We've had a failed implementation before. How do you de-risk this one?

By being specific about what can go wrong before you sign, not after. Concretely: the platform's limitations go in the proposal, in writing, including the things it can't do for you. Scope is split into streams with pilots, so one function proves the model before it reaches everyone. Nothing that already works gets replaced without a reason — a failed rollout usually means your people have low tolerance for change, so you spend that tolerance only where it buys something. And you ask the partner who owns the decision when a date slips. If the answer to that is vague, you already know how the project ends.

Can Zoho One realistically run a 500-user organisation?

Yes, and the platform is rarely the constraint at that size. Adoption is. Eleven applications landing on 500 people needs sequencing, pilots and training per function — the technical build is the smaller half of the work.

Should we move off Microsoft 365 if we adopt Zoho One?

Usually not, and be wary of anyone who says otherwise. Zoho integrates with Microsoft 365 calendar, mail and Teams. Changing where people read their email at the same time as changing how they work is the fastest way to lose adoption on a large rollout.

We operate in several countries. Should we build for that on day one?

Build the structure, roll out one operation first. The entity tag needs to exist across your records from the beginning because everything downstream inherits it, but attempting every country simultaneously multiplies the risk. Design for all, deploy in sequence.

Does the standard Zoho Projects to Books integration always apply?

No. Depending on how your Projects instance and Books organisations are provisioned, the native integration may not span them, and a custom integration is required. Ask any partner this specific question early — the answer tells you whether they've delivered this shape before.

Can we migrate from Tally to Zoho Books?

Yes. The practical approach is current financial year with validated opening balances rather than full history, which keeps the cutover clean. Full historical migration is a separate exercise priced on data volume, and it should be quoted separately rather than folded in.

Why a retainer rather than a fixed-price implementation?

Because the shape of the work changes as you learn the business. On a fixed scope you spend the back half arguing about change requests. A dedicated team lets priorities move between streams, and the people in month six already know why a rule exists. For a single-app implementation with a settled scope, fixed price is usually better — we'll tell you which one your project is.

Facing the same challenge?

If your sales, delivery and finance run on systems that don't talk — or you've been through an implementation that didn't land and need the next one to be different — we'll show you what one operating model looks like at your scale. Start with a free automation audit. Get a free automation audit