Q.Why Do Custom CRM Projects Fail at Distributors?
They fail for four reasons, and almost none of them are technical: the CRM is built for management reporting instead of for the sales rep's day, it is not connected to the order and item data, nobody owns it after launch, and the scope was never fixed so it never actually finished.
If you search for CRM advice as a distributor, you will find vendor pages telling you that custom-built CRMs disappoint their users, often with a precise-looking satisfaction score attached. Two things about that.
First, be careful with the number. The most-repeated version — a single-digit satisfaction score for custom CRM — traces back to one vendor's blog post, as a parenthetical with no report title, year or sample size, and the research group it credits does not publish that figure in any of its public reports. The vendor in question sells distribution-specific CRM, which the same sentence ranks highest. Treat it as marketing.
Second, take the underlying observation seriously anyway, because it is broadly right. The Distribution Strategy Group's 2022 survey of 96 people, 66 of them distributors, found that regardless of what a company had bought or built, "only 50% of sales reps and those in sales leadership regularly used their company's CRM solution." Half. That is the real problem, and it is not a custom-versus-purchased problem — it is a nobody-opens-it problem, and custom builds are simply more likely to arrive at it.
What those pages leave out is why, which matters — because the failure modes are specific and avoidable, and because the alternative they are selling fails for its own reasons in wholesale, which we will get to.
Failure 1: It Was Built for the Report, Not for the Rep
The most common failure is a system designed backwards. Someone in management wants pipeline visibility, so the build starts from the dashboard and works down. What arrives is a tool that asks the rep to enter data so that somebody else can read a chart.
A rep on the road, between two stops, with a customer asking whether the case price moved, does not open that. And a CRM nobody opens produces a dashboard that is wrong, which produces meetings about why the data is bad, which produces more required fields, which guarantees nobody opens it.
The inversion is the fix: build for the rep first and let the reporting fall out of what they do anyway. If the rep opens it because it is the fastest way to see what the customer bought last month, whether the last order shipped complete, what is on their open quote, and what they usually reorder about now — then the pipeline data exists as a by-product. Nobody has to be chased.
A practical test before anyone writes code: name the three things a rep will open this for on a Tuesday afternoon when they are not being asked to. If you cannot name three, you are building a reporting tool, not a CRM.
Failure 2: It Does Not Know What the Customer Bought
A generic CRM records conversations. A distributor's CRM is worthless unless it records conversations next to transactions.
This is where most off-the-shelf CRMs fail in wholesale, and it is the honest reason custom keeps getting attempted. A horizontal CRM built for software sales models a deal that opens, progresses and closes once. Your customer opened in 2014 and has ordered every week since. There is no pipeline stage for that. The questions your reps actually have are:
- What has this account bought over the last twelve months, by item?
- Is their order size drifting down?
- What did they stop buying, and when?
- What is on their open quote, and what is the item priced at for them specifically?
- Did their last three orders ship complete?
None of those are answerable without the order and item data sitting inside the same screen. A CRM that requires the rep to switch to the ERP to answer any customer question will be open for four minutes a week.
So the first architectural decision is not which CRM — it is the integration. If order history, item data and customer-specific pricing cannot be read into the CRM reliably and often, nothing else you decide matters.
Want this looked at for your operation?
Twenty minutes on a call, and you'll know whether this is worth building, buying, or leaving alone. No deck, no pitch.
Book twenty minutesFailure 3: Nobody Owns It After Launch
The third failure happens six months after go-live, and it is organizational.
The person who drove the project has moved on to the next thing. New items are added to the ERP and do not appear correctly. A rep leaves and their accounts do not get reassigned. Somebody adds a custom field, then another, and the entry form grows to nineteen fields. Data decays, trust decays, use decays.
This is not a custom-software problem — it happens to purchased CRMs at the same rate. But it is fatal more often with custom, because with a subscription there is at least a vendor sending release notes and an invoice that forces an annual conversation.
The fix is unglamorous and it is a condition we put in writing rather than a feature: a named internal owner, a short monthly check of a handful of health numbers (accounts with no activity in 90 days, items failing to sync, users who have not logged in), and an agreed route for changes. If nobody in your business will own it, do not build it. Buy something, accept its compromises, and let the vendor carry that weight.
Failure 4: The Scope Was Never Fixed, So It Never Finished
The fourth failure is commercial, and it is the one that produces the horror stories.
An open-ended build, billed by the hour, against a requirements document that keeps growing. Every demo generates three new requests. Nine months in there is no live system, the budget conversation has become adversarial, and the project is cancelled with nothing in production. This is the experience behind most of the industry's distrust of custom software, and the distrust is reasonable.
The structural fix is to make "finished" a defined thing before anyone starts:
- A fixed scope and a fixed price, agreed in writing before work starts. Not an estimate, not a range with an asterisk, not time-and-materials against a wish list.
- Something live and usable in the first few weeks, even if it does one thing. A system in production gets honest feedback; a system in a demo environment gets opinions.
- Changes handled as changes — priced and scheduled, not absorbed silently until the timeline collapses.
- You own the code, the accounts and the data. If leaving is impossible, the vendor has no reason to keep earning the relationship.
The Four Rules, Together
| Failure | Symptom at month six | The rule that prevents it |
|---|---|---|
| Built for the report | Reps enter data only when chased; the dashboard is wrong | Build for the rep's Tuesday; let reporting be the by-product |
| No transaction data | Reps switch to the ERP to answer any real question | Order history, item data and customer pricing live in the same screen |
| No owner | Fields multiply, data decays, logins fall off | A named internal owner and a monthly health check, agreed up front |
| Open scope | Nine months, no production system, an adversarial budget call | Fixed scope and fixed price in writing; something live in weeks |
When You Should Not Build a CRM
Plainly: most distributors should not.
If your reps are working from a shared spreadsheet and it is basically holding up, the first project is almost never a CRM. It is usually the ordering path — getting repeat orders off the phone and out of email — because that is where the hours and the errors actually are, and it produces the clean transaction data that any future CRM would need anyway.
If you have fewer than about five people who would use it, a well-configured off-the-shelf CRM with a decent integration will serve you better than anything custom, and it will cost less than the annual maintenance on a build. It is also what the industry does: in the same Distribution Strategy Group survey, 52% of distributors ran a general-purpose CRM and 9% ran something custom.
If your objection to the off-the-shelf options is price rather than fit, buy the cheap one. Custom software is not a way to avoid a subscription. It is a way to fit an operation that does not match the assumptions the subscription was designed around, and it is worth doing only when that mismatch is costing you real hours or real orders.
Custom earns its place when the thing that makes you money — how you price for specific accounts, how orders come in, how the route works, how approvals run — is genuinely not how the standard products assume it works, and you have already tried bending one of them.
FAQ
Q: Are custom CRMs a bad idea for distributors? A: They are a bad idea when they are built for management reporting, disconnected from order and item data, unowned after launch, or scoped open-endedly — which describes most of them, which is why the category has a poor reputation. They are a good idea when the way you price, sell or fulfill genuinely does not match the standard products, and all four of those conditions are fixed before work starts.
Q: What should a distributor's CRM show on the first screen? A: What the account bought over the last twelve months by item, whether order size is drifting, what they stopped buying, the open quote with their specific pricing, and whether recent orders shipped complete. If a rep cannot answer a customer's question without leaving the CRM, they will stop opening it.
Q: Should we fix the CRM or the ordering process first? A: Usually the ordering process. Repeat orders arriving by phone and email is where the hours and the errors are, and fixing it produces the clean transaction history that makes a CRM worth having later. A CRM built on top of messy order data inherits the mess.
Q: How do we avoid a custom project that never finishes? A: Fix the scope and the price in writing before work starts, require something live and usable in the first few weeks, price changes as changes rather than absorbing them, and make sure you own the code and the accounts. An hourly build against a growing requirements document is the shape of every project that ends with nothing in production.
Read us often? You can add Futurise as a preferred source in your own Google account.