Jon Cottrell — Enterprise CRM Systems Advisor

About

Dysfunctional CRM is not a technology problem. It is a systems problem. That observation, accumulated across more than thirty years working inside production revenue systems at global scale, is what this practice is built on.

I spent over thirty years at Oracle in predominantly global roles, living and working across the UK, Australia, and the United States. I began my career in back office systems: support renewals, it’s associated billing and revenue recognition, and the ERP infrastructure that sits downstream of every CRM transaction. I learned how data flows out of CRM into those systems, how it transforms as it moves, how records develop and change over time, and how that data eventually cycles back as renewal opportunities, upsell triggers, and customer history into the CRM itself.

That foundation gave me something most CRM specialists do not have: a working understanding of the full data lifecycle, not just what happens inside the CRM but what the rest of the business does with what it produces. When I turned that systems knowledge to CRM specifically, spending the last eleven years on lead management, contact governance, Marketing spend attribution, and opportunity management, I brought with me an understanding of the system of systems that CRM sits inside. That is what allows problems to be traced to their real source rather than their most visible symptom.

The experience that matters

Most CRM consultants start with the tool. I start with how the system actually behaves in production: the accumulated configuration decisions, workflow logic, data governance practices, integration choices, and operational history that determine real outcomes. That distinction matters because the tool is rarely the problem. The system encapsulating it is.

CRM systems are usually maintained via quarterly patching, multiple projects all applied in one go, from different teams, that need to be robustly developed and analyzed across functions to ensure proper behavior and continuity. I participated in significantly over 100 quarterly windows, each with potentially multiple projects that I managed. That depth of production experience created a diagnostic discipline that cannot be replicated through vendor certifications, consulting frameworks, or tool-specific training. This vast experience and mastery has enabled me to now see structural patterns others miss because I have lived the consequences of bad architectural decisions, missed dependencies, and siloed thinking. All of this at Enterprise scale, the same systems and business ecosystem, across time, seeing short, medium and long term effects of these decisions.

One area of that experience warrants specific mention. For eleven years I was the operational owner of Oracle's global CRM contact dataset, a record set that ranged over time between 12 and 25 million contacts across every Oracle business unit and geography. In that role I acted as data steward, subject matter expert, and de facto global process owner for contact data quality. I designed and operationalized the governance model that reduced duplication to under 0.5% and maintained it there over time. In 2026, as organizations layer AI on top of contact datasets that have never been properly governed, that experience is directly relevant. AI does not fix ungoverned data. It amplifies the consequences of it and it does it very, very quickly.

Diagnosis is only part of the work. Most consultants stop at the symptom and fix what they can see. I use symptoms as evidence. They are clues to something more structural underneath. The real work is deducing what that structural cause is before touching anything. Understanding what is wrong tells you where to look. It does not tell you what right looks like. That requires reasoning from first principles, setting aside existing system logic and asking a more fundamental question: what is this process actually for? It is that combination of production systems experience, diagnostic precision, and first-principles reasoning that makes the difference between a fix that holds and one that regenerates the same problem in a different form with different symptoms.

How I work

I work alongside client teams, not in place of them. I advise, guide, and transfer knowledge. The client's team does the work and owns every outcome. The goal is not to make myself indispensable. It is to make the team capable, able to confidently diagnose and govern their own systems independently.

I work with two kinds of organizations. Those building or scaling their CRM systems who want to design correctly before problems accumulate. And those with mature environments where systems have drifted from operational reality. In both cases the approach is the same: understand what is actually happening before recommending anything.

Frequently Asked Questions

  • Thirty years of working inside production revenue systems at global scale, across multiple acquisitions, each with different business models, processes, and system architectures that had to be understood, translated, and integrated into Oracle's existing operational framework, helped produce the diagnostic capability that this practice is built on. That capability is not Oracle-specific. The structural problems that cause CRM environments to drift from operational reality occur in every organization that runs a CRM system, regardless of size, sector, or platform. The diagnostic methodology follows the data, not the platform. The platform itself is just a means for execution of the intent.

  • The experience was built at enterprise scale but the problems are not exclusive to large organizations. A scaling B2B company with a CRM environment that has drifted from how the business now operates has exactly the same class of problem as a large enterprise. The diagnostic approach is the same. What changes is the scope and complexity of the environment, which affects the scale and duration of the engagement, not the methodology.

    One practical requirement applies regardless of organization size. The engagement model depends on a client-side team to work with. The diagnostic transfers knowledge and capability to that team as the work progresses. Without a team to work with, there is no knowledge to transfer and no one to own the outcomes. For very small organizations that do not yet have a dedicated Revenue Operations function, the engagement can work with current leadership across relevant functions, particularly where the work is focused on defining the right architecture as the organization builds capacity rather than diagnosing drift in a mature environment.

    If the problem is structural and there are people on the client side committed to resolving it properly, the size of the organization is not a barrier.

  • Full engagement pricing is on the Services page. All engagements start with a free 30-minute Discovery Call. That conversation establishes whether this is the right kind of problem for this practice and what the appropriate engagement model looks like. Pricing is discussed once scope is understood, not before.

  • Yes. The Problem Solver Call is designed exactly for this. A specific, contained CRM system question that needs a considered answer rather than a full diagnostic engagement. One hour intake call, up to 48 hours thinking time, one hour response call.

    It also serves as a low commitment way to experience the practice before deciding whether a fuller engagement makes sense. If the output demonstrates value, the conversation about next steps tends to follow naturally.

    Full details are on the Services page.

  • The right kind of problem is a structural one that the internal team cannot resolve on their own, or cannot resolve in a reasonable timeframe without external perspective. If the problem has been looked at before and keeps coming back, if it feels intractable or confusing, if the team knows something is wrong but cannot locate where it lives, if resolving it would take longer than the business can afford to wait, those are signals that external diagnostic capability is needed.

    This practice is also the right fit for smaller or less experienced Revenue Operations teams that want to build diagnostic capability alongside resolving a specific problem. The engagement transfers knowledge as it works. The team comes out of it more capable than it went in.

    If your revenue team is producing workarounds to compensate for what the CRM cannot reliably produce, if reports require manual adjustment before anyone will stand behind them, if lead routing produces exceptions that someone has to sweep up, if contact data has become ignored despite repeated cleanup efforts, those are structural problems. They are diagnosable and they are the right kind of problem for this practice.

    If you are looking for someone to configure or implement a CRM platform, recommend a tool, or provide outsourced operational capacity, this is not the right practice for that work.

    If you are not sure, book a Discovery Call. That conversation will make it clear.