How I Approach Implementation
Understand the problem. Build what helps. Measure what changed.
This is the discipline I run on every engagement, from the first conversation to the numbers that show whether something actually changed. It was shaped by three decades of business, marketing and technology work. The value is in the judgment applied at each step, not in the diagram.
Understand
The business comes before the technology: goals, people, current processes, constraints and risks.
On a CRM rebuild, this meant reviewing the sales process before touching anything.
Diagnose
Find what is actually broken and what is merely annoying. The obvious problem is not always the important problem.
A read-only audit surfaced specific, fixable problems instead of a vague sense that the system needed work.
Prioritize
Weigh business value against effort, risk and readiness, and decide what gets fixed first.
A scored health framework doubled as the prioritization tool.
Design
Lay out the workflow before building anything: roles, tools, knowledge sources, approval points and documentation.
Task structures and automations get designed on paper before anything goes live.
Build
Configure the tools, create the templates and instructions, test the process and protect what is already running.
Work starts read-only and moves carefully, so nothing the team depends on breaks.
Put It Into Use
Train the people who will run it, document the system, collect feedback and help adoption stick.
A written handover packet and live walkthroughs, not a file dropped in a shared drive.
Measure
Track usage, time saved, quality, follow-up and business outcomes. Launching the system is not the finish line.
On the CRM rebuild it showed up in the score itself: 47 out of 100 to 86 out of 100.
Principles
What stays true on every engagement.
AI earns a place when it is useful. I do not start with the tool. I start with the business problem. Some processes are not worth automating, and knowing when to leave AI out is part of the work.
Human review stays in the process. Every stage has a human approval point, and nothing gets automated or adopted without the people who will use it signing off.
I am not tied to one favorite tool. Platform-independent judgment means recommending what the business needs, including better use of tools it already owns.
The system should outlast me. A system that only the builder understands is not finished. Documentation and training are part of the build, not an afterthought.
“A smaller solution that gets used is better than an impressive system nobody adopts.” That principle keeps the work focused on adoption and business value instead of complexity for its own sake.
Tell me what is not working.
Describe the problem in a few sentences. I will give you a straight answer about whether I can help and what a sensible first step would look like.