The industrial belt around Kolkata — Howrah, Dankuni, Uluberia, Durgapur, Asansol, Haldia — is full of companies doing ₹50 crore to ₹500 crore of business on systems held together by three key people and a shared drive. Nothing is broken exactly. Month-end simply takes eleven days, three departments bring different numbers to the same meeting, and two people re-type orders from email into Tally until nine at night.
This is a practical guide to deciding whether an ERP or CRM programme is justified, what to build versus buy, and how to sequence it so it does not become one of the failed implementations everyone in the region can name.
The state most Bengal businesses are actually in
A recognisable pattern: Tally for accounts, because the CA knows it and it works. Between six and forty Excel files holding everything Tally does not — pricing, dispatch planning, production logs, dealer schemes, outstanding follow-up. A WhatsApp group where the actual decisions happen. And two or three people who are the only ones who understand how the pieces connect.
This arrangement is not stupid. Each piece solved a real problem faster than a formal system would have. But its cost curve bends sharply upward with volume: re-keying grows linearly, error rate grows, month-end lengthens, and the number of questions that simply cannot be answered — which customer is profitable, which SKU loses money, why dispatch slipped in March — grows too.
The other cost is concentration risk. A company with a single point of failure who has a notice period is carrying a risk nobody has priced.
When to buy, and when to build
Buy if your processes are conventional. An established product with a large user base will be cheaper, faster and better supported than anything custom, and the certified-consultant ecosystem is a genuine asset. We recommend this more often than clients expect.
Build when your process is genuinely a competitive advantage, when you have a workflow no product models, or when per-user licence costs across a large field team exceed a build over three years. In practice, custom most often wins for mid-sized manufacturers with heavy job work, multi-GSTIN operations and unusual costing needs.
The way to decide is arithmetic rather than opinion: map every process, attach the person-hours it consumes monthly and the money that leaks through it annually, and rank. Then compare the top items against what a package would cost to configure to fit.
| Process | Monthly hours | Annual error cost | Priority |
|---|---|---|---|
| Order entry from email and WhatsApp into Tally | 186 | ₹8.4 L in pricing errors | 1 |
| Dispatch planning across three warehouses | 94 | ₹5.1 L detention and re-routing | 2 |
| Monthly MIS from twelve spreadsheets | 72 | Decisions three weeks late | 3 |
| Field inspection reporting on paper | 61 | ₹2.2 L disputed claims | 4 |
| Vendor invoice matching | 48 | ₹1.6 L duplicate payment | 5 |
What Indian manufacturing needs that packages model badly
Job work is the clearest example. Material goes out under a challan, comes back partly as finished goods and partly as scrap, and accountability must hold across the boundary for both GST and costing. Packages treat this as an extension; it needs to be a core inventory state, or the stock report never tells the truth about what is physically where.
Multi-GSTIN operation is similar. A company with plants in West Bengal and Odisha moves stock between them as taxable transfers with e-way bills, and consolidated reporting must net that out. Built in from the start, it works. Bolted on, consolidated numbers get assembled manually in Excel forever.
Then the small things that are enormous in practice: weighbridge integration with tare and moisture deduction, LR and transporter tracking on every dispatch, quality claims settled as credit notes against historic invoices, dealer schemes on quarterly slabs with retrospective adjustment, and cash discount policies that vary by customer. Each is a day of design and saves a hundred days of workaround.
Why CRM adoption fails here specifically
The pattern is reliable: the CRM is bought, configured over three months, launched with a training session, used properly for about six weeks, and then the deals live in the salesperson's head again.
The cause is almost never laziness. It is that the CRM was designed for a generic funnel that does not resemble how the company sells. Where a sale involves a site visit, a technical drawing, three revisions of a quotation, a sample approval and a credit decision, a tool built around lead-opportunity-closed adds work and returns nothing.
The second cause is WhatsApp. In Bengal B2B, the enquiry arrives on WhatsApp, the drawing is shared on WhatsApp, the negotiation happens on WhatsApp — and then someone is expected to summarise it into a CRM. They do not. Integrating through the WhatsApp Business API so conversations attach to the deal automatically is the single change that most improves adoption.
Third: build features that help the salesperson before features that help management. Instant quotations, price and stock lookup, customer ledger. Reporting then fills itself as a by-product of usage rather than being a separate task.
In practice
Sequencing an implementation that does not fail
Never big-bang. Everything changing on one date, with nobody having used the system for real, produces a first month of chaos that damages customer relationships and organisational trust simultaneously.
Sequence instead. Procurement and stores usually first — self-contained and immediately effort-reducing. Then sales and dispatch, where the revenue is. Then production and quality. Finance last, running in parallel with Tally for a full quarter until the numbers reconcile exactly, month after month, before Tally is retired.
Master data cleanup is the step everyone underestimates. Items, customers, vendors and BOMs deduplicated and standardised, with a validation report your team signs off. Expect the data to be worse than anyone believes — it always is, and finding out early is the point.
What it costs and what it returns
A costed discovery is around ₹2.2 lakh and produces a module plan your leadership can act on with or without us. A first module is typically ₹8–22 lakh and live in fourteen to eighteen weeks. A full programme across modules and sites runs ₹60 lakh upwards over twelve to twenty-four months.
The returns we see most consistently: month-end close falling from eleven or twelve days to two or three, inventory carrying value down around twenty per cent from visibility and reorder discipline, and manual data entry hours down by roughly three quarters. Payback on labour cost alone is typically seven to nine months on the first module.
The return nobody forecasts but everybody mentions afterwards is that arguments about whose number is correct stop.
Key takeaways
- Decide build versus buy with arithmetic — hours and leakage per process — not with opinion.
- Job work, multi-GSTIN, weighbridge and scheme logic are where packages cost the most to fit.
- CRM adoption in Bengal depends on WhatsApp integration and on helping the salesperson first.
- Sequence module by module; run finance in parallel with Tally for a full quarter before switching.
- Master data cleanup is always worse than expected — schedule it properly rather than discovering it.
Frequently asked
For conventional operations, implement a package — the ecosystem and certified consultants are real advantages. Build custom when package customisation to fit your process would cost more than a build, when licence costs across hundreds of users are punitive, or when your process is genuinely distinctive. We run that comparison in discovery and have recommended buying more than once.
Built in rather than bolted on. Invoices generate IRNs through the IRP directly, e-way bills are raised from the dispatch transaction with transporter and vehicle captured at source, GSTR-1 and 3B data is produced from the ledger, and 2A/2B reconciliation is a standard report. Rule changes are handled under the support agreement.
Yes. Application server inside your network, with optional replication to a cloud instance for head-office reporting. Plant-floor terminals tolerate network interruption and buffer locally. For multi-site groups we typically run head office in the cloud and plants on-premise with sync.
We migrate opening balances and masters and can maintain a Tally sync for as long as your CA wants it. Many clients keep Tally for statutory filing for a year or more while the new system handles operations. Nothing forces a change of accountant or auditor.