How to Know if You Need a Consultant or Just Better Documentation
Half of "we need a consultant" conversations are really "the process only lives in one person's head" — and that one is fixed with an hour and a shared doc.
A lot of "we need a consultant" conversations start in the wrong place. The actual problem, half the time, is that the process only lives in one person's head. When that person is out, slow, or gone, the work stalls, and it feels like a systems problem because the symptom shows up in the system. It usually isn't.
Here's a rough filter I use on myself before I'd ever recommend bringing someone in. If the fix is "write down what Sarah already knows how to do," that's documentation, and it's cheap. It doesn't require new tooling, new automations, or an outside perspective. It requires an hour with the person who already has the answer and a place to put it where the next person can find it.
The cases that actually need outside help look different. The process itself is unclear, not just undocumented. Two departments disagree about who owns a step, and neither side is wrong given their own incentives. The system was built for a version of the business that doesn't exist anymore, and nobody inside the company has the bandwidth or the distance to see that clearly, because they're all too close to the daily version of the problem. That's a design problem, not a knowledge gap, and documentation won't fix it. It'll just write down the confusion more clearly.
A useful gut check: would writing this down actually solve it, or would you just end up with a very well organized description of something broken? If it's the second one, you've found the real work. If it's the first, save the money and write it down yourself this week.