What a Bad CRM Agency Looks Like Before You Hire One

What a Bad CRM Agency Looks Like Before You Hire One

Most companies don't realize they hired the wrong CRM agency until six months after the engagement ends.

By then, the consultant is gone. The Salesforce instance is full of custom fields nobody can explain. The automations are running, but nobody is confident they're running correctly. And the one person who understood how it was built left the company in March.

This isn't a story about bad actors. Most of the agencies that leave messes behind aren't incompetent, they're optimized for implementation speed, not long-term operability. They build what you asked for, hand it off, and move to the next client. The problems surface later, when your company grows, your team turns over, or you try to integrate a newly acquired business and discover the foundation wasn't built to absorb any of that.

The good news: the warning signs are visible before you sign the contract. Here's what to look for.

They build before they ask about your data model

A CRM is only as useful as the data structure underneath it. Before any field gets mapped, any workflow gets built, or any integration gets configured, someone needs to answer a foundational question: what does your data actually represent?

What is a lead in your business? What makes it qualified? When does it become an opportunity? What does a "customer" record need to contain to be useful to both sales and marketing? How do your Salesforce objects relate to each other, and how does that map to how HubSpot thinks about the same entities?

An agency that skips this conversation and moves straight to implementation is building on an undefined foundation. The system will work, until your business logic changes, your team grows, or you try to report on something they didn't anticipate. Then it breaks in ways that are hard to diagnose because nobody documented the logic in the first place.

The question to ask in the first call: "Walk me through how you define the data model before you start configuration." If the answer is vague, that's the answer.

The Salesforce build only they understand

Heavy Salesforce customization isn't inherently a problem. Complex businesses have complex needs, and the platform is built to accommodate them. The problem is customization that serves the consultant's preferences rather than your team's ability to operate the system independently.

Signs you're heading into this: custom Apex triggers written without documentation. Page layouts restructured in ways that don't match how your team actually works. Validation rules added to enforce data quality that nobody on your team knows exist until they cause a sync failure six months later. Fields named in ways that made sense to the person who built them but mean nothing to the next admin who inherits the system.

The test: ask the agency to show you a system they've previously built and explain how they would onboard a new admin to manage it. If they can't walk you through it clearly, your team won't be able to either.

Automations built for today, not for scale

Workflow automation is one of the highest-leverage things a CRM agency can build for you. It's also one of the easiest things to build badly.

An enrollment trigger that works perfectly for a 40 person sales team can behave unpredictably at 150. A lead routing rule that made sense before the acquisition doesn't account for the acquired company's territory structure. A lifecycle stage automation designed around one product line doesn't hold when you add three more.

Agencies that build automations without asking "what does this look like in 18 months?" are building for the demo, not for the business. The automation runs, it looks correct, and the QA passes. Then your business changes and the automation keeps running, just incorrectly.

The question to ask: "How do you build automations to be maintainable as the business changes, and what breaks first when it scales?" An agency that's actually thought about this will have a real answer. One that hasn't will tell you it depends.

No documentation, no handoff

This is the most common failure mode and the most avoidable.

When a consultant exits an engagement without leaving documentation, a data dictionary, workflow logic, field mapping decisions, integration architecture, they've transferred a system without transferring the knowledge to operate it. Your team inherits a car with no owner's manual and no explanation of what was modified under the hood.

The consequences compound over time. The first admin who needs to troubleshoot a sync issue can't find the integration spec. The new RevOps hire who needs to add a field doesn't know which existing fields it might conflict with. The PE firm that needs consolidated reporting across the portfolio discovers that each portco's CRM was built differently, with no documentation explaining why.

Documentation isn't a nice-to-have. It's the difference between a system your team owns and one your team is hostage to.

Ask for examples of documentation from past engagements before you hire. If they can't produce them, assume they won't produce them for you either.

What good actually looks like

Most agencies won't fail all four of these tests. The dangerous ones fail one or two quietly. Knowing what good looks like gives you a baseline to compare against.

• Discovery phase is scoped and billed separately before any configuration starts
• Data model is documented before the first field is created
• Every automation has a written logic spec: trigger, conditions, outcome, edge cases
• Admin handoff includes a walkthrough session, not just a document drop
• Documentation is a named deliverable in the SOW, not a verbal promise
• They push back on your requests when the architecture doesn't support them

‍

Before you sign: a pre-hire checklist

The warning signs are visible before the contract. These questions surface them.

• Ask for a data dictionary from a past engagement,  not a template, an actual one
• Ask them to walk you through how they'd onboard a new admin to a system they built
• Ask what breaks first when a workflow scales,  if the answer is vague, that's diagnostic
• Confirm discovery is a paid phase, not absorbed into implementation
• Check if documentation is listed as a deliverable in their standard SOW
• Ask how they handle scope changes mid-engagement, process reveals maturity

Contract and SOW red flags

Even if the agency passes the conversation test, the SOW tells you what they actually intend to deliver.

• No discovery phase,  implementation starts at kickoff
• Documentation not listed as a named deliverable
• Fixed fee with no change order process
• No post-launch support window defined
• Vague acceptance criteria, "system configured per requirements" with no test cases
• Single point of contact with no backup,  if they leave, you have no continuity

If you already inherited the mess

Not everyone is evaluating an agency before the engagement. Many are living with what a previous one left behind. If that's you:

• If you can't explain why a custom field exists, assume it's load-bearing and don't touch it until audited
• Run a field usage report before deleting anything,  dead fields aren't always inactive
• Map every active automation before changing any object structure
• Identify which integrations are running and what triggers them, sync failures compound silently
• Prioritize documentation of what exists over optimization until you have a baseline
• If the original agency is reachable, one paid session to document their decisions is worth it

The pattern underneath all of it

These failures share a common root: agencies that treat CRM implementation as a project to be completed rather than a system to be built for ongoing use.

A project ends. A system has to keep working after the people who built it are gone. That requires a different set of decisions, about architecture, about documentation, about what happens when the business changes, that agencies optimizing for delivery speed tend to skip.

The companies that avoid this hire for operational thinking, not just technical execution. They ask hard questions before signing. They require documentation as a deliverable, not a bonus. And they treat the data model conversation as the first meeting, not something to sort out later.

The warning signs are there before you engage. You just have to know to look for them.

Is your CRM built to last, or built to hand off? If you inherited a system you don't fully trust, or you're about to hire an agency and want to know what you're walking into, we'll audit your setup and tell you exactly what's there.