I start with your pain points, not with tools.
Most technology projects go wrong by starting with the technology. Someone reads about a new tool, decides to adopt it, and then tries to figure out where it fits. That's backwards.
I start by understanding where you're overwhelmed. We focus on a small number of high-impact workflows — usually around documents, email, and follow-ups — and we don't add complexity unless it clearly reduces the bigger pain. When we're done, you have something you can run without me. That's the goal.
I ask questions that get past the surface. Not "what tools do you use?" but "where do you lose track of what's been done for clients?" Or "who is the person you wish you had three of, and what do they spend their time on?" Or "where does not keeping up cost you business?" The answers tell me where the real pain is — and that's what shapes everything else.
We walk through where information comes from — emails, documents, notes, forms — where it ends up, and where it gets lost. This isn't a formal audit; it's a conversation. Most people haven't thought about this explicitly, but they know exactly where the friction is once we start talking. That map tells us what a realistic workflow can actually fix.
We pick one pain point and build something targeted at it. That might mean a way to quickly find what you did for a specific client, a reminder system for follow-ups that doesn't rely on memory, or a way to process a flood of emails without reading every one. The solution is always as simple as it can be — and only uses tools that are already in the budget or clearly worth adding.
We run the workflow on real work — actual client files, actual emails, actual situations from your business. We adjust until it works reliably. And I leave behind a plain-English explanation of what it does, what it's made of, and how to tweak or fix it. The goal is that your team owns it, not that they're dependent on me.
I don't force specific tools. I pick a small set that fits what you already use and what the workflow actually needs. In practice, that usually means:
For each workflow, you get a clear plain-English explanation of what it does, what it's made of at a high level, and how to adjust or fix it when something changes. No black boxes, no "call George when it breaks." I aim to build things your team understands and can own.