Find out what’s actually failing before you spend more fixing the wrong thing.

Absolutely. They’re often some of the first people I want to hear from. Frustrated users will usually explain exactly where the process breaks, what Salesforce makes harder, what workarounds they’ve created, and how it affects their day-to-day work. I don’t assume their explanation of the root cause is automatically right, but I take the pain seriously. And when you involve the loudest critics in understanding and improving the problem, they can become some of the strongest advocates for the solution.

No. If you already knew the root cause, you probably wouldn’t need me. Bring the symptoms: the report nobody trusts, the field that keeps changing, the process users work around, the automation nobody wants to touch. My job is to help turn those signals into a clear explanation of what’s actually happening and what deserves attention first.

A traditional Salesforce health check is a bit like doing X-rays, CT scans, and MRIs without first talking to the patient or their family. The tests may show plenty of things worth noticing, but without understanding the history, the symptoms, and where the pain is showing up right now, it’s easy to jump to the wrong conclusion ..or spend time fixing something that isn’t actually causing the problem. Salesforce works the same way. We look at the system, data, automation, and technical debt, but we also talk to the people who use it, support it, and depend on it. The diagnostic evidence only becomes useful when you understand the context around it.

Sometimes. But first I’m going to ask why. A new Flow, dashboard, integration, field, or AI agent may absolutely be the right answer. I just don’t want your team spending money implementing a request only to discover that the real problem was the process, ownership, definition, or business decision underneath it. If the requested solution survives that test, we can build it with much more confidence.

Almost certainly not. Every mature Salesforce org has clutter and technical debt. The useful question is not, “Can we find things to clean up?” We can. The useful question is, “Which Salesforce problems materially threaten the outcome we’re trying to create?” We fix what matters, flag what can safely wait, and avoid turning “cleanup” into a permanent corporate hobby.

It shouldn’t. We start with a specific problem, outcome, or decision and expand the scope only when the evidence tells us the problem genuinely reaches farther. Sometimes that leads to a broader Salesforce implementation. Sometimes it leads to one targeted fix. Sometimes the best recommendation is to leave half the org alone. The scope follows the evidence ..not a predetermined consulting package.

We implement. Diagnosis itself is boring. The part we geek out on is solving the problems that actually affect employees, leadership, and customers. The diagnosis helps us avoid fixing the wrong thing; then we simplify the process, make the right Salesforce changes, improve the automation, address the dependencies that matter, and validate that the solution actually improved the outcome. And because the work has to live after we leave, we involve your team along the way so they understand what changed, why it changed, and how to own it confidently.

That’s usually the best way to work. The admin knows things leadership doesn’t. Users know where the official process and the real process diverge. IT understands dependencies and constraints. Leadership understands the business consequence. I help get those perspectives into the same conversation without assuming anyone is the problem. Then we build the solution with the people who will ultimately use and support it.

Yes. I’m not here to defend Salesforce. Sometimes the architecture, implementation, or platform really is part of the problem, and replacement deserves serious consideration. But a CRM migration does not automatically fix weak governance, unclear ownership, inconsistent definitions, poor processes, or low trust. Before spending heavily on a replacement, I want to know one thing: will the problem follow you into the new CRM?

No - and chasing perfect data can become its own expensive project. Salesforce AI readiness is use-case specific. We first define what you want AI to do, what information and business context that task depends on, what happens if the AI is wrong, and whether those dependencies are trustworthy enough for that particular use case. Some Salesforce issues may be blockers. Others may have absolutely nothing to do with the AI outcome and can wait.

Enough access to follow the evidence ..but we don’t automatically ask for the keys to the kingdom.Depending on the problem, that may include Salesforce access, relevant reports or documentation, and conversations with the people who understand the process, use the system, or own the outcome. We agree on the scope first and ask for what the investigation actually requires. Context is often just as important as configuration.

That’s normal ..and often useful. Sales may experience the problem one way, Finance another, and the admin may be looking at an entirely different part of the system. I don’t need everyone to agree before we start. I need the different perspectives in the room so we can separate assumptions from evidence and figure out what is actually happening.