"Custom CRM" is an abstraction until you see one. So here is a concrete example: a composite of field services companies we've built for — anonymised, with the details that matter left intact. Call it a 60-technician residential and light-commercial contractor running HVAC, plumbing and electrical crews across two regions, with a warranty program, a maintenance-plan subscription base and a small subcontractor bench.
This company had a well-configured platform CRM, a separate scheduling tool, an accounting package and eleven spreadsheets. Nothing was broken exactly. It just took four people to hold the picture together. What follows is what changed when the system was engineered around the operation instead of the operation being reshaped to fit software.
The data model starts with the job, not the deal
In a generic CRM, the root object is an opportunity attached to a contact. Everything this contractor cares about had to hang off that: the property, the equipment installed at that property, the maintenance plan covering it, the visit history, the warranty clock, the technician certifications required to touch it.
The custom system inverted that. The root object is a property. A property has equipment records with make, model, serial, install date and warranty expiry. Equipment has a service history. A customer can own several properties; a property can change owners while keeping its equipment history — which matters enormously, because the contractor's most profitable work comes from equipment they installed years earlier for someone else.
Jobs reference the property and specific equipment. A maintenance plan is its own object with a renewal cycle, covered equipment, entitlement rules and margin tracking. None of these are custom fields bolted to a Deal. They're first-class tables with their own constraints, so the database itself refuses to record a visit against equipment that doesn't exist at that address.
That sounds pedantic until you look at reporting. Because the model is true, questions like "what's the failure rate by equipment model within warranty, by installing technician" are a query, not a three-day export-and-reconcile project.
Permissions written around real roles, not licence tiers
Generic platforms price and structure access around seats and role templates. This company has six meaningfully different roles and one of them isn't even an employee.
Technicians see today's route, the property's equipment and service history, parts availability and the customer's plan entitlements — and nothing about pricing margin. Dispatchers see everything schedulable across both regions but can't modify invoices. Regional managers see their own region's financials, not the other's. The office admin can issue credits up to a threshold; above it the system requires a second approval and logs both. Subcontractors get a scoped external view: only their assigned jobs, only the site details required to do the work, no customer contact export, and access that expires when the job closes.
The customer has a portal too — an authenticated view of their own equipment, visit history, plan status and invoices. On a per-seat platform, every one of these people is either a licence cost or excluded from the system. Here, access is a permission rule enforced server-side, and adding 40 more technicians costs nothing.
Automations that only make sense for this one company
This is the part that can't be configured, because the rules were never generic to begin with. A sample of what actually runs:
- When a technician marks a diagnostic complete and the equipment is inside its warranty window, the system generates a manufacturer claim draft with the serial, fault code and labour codes pre-filled — and blocks invoicing the customer for covered parts.
- Maintenance-plan visits are auto-scheduled against seasonal capacity: cooling tune-ups are back-loaded into spring shoulder weeks so they don't consume peak emergency capacity in July.
- If a job requires a gas-fitting certification and the assigned technician's certification expires before the scheduled date, dispatch is blocked at assignment time, not discovered on site.
- Second callbacks on the same equipment within 30 days are flagged as rework, routed to a supervisor, excluded from the technician's commission calculation and tracked as a quality metric per install.
- Truck stock consumption posts from the job, so parts reorder thresholds are driven by what was actually installed rather than a monthly manual count.
- Invoices are derived from completed job records — labour, parts, plan entitlements and warranty coverage applied automatically — so nobody retypes anything into accounting.
What that replaced
Before, the warranty claim process lived in one person's head and a shared spreadsheet, and the company was leaving claims unfiled because nobody had time. Certification tracking was a wall calendar. Rework was invisible, which meant the commission plan quietly rewarded the technicians causing it. Parts reordering happened when a truck ran out.
The pattern is consistent across the service businesses we work with: the workarounds aren't laziness, they're what happens when the system can't hold the real shape of the operation. See how that plays out in home and field services specifically, or across the other verticals we build for.
How this differs from a well-configured platform
A skilled Salesforce or HubSpot partner could approximate parts of this. Custom objects for equipment, a managed package for field service, flows for the warranty logic, an integration for accounting. It would work, and for some companies that's the right call — we say so plainly in our comparison of custom builds versus platform customization.
The differences show up in three places. First, fidelity: approximated models leak, and every leak becomes a manual reconciliation someone performs forever. Second, cost shape: the approximation is priced per seat per month, escalating with headcount, while the built system is a capital cost that then only carries hosting and maintenance. Third, change velocity: when this contractor added a commercial-contract line with its own SLA rules, that was a two-week engineering change, not a licensing conversation.
None of this required exotic technology. It required starting from the operation — which is the whole point.
The short version
- A 100% custom CRM isn't a generic CRM with more fields — it's a data model whose root objects are the things your business actually revolves around.
- Permissions and automations built for one company encode competitive advantage that a configurable platform can only approximate.
- The test is simple: can your system answer operational questions directly, or does someone have to assemble the answer by hand?