CRM Processes: Standard or Custom Path

Why "we do it differently here" is the most expensive sentence in a CRM project

That sentence comes up in nearly every workshop, and it ends the discussion instead of opening it. The business cost only shows up months later, when the project turns out to have modelled a habit rather than a business, and nobody can say why any more. An exception that is not examined the moment it appears never gets examined at all.

Our position: an exception to the standard needs evidence in the business, not in the room. The burden of proof sits with the custom path, never with the standard. That is not ideology, it is arithmetic, and it almost always comes out the same way.

Technically, an exception ends up in one of three places. It becomes an extra field on an object that already exists (a property). It becomes its own sequence of stages for deals (a second pipeline). Or it becomes a business object of its own with its own life cycle (a custom object). All three look equally harmless in a workshop. In daily operation they cost wildly different amounts.

The reason is simple. HubSpot can model almost any exception, which is neither impressive nor an argument. The question is not whether the system can do it. The question is what it costs every single time somebody builds a report, extends a workflow or onboards a new colleague.

Three questions that settle the decision

What is usually missing in a modelling session is not knowledge but a rule. The consequence is that the loudest voice decides, or the consultant does, and both justify it afterwards. Three questions settle the normal case in a few minutes.

First: does the standard object carry the life cycle? Does the thing you are discussing move through its own stages with its own transitions? A quotation that is created, negotiated and won is a deal. A site that belongs to a customer moves through no stages at all. It is an attribute of that customer. If the answer is "no stages of its own", the decision ends right here.

Second: does reporting need a timeline of its own? Will somebody later want to count how many there were per month, how long they took and how many ended well? Then the thing needs its own record with its own start and end date. If it is only ever reported as an attribute, a field is enough. This is the question that gets answered wrongly most often, because nobody asks it in the workshop.

Third: does the exception exist in the business or in the habit? The test is uncomfortable and takes a minute. Ask which customer, which contract or which regulation forces the exception. If the answer contains a name, it is real. If the answer is "we have always done it this way" or "that is how the old system worked", it is a habit about to become expensive.

Our position: if the answer is no twice, the thing is a field. If it is yes three times, it is an object of its own. Everything in between is a second pipeline, and in practice that is the most common correct answer.

The ladder: field, own pipeline, own object

When in doubt, teams reach for the heaviest option, because nobody names the cheaper one. The consequence is a data structure that can do more than needed and delivers less than hoped, paid for in reporting time and onboarding. The three rungs differ hardly at all in build effort. They differ enormously in what they cost afterwards.

You start at the bottom and climb only when the rung below demonstrably fails. That direction is the actual content of the rule — not the rungs themselves, but the order in which you walk them.

What the custom path costs in daily operation

The cost of an exception appears in no proposal, because it does not arise during the project at all. It arrives afterwards, as time the sales team spends on administration instead of conversations. That workload is the currency a custom path is actually paid in.

It accumulates in four places. Every report has to know about the exception or it counts past it. Every automation needs one more condition. Every new colleague has to learn why this part is different. And every permission rule has to account for the special case. None of the four is expensive on its own. Together they are the reason a CRM is called cumbersome two years in.

Our position: that number is not a tool effect. It comes from modelling processes in the standard wherever the standard carries them, so the sales team no longer maintains records by hand.

When the custom path is the right answer

Treating the standard as a dogma fails to represent real differences in the business and creates the same problem from the other side. The consequence is a system the sales team works around, in spreadsheets, in notes, in their heads. Two patterns make an object of its own clearly correct.

The first is a life cycle of its own. A leased item, a certificate, a project phase or an installation at the customer comes into being, changes, expires and gets renewed, regardless of whether a deal is open at the time. Holding something like that as a field on a company destroys the history the moment the value changes.

The second is a permission boundary of its own. If certain records may only be seen by part of the team, and that boundary cannot be drawn along company membership, you need the separate layer. That is the exception where an object of its own is not merely more convenient but necessary.

In both cases the decision still holds two years later, because it is anchored in something that exists in the business rather than in a habit inherited from the previous system. Everything else belongs on the bottom rung of the ladder.

Deep Dive Guide · 17 pages · free

CRM rollout: the internal cost nobody budgets for

A readiness check and an effort calculation in person-days, before you decide. Plus the processes that will break at go-live, and the choice between repair and rebuild.

Explore guide →

How fast a standard setup can carry

Many decision makers postpone the modelling question because they assume a six-month project sits behind it. The consequence is that custom paths keep appearing every week in the meantime, and nobody unwinds them later. The assumption is wrong, and that can be shown.

At Nestermind, 2x pipeline visibility landed within a timeframe of under one month, together with faster sales cycles. At figure it, it was 30 percent less sales admin workload at two days of time investment. Both numbers come from standard setups, not from heavily modelled special constructions.

Our position: the standard path is not the compromise. It is the faster route to the visibility the CRM was introduced for in the first place. The custom path is the investment you make deliberately, and that you have to be able to justify.

If you want to go deeper into the system boundary, the split between CRM and ERP is in CRM and ERP: Which Data Belongs Where, and how large such a project gets is in CRM Implementation: The Scope Nobody Writes Down. How we build HubSpot setups is on our HubSpot page.

SalesPlaybook is a HubSpot Diamond Solutions Partner with 39+ five-star reviews in the HubSpot Solutions Directory, and in this trade-off takes the standard when in doubt. For aumico that put the CRM live in under 2 weeks, and cut the time for sending quotes by 80%.