How to Audit an Inherited CRM in Your First 90 Days

Your new CRM is already broken: here's what to do

You've stepped into a new GTM leadership role, done the listening tour, met the team. Then sometime around day thirty, you open the CRM and realize nobody actually trusts it.

Reps aren't logging activity. Forecasting is happening in a spreadsheet somewhere. Ops is apologizing for fields nobody remembers creating. The last three deals sitting in Closed Won have been there for six months.

That's not a data problem. It's an architecture problem, and it's been building since before you arrived.

‍

Why the first 90 days matter

The 90-day window is real. It's the only stretch where you have the political cover to ask hard questions about existing systems without it reading as an attack, the only stretch where a team expects things to change and the "this is just how we do it" noise is at its lowest.

Miss that window and the status quo sets. A broken Salesforce org becomes your process. Unmapped workflows become tribal knowledge. Six months later, you're patching instead of building.

Most GTM leaders run a people assessment in the first 90 days. Almost none run a systems assessment with the same rigor, even though the CRM is a direct record of how revenue actually got built before they arrived. What's sitting in there tells you more about the real state of the business than any slide deck or QBR will.

The four warning signs

These are the patterns that show up again and again in an inherited CRM, Salesforce, HubSpot, or otherwise.

• Bad data, no baseline: contacts with no owner, deals with no close date, stages that don't map to any real buying motion. Nobody knows what's accurate anymore.
• Over-customized systems: three hundred custom fields, automations firing on triggers nobody remembers setting, a Salesforce org shaped by five different admins over four years.
• Broken workflows: sequences still running against dead leads, duplicate records inflating the pipeline number, stage changes that trigger the wrong follow-up.
• No RevOps ownership: nobody owns the system strategically. The admin manages tickets. Nobody's connecting the CRM's architecture back to revenue outcomes.

How to run the assessment

Don't wait until day sixty to start looking. Run it in three phases.

Days 1 to 30: audit without touching

The only job here is to observe and document. Talk to sellers, ops, and finance. Don't fix anything yet.

• Pull a pipeline report and have sellers walk you through every deal on it.
• Map how leads actually move from source to close, not how the process doc says they do.
• Count the custom fields. Flag anything with no clear owner or use case.
• Notice where people are working outside the CRM: spreadsheets, Slack, personal trackers.
• Ask everyone the same question: if you needed to forecast next quarter today, what would you actually trust?

Days 31 to 60: diagnose the architecture

By now you have enough context to separate symptoms from root causes. The goal is a clear diagnosis before any rebuild starts.

• Map the existing data model: what objects exist, what connects to what, what's orphaned.
• Audit the active automations: what fires, when, and whether anyone's watching the outcomes.
• Find the highest-friction moments: where deals stall, where records break, where reporting falls apart.
• Sketch what a clean, minimal architecture would look like for your current GTM motion.
• Pressure-test it with your RevOps or ops lead. If you don't have one, that gap is itself part of the diagnosis.

Days 61 to 90: build the case and the plan

Present what you found. Be direct. This window is for getting organizational alignment on the rebuild, not for softening the problem.

• Lay out the gap between where things are and what the business needs to scale.
• Separate the quick wins, data cleanup, workflow fixes, from the strategic work: the architecture rebuild.
• Define what RevOps ownership looks like going forward: an internal hire, a fractional partner, or both.
• Set a 90-day roadmap with milestones you can actually measure.
• Get budget and executive alignment locked in before the window closes.

Most CRM problems aren't technical, they're architectural. A Salesforce org with four hundred custom fields and broken pipeline hygiene doesn't need more customization. It needs a clean revenue architecture built around how the team actually sells. That's the real difference between a CRM admin and a RevOps partner.

Fix, rebuild, or replace

After a real assessment, most GTM leaders land on one of three answers.

• Fix: the core architecture is sound, execution has just drifted. Cleanup, workflow pruning, and better hygiene get you there. Thirty to sixty days.
• Rebuild: the platform is right but the configuration is wrong. This is the most common outcome, a RevOps-led re-architecture on the tool you already have. Sixty to ninety days.
• Replace: the tool no longer fits the GTM motion. Rare, but real when the org has outgrown the stack or the tool was never right for the motion in the first place. Ninety to one hundred eighty days, with a real migration plan behind it.

Most inherited CRMs need a rebuild, not a replacement. Ripping everything out and starting over is expensive, and almost always avoidable if the architecture gets designed correctly the second time.

What changes once it's fixed

The assessment isn't the point. What it unlocks is.

• A forecast you can trust: pipeline reflects reality, stage movement means something, and nobody's running a shadow spreadsheet next to the CRM anymore.
• Sellers who use the system: when the CRM reflects how people really sell, adoption stops being a fight.
• Ops with real leverage: less time firefighting broken workflows, more time building systems that scale with the pipeline.
• Leadership with real visibility: one source of truth, dashboards that reflect what the business needs to know now, not what someone built in 2021.

‍