Common failures

Most RevOps failures are the same handful of mistakes, and each has a known fix

Almost every broken RevOps setup I see traces back to the same short list of mistakes, not to anything exotic. Learn to recognise them and you can fix trouble early, before a small crack becomes a CRM the team has abandoned. Here is the list, each with the symptom and the fix.

The CRM is a filing cabinet, not an engine

Symptom: the CRM records what already happened but triggers nothing. Follow-ups depend on memory, reports get exported and argued over, and the system feels like admin overhead rather than help. The fix: turn records into actions. Build workflows that fire the next step automatically, and make a weekly dashboard the surface the team steers by. The test of a working CRM is whether it tells you what to do next; if it only tells you what you did, it is a cabinet. This is the whole point of chapter seven, revisit it.

No lifecycle stages, or vague ones

Symptom: contacts are only "lead" or "customer", or two people define "qualified" differently, so the funnel never reconciles and nobody trusts the conversion numbers. The fix: adopt HubSpot's default lifecycle stages and write one checkable entry criterion per stage, agreed once. The funnel report is only as honest as the stage definitions beneath it. Vague stages produce vague reports that quietly die of distrust.

Manual logging, so the data has holes

Symptom: calls and meetings get logged only when someone remembers, so activity reports undercount and the pipeline view is always a little stale. The fix: wire the plumbing. Connect scheduling and forms to the CRM so interactions log themselves, and stop relying on human discipline that a busy day always defeats. If a human has to remember to log it, assume it will not get logged.

Reports nobody believes

Symptom: the dashboards exist, but the team spots one wrong number and discounts all of them, so decisions get made on gut feel anyway. The fix: the problem is almost always data quality at entry, dirty inputs, duplicates, free-text fields. Require the reporting-critical properties, convert reported fields to dropdowns, and dedupe on a schedule. Trust is downstream of clean data; you cannot report your way out of a dirty database.

Tool sprawl

Symptom: revenue data is split across five overlapping tools, none fully configured, and no single view of the pipeline exists. Every new problem gets a new tool instead of a fixed spine. The fix: name one CRM the spine, migrate everything into it, and refuse to add a new tool until a named, repeated pain proves a real gap. Subtraction usually beats addition; the seventh tool rarely fixes what the first six could not.

Building the model after the data

Symptom: thousands of records were imported flat, with no company associations and no source, so historical reporting is permanently blank. The fix: model companies, contacts and deals as one connected object before bulk-importing, and when you inherit a flat database, backfill associations and source so the history becomes legible. The model is cheaper to build first than to retrofit, but retrofitting beats reporting on nothing.

A worked example

A 28-person B2B services firm hit four of these failures at once: a filing-cabinet CRM, vague stages, manual logging and tool sprawl across six apps. Challenge: the founder could not produce a pipeline number she trusted, and revenue forecasting was pure guesswork. Approach: over six weeks they worked the fixes in order, consolidated to HubSpot as the spine, adopted default lifecycle stages with written criteria, wired scheduling and forms to auto-log, and built one weekly dashboard. Result: forecast accuracy (forecast versus actual close) went from wildly off to within 12 per cent, the team stopped re-exporting data for every meeting, and tool spend fell by roughly 900 EUR a month. The failures were ordinary; fixing them in sequence rebuilt the engine.

Pitfalls within the fixes

• Fixing symptoms, not causes. A wrong report is a data-quality problem, not a dashboard problem. Trace each failure to its root.
• Fixing everything at once. Work the list in dependency order, model, stages, plumbing, quality, reporting, so each fix stands on a solid one below it.

These are the failures to watch for as your system matures. The final chapter answers the questions a lean founder asks before and during this build, from whether you need a RevOps hire to how to rescue a CRM that is already a mess.