When a large organisation with 250+ staff members needs a Zoho Partner to handle an implementation project, just being a Zoho expert isn’t enough. Your partner needs to understand how to use that expertise at scale.

A note on the words

Software conversations are full of terms that mean very little outside the industry, so it is worth translating the ones that come up most often.

Any partner should be willing to explain these things in ordinary language. If the explanations only make sense to people who already work in software, that is worth noticing early, because you will be having these conversations for months.

What changes when an organisation gets large

Under the Companies Act 2006, a business is classed as large once it goes beyond 250 employees, and while the number itself is arbitrary, something real does shift around there.

It is rarely about the number of people logging in, since Zoho copes with that comfortably. What changes is the nature of the work.

What changes most of all is that departments stop wanting the same things. Finance quite reasonably wants sign-off steps that operations find slow.

The sales team wants visibility that another department cannot give them for good reasons of their own. Someone makes a sensible improvement in one team and it has consequences elsewhere that nobody predicted, because nobody had the whole picture written down.

Add a few years of history and you end up with processes that no one designed but everybody now relies on.

Two things tend to rise to the top of the agenda at this point, and they are worth naming because they are what most large organisations are actually buying.

The first is visibility. Leadership wants to see what is happening across the whole organisation without waiting a week for someone to assemble it by hand, and to know that the numbers in front of them are current and consistent wherever they came from.

Reporting that pulls from one source, rather than four spreadsheets that disagree, is often the single biggest change people notice.

The second is clarity in how the work runs. Large organisations are complicated by nature, but the day to day experience of working in one does not have to feel complicated.

When each step is clear, when information arrives where it is needed without being chased, and when the system reflects how people genuinely work, the complexity stays in the background where it belongs.

How Zoho compares to Salesforce, HubSpot and Microsoft Dynamics

These are the comparisons most large organisations are actually making, so they are worth setting out honestly rather than selectively. All four are capable platforms, and the decision is rarely settled on price. It is settled on what each one can do for the way your organisation actually works.

What each platform is built to do

The honest case for each of the others

A comparison that finds no merit in the alternatives is not worth reading.

Salesforce holds roughly a quarter of the CRM market and has an ecosystem nothing else matches, with several thousand applications available including deep options for financial services, healthcare and other regulated sectors. If your requirement is unusually specialised, something is more likely to exist already.

Its AI governance is more mature, which matters where regulators take an interest in how customer information is used. The pool of experienced administrators is also far larger, so recruiting internally is easier.

Microsoft Dynamics 365 has an obvious advantage if you are already committed to Microsoft, which most UK organisations of this size are.

It sits alongside Microsoft 365, Teams, Power BI and the Power Platform, and a Microsoft-centred IT function will find it familiar. It is the natural choice where you need full enterprise resource planning rather than CRM alone, since finance and supply chain sit in the same family.

The trade offs are licensing, where each additional application adds cost per user, and implementation timelines that commonly run six to twelve months or more on larger rollouts.

HubSpot is the most straightforward of the four to use, and adoption tends to be quicker as a result. If marketing is the centre of what you are buying and your processes are broadly consistent across the organisation, it is a strong choice.

It is less accommodating when a department needs something genuinely unusual.

Where Zoho tends to win for large businesses

The breadth is included rather than assembled. Sales, support, finance, HR, analytics and marketing come from one vendor and connect natively.

For a large organisation that means fewer contracts, fewer renewals to negotiate and considerably less work simply to make your own systems talk to one another. With the others, that breadth is usually bought module by module.

The flexibility is genuinely useful at this size. When each department works differently, being able to build custom modules and shape each team’s setup around its own way of working matters more than any feature list.

Zoho allows that without the specialist overhead the others tend to require.

The independence matters too. Zoho is designed to be adjustable by capable people within the business rather than only by certified specialists, so with the right training your own team can make routine changes rather than raising a ticket or paying an hourly rate every time something needs adjusting.

Enterprise CRM platform cost considerations

Cost should not decide this, but it is worth being straight about it since the differences are substantial. At comparable enterprise tiers, Zoho is the least expensive of the four on licensing. Dynamics sits at roughly two and a half times, HubSpot at nearly four times, and Salesforce at more than four times.

The wider picture matters more than the licence line. Salesforce implementations at enterprise scale are commonly quoted at one and a half to three times annual licensing and usually need a dedicated administrator.

HubSpot charges a mandatory onboarding fee at Enterprise and layers contact tiers and AI credits on top of seats. Dynamics adds cost for each additional application per user. Industry reporting suggests a majority of large implementations across these platforms exceed their initial budget.

What this really affects is what you can afford to do properly. When licensing takes a smaller share, the money released usually funds the work that determines whether the system succeeds, which is the process mapping, the development and the training. A well implemented system beats a partially implemented one on any of these platforms, and budget is often what decides which you end up with.

Whichever you are considering, ask each vendor for a written three year total in sterling covering licences, implementation, support and the add-ons your requirements actually need, rather than working from a per user figure.

What CRM should a large company use?

If you are heavily regulated, need a specialised industry application that already exists, or intend to staff a substantial internal team, Salesforce deserves serious consideration.

If your organisation is deeply committed to Microsoft, or you need full resource planning alongside CRM, Dynamics 365 is the natural fit and the familiarity will help adoption.

If marketing sits at the centre of what you are buying and your processes are consistent across the business, HubSpot is quick to adopt and pleasant to use.

If you want several parts of the business working from one connected platform, need each department able to work its own way, and want your own people able to adjust the system as the organisation changes, Zoho is likely to serve you better at this size.

The decision worth avoiding is choosing any of them on brand recognition alone. Ask each to show you work at your scale, and compare what the whole thing costs over three years rather than what appears on a pricing page.

Your Zoho Partner should understand what’s already there

Large organisations rarely start with a blank page. There is usually a system that has been running for years, that few people fully understand any more, and that the business has quietly built habits around.

Older systems hide things, and they hide them in fairly predictable ways. Fields get repurposed and end up holding something quite different to what their label suggests. The same customer appears twice because someone spelled the name differently in 2019.

Information makes sense only if you knew the person who set it up, and that person left two jobs ago. Reports sit on assumptions that stopped being true some time ago and nobody noticed because the number still looked plausible.

None of this shows up in a demonstration. It shows up when the information moves.

So the first piece of work is not building anything at all. It is understanding what exists, what it is genuinely used for, and what can be left behind.

It is worth asking any partner how they approach the system you already have, because an answer that is only about the new one has skipped the part where the risk lives.

How Zoho Partners help large organisations plan

This is not the administrative bit to get through before the interesting work starts. At this size, it is the work.

The reasoning is simple enough. If nobody maps how each team actually operates, including the exceptions and the workarounds people have quietly invented, then what gets built reflects how the organisation believes it works rather than how it does.

The gap between those two things is where projects come unstuck, and it usually appears after go live, when the people doing the job discover the new system cannot handle the thing they do every Thursday afternoon.

Doing it properly means sitting with each team and walking through the work as it actually happens, treating the exceptions as important rather than as noise. It means finding out which steps exist because of policy and which exist because of habit, since those need handling quite differently.

It means asking what happens when someone is on leave, because that is usually where the undocumented workaround has been living for years.

We use structured process mapping workshops for this, using Liberty Spark, formerly known as Skore, which lets people see their own processes laid out visually and correct them before anything is built. Changing a diagram is considerably cheaper than changing a system that four hundred people are already using.

Whatever method a partner uses, the output should be something you can read and argue with. If you cannot follow your partner’s requirements document, there is a fair chance they cannot either.

Zoho Partners need to understand a large ecosystem

A large organisation is never running one system on its own. There is an accounting package, often Xero or Sage. There may be a stock, warehouse or resource planning system, an HR platform, a phone system, and sector specific software that nothing else replaces.

Connecting these well is where a great deal of the value sits. It is also where a fair amount of the risk sits, so it is worth asking a few direct questions.

Does information move in both directions or only one, since both is harder and usually what you actually want?

What happens if the connection stops working at two in the morning, and does anybody find out, or does it quietly fail and get discovered a fortnight later?

If the same record is changed in both systems at once, which one wins, and who made that decision? And is the connection built on something supported and documented, or on something only one person understands, because that becomes your problem eventually.

We build these connections directly against the systems involved, including large enterprise finance and resource planning platforms, and use scheduled updates into Zoho Analytics where reporting needs to draw on information held elsewhere.

The aim is straightforward enough: client information, pipeline and financial figures sitting together, so that the reporting leadership relies on comes from one place rather than being reassembled by hand each month.

It is always worth asking whether a partner has connected the particular products you use, rather than similar ones.

Data protection, access and who sees what

For an organisation of this size this matters as much as anything else in the project, and it is the part most often treated as a detail to sort out at the end.

It is not a detail. Under UK GDPR you remain accountable for personal information regardless of which system it happens to sit in, and a new system means new copies of it in new places.

Access is the practical heart of it. Permissions should reflect how the organisation is actually structured rather than what was quickest to set up, which in practice means each team can reach what it needs to do its work and nothing beyond that. Sales does not need HR records.

Support does not need salary information. Getting this right while the system is being designed is relatively straightforward, whereas going back and imposing it across a live system used by hundreds of people is considerably harder and rather more disruptive.

Alongside that sit a handful of questions worth answering deliberately rather than by default. What personal information are you holding, why, where does it now live, and how long are you keeping it, given that a migration is the natural moment to answer this properly because you are handling all of it anyway.

Financial information usually needs tighter access than anything else, along with a record of who changed what, so audit trails belong in the requirements rather than in a later phase. Every connection to another system is a route information travels along, so each one needs to be understood and written down.

Zoho offers UK and EU hosting, and which region your information sits in should be a decision you made rather than something discovered later. And with hundreds of staff, people join, move and leave constantly, so if removing access depends on somebody remembering, it will eventually not happen.

Worth asking any partner where this sits in their process. If it appears at the end, that tells you something useful.

Planning and managing the risk

Every large implementation carries risk. What separates one partner from another is whether it gets named at the start or discovered halfway through.

A properly planned programme tends to be phased, so the organisation is not asked to change everything at once and each part can settle before the next begins. Success gets defined in writing before work starts, because “it went well” means different things to different departments.

Responsibilities are named on both sides, including who decides when two departments want incompatible things, since that decision will be needed at some point. Testing involves the people who will actually use the system rather than only those who built it. Training is planned as part of the work rather than compressed into the final fortnight.

There is a way back at each stage. And when something slips, it gets reported early enough to do something about it, which is rather the point of reporting it at all.

The risks worth asking about specifically are information that does not reconcile, a department whose way of working turns out not to fit what was designed, a connection that behaves differently once it is live, and people quietly carrying on with the old system. All of these are manageable when they are planned for, and all of them are expensive when they are not.

A partner helps large organisations onboard their teams

A system that works perfectly and that nobody wants to use has not solved anything. This is the part of a large implementation that gets least attention in proposals and causes the most trouble in practice.

People are rarely resistant for no reason. They are usually busy, they have a way of working that gets them through the week, and they have often lived through a previous system that was imposed on them and made their job harder. Winning them over comes from involving them early enough that the system reflects how they actually work, which is another reason the process mapping conversations matter beyond simply gathering requirements.

When someone has been asked how they do their job and can see their answer reflected in what gets built, the conversation on launch day is a very different one.

It also helps enormously to have people within each team who understand the system properly, rather than one overworked person in IT holding all the knowledge. That is why we train towards independence rather than dependence. If your team wants to make their own adjustments, add a field, change a report, adapt a workflow as the business shifts, we will show them how and support them while they get comfortable.

Some organisations want to run most of it themselves and call us for the harder work. Others would rather we handled it. Both are entirely reasonable, and the right answer usually changes over time as confidence grows.

For ongoing support we offer A2Z Guardian, our managed service, which covers the day to day looking after of the system so your teams are not left working out what to do when something behaves unexpectedly. Whatever arrangement you choose, and whoever you choose it with, agree in writing before the work begins who you contact, how quickly they respond and what is included.

Underneath all of this sits something that is harder to put in a proposal. The partners worth having are interested in the business, not only the software. Understanding why a process exists, what pressure a department is under, what leadership is actually trying to achieve, all of that shapes better decisions than any amount of technical knowledge on its own.

A partner who only asks about systems will build you a system. A partner who asks about the business will build you something that helps it.

What should a large business ask their Zoho Partner?

Can you describe a project of a similar shape to ours? Shape matters more than size alone. Ask about the number of departments involved, what needed connecting to what, and what turned out to be harder than expected, since a partner who cannot name anything difficult has either had remarkable luck or is not telling you very much.

How do you gather requirements, and can we see an example? Redacted is fine. What you are looking for is a structured method and a document you can actually read.

Do you develop as well as configure? In other words, when a process genuinely does not fit the standard options, can they write something that does, and what do they build it in?

How do you handle moving our information, and how do you check it is right? Ask specifically about verification rather than transfer, because the transfer is the easy half.

What are your credentials? These are checkable rather than claimed, which is what makes them worth asking about.

How do you help our people take to it? Ask what they do about training, how they involve teams during the work rather than at the end, and whether they will teach your staff to make their own adjustments if that is what you want.

What happens after go live? Who you contact, how quickly they respond, and what is covered, all written down before you start. Ask whether a managed service is available if you would rather the day to day looking after sat with them.

How will this hold up in three years? Ask what happens if the organisation grows considerably, restructures or acquires another business, and what they would do differently now to make that easier later.

Is A2Z the right Zoho Partner for you?

We are a Zoho Premium Partner, the highest tier Zoho awards, which we have held since 2017, and we have delivered over 800 implementations across organisations of every size.

We develop as well as configure. We have a large in-house development team spanning a wide range of skills and technologies, which means we can put the right people on each piece of work rather than fitting the work to whoever is available. Where a process does not fit the standard options, we build the part that is missing rather than asking people to change how they work to suit the software.

Requirements gathering, process mapping and access design are treated as core parts of the work rather than preliminaries, and we use structured workshops with Liberty Spark, formerly Skore, so you can see and correct your own processes before anything gets built.

We also spend time on where a system is heading rather than only where it needs to be on launch day. That means asking what happens when the organisation doubles in size, opens somewhere new or takes on another business, and making choices now that will not need unpicking later.

It increasingly means artificial intelligence too, since Zoho has been building AI into its products steadily and there are practical uses in most large organisations, from summarising long email threads and drafting replies to spotting patterns in sales or support information that nobody has time to look for manually. The useful conversation is about which of these genuinely saves your teams time, rather than adding them because they are available.

On credentials, we are Cyber Essentials certified, listed on the G-Cloud 15 framework, and working towards ISO 27001 certification.

A few of the organisations we work with

Fred. Olsen Cruise Lines, a cruise line established in 1848, came to us having decided their existing customer database was too basic for what the business needed. We implemented Zoho CRM Plus, restructured and moved the information, which brought costs down and cut duplication, and brought guest and booking information together so it could be used properly. Their net promoter score and marketing returns both improved, and their CRM manager describes us as an extension of their workforce. Zoho published this one themselves.

StudyIn, formerly SI-UK and SI-Global, has one of the largest Zoho One user bases in Europe. Their Group Chief Technology Officer led a review of their existing system, looked at what the market offered, and selected Zoho One and A2Z Cloud on evidence rather than instinct. We worked through structured process mapping and solution design to shape the first phase, rather than starting to build on day one. They challenge us, ask questions and expect honest debate, which is a large part of why the programme works.

ITV PLC is an example of what is possible when scope allows for it. We built, launched and rolled out a system in six to seven weeks, which their Technology and Platforms team called a fantastic achievement.

Framtiden in Sweden took on Zoho One across the business at a point when it was not well known in their market. Their Chief Information Officer reported less administration and better information security as a result.

Whether an organisation has fifteen people or fifteen hundred, the work is the same in principle: understand how the business actually runs, build something that fits it, connect it to everything else, and make sure the people using it can see what they need. The scale changes what that takes. It does not change the approach.

If you would like to talk something through, we are happy to do that at any stage, including well before you are ready to commit to anything.