Akshhayaa SChief Executive Officer
Here is a conversation we have had more than once. A requirement is agreed in week one: the approval has to route differently for one category of purchase. Everyone nods — the product does approvals. The build starts. In week six someone discovers that the particular form of routing needed sits one tier up from the licence the client holds, and the project stops while a procurement decision is made that should have been made at the start.
Nobody was careless. The requirement was written against a product name, and product names are not where capability lives.
Why this keeps happening
When you evaluate software you read the product page. Product pages describe what the product can do, because that is their job — they are written for the whole range, not for the tier you are about to buy. The comparison table that actually matters is one click further on, and it is long and dull, so most people scan it rather than read it against their own list.
Then scoping happens in a meeting, verbally, against names. "We will do that in CRM." "Books will handle the invoicing." Both true at the product level. Neither is a commitment anyone has checked.
What tends to sit behind an edition
This varies by product and changes over time, so treat it as where to look rather than as a list of answers.
- Depth of customisation — how many custom fields, modules, layouts or validation rules you may create, and which of them exist at all.
- Automation allowances — the number of workflows, scheduled functions, webhooks or blueprints, which is usually a count rather than a yes or no.
- User types and permission granularity — how finely you can separate who sees what, which matters most to organisations with layered approvals.
- API call allowances — the thing that decides whether a high-volume integration is comfortable or constantly near its ceiling.
- Environments and governance — sandboxes, audit trails and deployment controls, which enterprise buyers assume and smaller tiers may not carry.
The bundle trap
A bundle is not simply every product at the edition you would otherwise buy. The edition of a given app inside a suite is a specific one, and it may sit below the standalone tier you had in mind for that app. This is not a trick — it is how bundles are priced — but it catches people who move from "we will buy CRM Enterprise" to "we will take the bundle, it includes CRM" without re-checking the one feature the whole requirement rested on.
If a single capability is load-bearing for your project, verify it against the exact edition in the exact package you are buying. Not the product. Not the bundle's summary page.
How to check properly
This takes an afternoon and saves weeks.
- Write down the requirements that are genuinely non-negotiable. Usually there are five or six, not thirty. Everything else can flex.
- For each one, name the specific feature that delivers it — not the product, the feature. If nobody can name it, that requirement is not yet understood well enough to price.
- Find each feature in the vendor's own edition comparison, and write the edition beside it. Screenshot it, with the date.
- Take the highest edition your list demands. That is your floor, and it is often driven by one requirement rather than by the general level of the rest.
- Ask whether that one requirement is worth the tier it forces. Sometimes the honest answer is to change the process instead, and that is a legitimate outcome of discovery rather than a failure of it.
Whose job this is
Ours, and we do it during discovery rather than after. Every engagement produces a feasibility document before any build begins, and the edition each must-have depends on is written into it alongside a recommended plan. If a requirement forces a tier you were not expecting, we would rather tell you in week one, when it is a budget conversation, than in week six, when it is a delay.
Editions change. Features move between tiers, new tiers appear, and packaging is revised. Whatever you check today, check it again when you buy — and confirm the current terms with Zoho rather than relying on a blog post, this one included.
Scoping something now? Send us the five requirements you cannot compromise on and we will tell you what edition they imply, before you talk to anyone about price.