New from Debox — 100 Ops. SOPs that actually get followed.See how it works →

Technology consulting · Pharma logistics · Mumbai

They asked us to build an ERP. We told them not to.

Parazelsus India moves temperature-controlled pharmaceuticals across 243 cities. What they needed was not custom software — it was their own operating logic written down precisely enough that a system could enforce it.
Client Parazelsus India (opens in a new tab)Engaged From January 2022Concluded After implementation handoverScope Scoping, platform build, process, training
Order volume+15%Additional volume handled on the same team, once the data made the bottlenecks visible. Client-reported.
What they asked forCustom ERPZohoWe recommended a configured platform instead of a custom build, at a fraction of the cost.
Network covered243 cities12 logistics nodes, 450 transport routes and 5,000 distributors, all running through one system.
01

The short version

Parazelsus India is the Indian arm of a Swiss-founded group, moving cold-chain and ambient pharmaceuticals through 12 logistics nodes to 5,000 distributors. The chairman and CEO wanted a platform to run full-truckload operations and warehouse leasing digitally. They came to us asking for a custom ERP. We told them a custom build was the expensive way to solve their problem, recommended configuring on Zoho instead, and spent the engagement doing the part that actually mattered — turning how the operation works into rules a system can enforce. They went on to handle 15% more order volume without adding people.

02

The expensive answer and the correct one

A company that has outgrown its spreadsheets usually concludes it needs custom software. It is a reasonable inference and it is usually wrong, because the difficulty is almost never the software. It is that nobody has ever written down exactly what the business does, in the order it does it, with the conditions that apply at each step.

Until that exists, a custom build is just an expensive way to discover it — you find the missing rules during user acceptance testing, at the worst possible moment and the highest possible cost. Once it exists, you frequently find you do not need a custom build at all.

The hard part of an operations platform is not writing the code. It is getting the operation described precisely enough that code becomes possible. Do that first and the build gets cheaper, whoever does it.

So we recommended Zoho, and we said so before we had a contract that depended on building something larger.

03

What the operation actually required

We worked through the operation with the Head of Operations and the core team — how things were tracked, where they went wrong, which numbers mattered.

Two requirements came out of it. The process had to be simplified to the point where the correct action at each step was obvious. And it needed control points that could actually be checked, rather than steps everyone agreed were important and nobody could evidence.

This matters more in cold chain than in most industries. A missed temperature reading or an unrecorded seal number is not an administrative gap — it is a consignment that may no longer be saleable and a compliance record that cannot be reconstructed after the fact.

So the logic went into the platform rather than into the operator. Every transaction type and scenario, with its own rules, validations and conditions, down to individual fields where it mattered — and the system proposing the next applicable step rather than expecting someone to remember it.

In an operation where errors are expensive, the goal is not to train people to be careful. It is to build a system in which the careless path is unavailable.

04

What we built

01
Enquiry through to order: vendor and customer quote management and approval, with team-level visibility and central oversight across every order.
02
Contract and vehicle placement against contracted rates — fixed route, rate per kilometre, rate per kilogram and the rest, each with its own calculation logic.
03
Order confirmation, vehicle mapping, reporting, pre-loading vehicle check, and loading completion with seal details and mandatory documents captured at the point of loading.
04
Lorry receipt generation, manual or digital, multiple per placed vehicle.
05
Delivery tracking, electronic proofs of delivery, temperature reports where applicable, and receipt of the original POD against each individual LR.
06
Invoice value calculated for customer and vendor per trip, with generation and receipt status tracked on both sides.
07
A vehicle pool model, so contracted vehicles could be allocated between clients or released to an on-demand enquiry.
08
Warehouse re-leasing and carrying-and-forwarding modules across multiple locations.
09
Triggered emails and ready-to-use document templates.
10
A customer portal — secured access to LR and order status, a personalised dashboard, and history of orders, enquiries and invoicing without anyone at Parazelsus being asked.

Item ten is the one that changes the working day. A logistics operator’s time disappears into status enquiries. Answering them once, in software, gives it back.

Logistics nodes
12
Cities covered
243+
Transport routes
450
Distributors
5,000
05

What it produced

MeasureResultBasis
Order volume handled+15%Additional volume managed with no increase in team size, after process improvements the platform’s data made visible. Client-reported.
ReportingautomatedCollation, analysis and reporting generated by the system rather than assembled manually.
Modules delivered10Enquiry to invoice, plus vehicle pool, warehouse re-leasing, carrying and forwarding, and the customer portal. Our own project records.
Build approachconfiguredZoho platform rather than a custom ERP, on our recommendation and against the client’s original brief.

How to read this

The 15% is the client’s figure. We had no access to Parazelsus’s financial or operational reporting after handover and did not audit it. What we can evidence from our own records is the scope, the modules and the approach.

The platform did not create the improvement directly. What it did was make the operation visible, and the team then found the bottlenecks and fixed them. That distinction matters: software does not remove waste, it shows you where the waste is. The improvement was theirs.

We are not claiming a cost saving figure. Configuring on Zoho was materially cheaper than a custom ERP would have been, but we never scoped the custom alternative in detail, so we have no comparison to publish. We recommended the cheaper route on judgement, not on a costed model.

06

How it ended

We built the platform, supported the implementation, trained the teams on the processes behind it, and then handed it over. Parazelsus took it in-house and has run it since.

That is the intended shape of this kind of engagement. An operations platform that still needs the firm that built it is a dependency dressed up as a deliverable.

07

Constraints that shaped the work

Choosing a configured platform over a custom build is a trade, not a free win. It caps how far the system can eventually be pushed, and it ties the client to a vendor’s roadmap and pricing. For an operation of this size and shape it was clearly the right call. For a business with genuinely unusual requirements or an intention to sell the software itself, it would not be, and we would say so.

The bigger limitation is what we know about what happened afterwards. We handed over and stepped back, which was correct, and it means the only outcome we can report is one the client told us. A short review at six and twelve months would have cost very little and would have given both sides something firmer than a recollection.

In their words

We approached Debox for developing an ERP for our operational processes, books of accounts and B2B lead management. Debox recommended a cost effective solution on Zoho platform. I must appreciate their understanding about the operational processes, converting them into algorithms which not only have automated the transactions but also with controls to minimise the human error.

Kaustubh Kulkarni — Head of Operations, Parazelsus India

If you are about to commission custom software

Write the operation down first — every transaction type, every condition, every point where somebody currently decides something on judgement. Do it before you brief a developer, not during their user acceptance testing.

You will find one of two things. Either the requirement is genuinely unusual and the custom build is justified, or the reason nothing off-the-shelf seemed to fit was that nobody had ever specified what needed fitting. In our experience the second is far more common, and it is a much cheaper problem to have.

Measurement note. Scope, modules and approach are from our own project records. The additional order volume handled is a figure reported to us by the client and was not independently audited by us. Network figures — nodes, cities, routes and distributors — are the client’s own published description of their operation.