A profitable fencing contractor doing $2.5M a year walked into a workshop, opened JobNimbus on the big screen, and the consultant in the room took one look and said the quiet part out loud: "You have a data risk issue. Your CRM is a mess. You're flying blind." He was right. This is the story of the rebuild that followed — not a highlight reel, not a sanitized recap. The full teardown: what was actually broken, why "data risk" is a symptom and not a setting, and the exact four-phase sequence that turned a CRM nobody trusted into a system the owner now opens before he makes a single marketing decision.
Let me be blunt about who this client was, because it matters. This was not a struggling business. They were profitable. They were growing. They had a real backlog of work and a team that knew how to build fences. The problem was never the trade. The problem was that a $2.5M operation was being steered on gut feel, because the one tool that was supposed to tell them the truth had quietly stopped telling the truth somewhere around year two.
They didn't know their close rate. They didn't know their average job value. They didn't know which lead sources actually produced paying customers versus which ones just produced noise. They spent $120K a year on marketing and could not tell you, with a straight face, which channel that money should go to next. Every one of those answers was technically inside JobNimbus. It just couldn't be pulled out, because the data underneath was corrupted by three years of well-intentioned drift.
"A contractor CRM doesn't fail in one dramatic moment. It dies by a thousand small shortcuts — one free-text field here, one duplicate contact there, one made-up status to get through a busy Tuesday. Three years later you have a $2.5M business making decisions on vibes." Arsalan Faysal — Revenue Systems Architect
The first thing I had to do was kill a misconception. The owner thought "data risk" was a switch — some warning he could acknowledge, dismiss, or pay to turn off. It isn't. A data risk warning is JobNimbus telling you that the integrity of your data has degraded to the point where the platform itself can no longer guarantee that what it reports back to you is real.
It's the smoke detector, not the fire. And the fire is always one of four things, usually all four at once.
So when the owner asked me "what's the fix for the data risk warning," the honest answer was: there is no fix for the warning. There is only a fix for the four things causing it. Clean the data, lock down the fields, rebuild the statuses to match reality, and backfill what's missing. Do that, and the warning clears on its own — because the condition it was reporting no longer exists.
This reframe changed the entire engagement. We weren't toggling a setting. We were rebuilding the foundation the business runs on, without taking the business offline while we did it.
You do not start a CRM rebuild by changing things. You start by proving, in writing, exactly what is broken — with screenshots, with counts, with specifics the owner can't argue with and a future team member can't misunderstand. Phase 1 produced a written diagnosis document, and that document did two jobs: it earned trust, and it became the spec for everything that followed.
Here's what the forensic audit actually surfaced inside this account.
I exported the full contact and job database and ran it through deterministic matching — exact matches on phone, fuzzy matches on name plus address. The result was ugly and specific: a meaningful share of "customers" were the same person logged two or three times, usually because a job came in from a new channel and nobody checked whether that name already existed. Each duplicate had a fragment of the real history. The estimate was on one record. The install notes were on another. The payment was on a third. No single record told the truth.
Then I mapped every job status in active use against the workflow the owner described to me out loud. They didn't match. The business runs a clean, knowable path — a lead comes in, you go measure and estimate, you send the number, they say yes or no, you schedule, you build, you invoice, you get paid. Seven, maybe nine real stages. The CRM had fourteen, and several of them were synonyms invented on different busy days by different people.
Finally, I did the thing the owner said was impossible: I tried to pull close rate by lead source. It took the better part of two hours, the filters fought me at every step, and the number that came out the other end was garbage — because it was built on duplicated jobs, blank values, and inconsistent source labels. That two-hour exercise, documented with screenshots, was the single most persuasive page in the audit. It proved the data risk flag wasn't paranoia. It was accurate.
Most CRM setups are designed around features. That's backwards. You don't design a contractor CRM around what the software can do — you design it around the decisions the owner needs to make, then build the minimum structure required to support those decisions cleanly. We started from the success criteria the owner gave me and worked backwards.
His list was specific and I respected it, because a specific brief is a gift. In 60 days he wanted to pull close rate by lead source in under two minutes, see which salespeople close at what margin, know the live pipeline value, track the real workflow without jobs rotting in the wrong status, and decide marketing spend on data. Every one of those is a question. Each question dictates a field, a status, or a dashboard. Nothing else gets built.
"The number one mistake contractors make with JobNimbus is adding fields. Every custom field someone adds 'just in case' is a future blank value, a future inconsistency, a future reason a report lies. Discipline is subtraction. The best contractor CRM has the fewest fields that still answer every question that matters." Arsalan Faysal — Revenue Systems Architect
We went field by field. The test for every single one was the same: does a report or a decision depend on this? If yes, it stays, it becomes required, and it gets locked to a dropdown wherever a human might otherwise free-type. If no, it's noise, and noise gets deleted. This is the step almost every "CRM expert" skips, because deleting fields feels destructive. It's the opposite. Every field you remove is a future data risk you've prevented.
| Field | Decision It Supports | Verdict |
|---|---|---|
| Lead Source | Which marketing channel produces profitable jobs — the $120K/year question | Keep · Required · Locked dropdown |
| Job Value | Average job value, pipeline value, margin by rep | Keep · Required · Gates stage progression |
| Assigned Salesperson | Who closes, at what rate, at what margin | Keep · Required · Locked dropdown |
| Job Type | Which work is most profitable (wood vs. vinyl vs. chain-link, repair vs. new) | Keep · Locked dropdown |
| Estimate Date / Sold Date | Sales cycle length and accurate close-rate windows | Keep · Auto-stamped on stage change |
| Misc free-text notes ×7 | Nothing a report can use | Consolidate into one notes field |
| Legacy "priority" / "rating" fields | No decision depended on them; inconsistently filled | Delete |
The second structural decision was splitting the workflow into two pipelines instead of one overloaded list. A fence job lives two distinct lives: first it's a sales opportunity (will they buy?), then it's a production job (when do we build it and are we done?). Cramming both into one status list is exactly how you end up with fourteen synonyms. Separate them, and each pipeline gets short, unambiguous, and reportable.
Then we mocked up the dashboards — on paper, before touching the software — mapped directly to the owner's five questions. Close rate by lead source. Revenue and margin by salesperson. Pipeline value by stage. Average job value by job type. Cost per acquired job by channel, the report that finally tells him where the $120K should go. Designing these first is what guarantees the field architecture actually supports them. You never want to finish a rebuild and discover a dashboard needs a field you didn't collect.
This is the phase that scares people, and it should — because the wrong way to clean a CRM is to start deleting and merging records by hand in the live account while the business keeps running through it. Do that and you will lose history, you will break a job mid-build, and you will turn a data risk problem into a data loss disaster. We did it the disciplined way.
Before anything moved, the entire account was exported and backed up. Every contact, every job, every note, every attachment reference. This is non-negotiable. The backup is what makes every subsequent change reversible. If a merge goes wrong, you restore the truth from the export. Working without that safety net on a $2.5M operation's live data is malpractice.
Cleaning the data once is worthless if the same drift starts the next morning. So the rebuild hard-wired the discipline in. Lead source, job type, salesperson, and status all became controlled dropdowns — no free-typing. Job value and lead source became required to advance a job past the early stages, so a blank simply can't propagate down the pipeline. The structure now enforces clean data automatically, instead of relying on six different people to remember the rules on a busy Tuesday.
Then the automations — deliberately few. Auto-stamp the sold date when a job hits Won. Auto-create the production job when sales hands off. Flag a job that's been in Estimate Sent too long so it doesn't quietly die. That's the restraint that matters: just enough automation to remove human error, not so much that the system becomes a black box the admin is afraid to touch.
With clean, consistent, complete data underneath, the dashboards we designed in Phase 2 finally had something real to report on. The two-hour filter fight became a tab the owner opens. Close rate by lead source, on demand. Margin by salesperson, on demand. Pipeline value that reflects actual money. The data risk warning — the thing that started all of this — cleared, because the conditions causing it no longer existed.
A rebuild that only works while the architect is in the room is a failure with a delay on it. The whole point was to make the admin spend less time fighting JobNimbus, not to make them dependent on me forever. Phase 4 was about transferring ownership completely.
The admin got trained on the new structure — not "here's how to click buttons," but how the two pipelines work, why the dropdowns are locked, and how to keep the data clean as new jobs flow in. The owners got trained on something different: how to read the dashboards and turn each number into a decision. A close rate by source is just trivia until you know it means "stop funding the channel on the right, double the one on the left."
Here's what changed, measured against the owner's own 60-day success list — because that list, not my opinion, is the only scoreboard that counts.
| The Owner's Target | Before | After The Rebuild |
|---|---|---|
| Close rate by lead source | ~2 hours fighting filters, output untrustworthy | Under 2 minutes, from a saved dashboard |
| Which salespeople close at what margin | Unknowable | Visible per rep, on demand |
| Live pipeline value | Fiction — built on duplicates and blanks | Real money, summed from clean sales stages |
| Jobs in the right status | 14+ overlapping synonyms; jobs stalled silently | 9 real stages across two pipelines; nothing hides |
| Where to invest marketing budget | Gut feel on $120K/year | Cost-per-acquired-job by channel, in a report |
| Admin time fighting the CRM | Constant friction | Dropdowns and automation removed the fight |
| JobNimbus data risk warning | Active | Cleared — root causes eliminated |
The bigger win isn't on that table, though. It's that the business can now scale. The owner's real fear was that he couldn't push from 250 toward 400 jobs a year because the systems would break under the load. They wouldn't have — the old setup was already breaking at 250. A clean, enforced, two-pipeline structure with honest dashboards is a system that gets more valuable as volume grows, because every new job makes the reports sharper instead of muddier.
"The right CRM setup was worth six figures a year to this business in better decisions alone — the owner said so himself before we started. The rebuild didn't add a feature. It gave a profitable company the ability to see what it was already doing, and decide what to do next on something better than a hunch." Arsalan Faysal — Revenue Systems Architect
If you run a contracting business — fencing, roofing, HVAC, anything with estimates and crews and a CRM that's supposed to keep score — and any of this felt uncomfortably familiar, here's the honest takeaway. A data risk warning is not a software bug you wait out. Reports that take two hours and contradict each other are not normal. A CRM that makes your admin's life harder instead of easier is not a CRM you're using; it's a CRM that's using you.
The fix is never a new platform. This client stayed on JobNimbus, exactly as they wanted — the problem was never the tool, it was the structure built on top of it. The fix is a disciplined rebuild: prove what's broken, design around the decisions that matter, clean the live data without losing a day of history, lock the structure so it can't drift again, and hand it back to a team trained to run it.
You make decisions worth millions. You should be making them on data that tells the truth. If your CRM can't give you close rate by lead source in under two minutes right now, you already have your answer — and it's the same answer a consultant gave a profitable fencing contractor across a workshop table. You're flying blind. Let's fix that.