7 questions to ask before hiring a documentation consultant

You’ve decided your documentation needs outside help. The product has outgrown what you have, or the knowledge base was never properly structured in the first place. You need someone who can fix it.

But not all documentation consultants work the same way. Some focus on the writing, while others focus on structure. If you hire the wrong fit, you can end up with a polished set of articles built on the same broken structure you started with.

Here are the questions worth asking before you sign anything.

1. Who exactly will be doing the work, and what is their experience level?

This is the question agencies hope you won’t ask.

It’s common practice to pitch a project with a senior consultant in the room, then assign the actual work to a junior writer once the contract is signed. The client doesn’t find out until something goes wrong, or sometimes not at all.

Ask directly: who will be writing the content and making structural decisions on my project? How many years of experience do they have? Have they worked on documentation for complex software products before?

If the answer is “a team” or “our writers,” push further. A consultant who can’t tell you who will be doing the work is telling you something important.

2. Is this a fixed-phase engagement or an open-ended retainer?

Some consultants and agencies operate on a retainer basis. The project starts, months pass, and before you know it, you’ve been paying for two years with no end in sight.

Ask how the engagement is structured before you start. Is the work broken into defined phases with clear deliverables at the end of each one? Can you make a decision about the next phase before committing to it, or are you signing up for the whole thing upfront?

A well-structured engagement should have a clear scope for each phase, a defined timeline, and something concrete you receive when it’s done. The audit should produce a written report. The architecture phase should produce a documented structure that holds regardless of who writes the content next. The rewriting phase should produce finished content, ready to publish. Each phase stands on its own.

3. What kind of documentation have they worked on?

Documentation experience is not all the same. Someone who has spent years documenting heavy machinery thinks in diagrams, parts, and physical components. That’s a different skill set from someone who has spent years documenting SaaS products and graphical interfaces, where the challenge is explaining complex workflows clearly to a wide audience.

Ask specifically: what types of documentation have you worked on? Customer-facing or internal? Software or hardware? End-user guides or API references? Have you worked on products that are genuinely complex, with multiple versions, configurations, or audiences?

The answers tell you whether their experience maps to your situation, or whether you’d be their first real attempt at your type of product.

4. Do they fix structure first, or do they start by writing?

This one tells you a lot.

Most documentation problems look like content problems. Articles are hard to find, information is inconsistent, and the same question gets answered differently in three different places. The instinct is to rewrite everything.

But what looks like a content problem is almost always a structural one. The rules behind the knowledge base were never defined: what to write, where it belongs, what role each article plays. So every new article becomes another ad hoc decision, and the mess grows.

A consultant who starts writing without first defining architecture is solving the wrong problem. Ask whether they apply a specific framework for writing and structuring articles, and what it looks like in practice. If they can’t describe it, that’s your answer.

5. Will the same person define the structure and do the writing?

Some agencies split strategy and execution across different people. An architect defines the structure, then hands it off to writers who implement it. That handover is where context gets lost.

If the person who defines the architecture is not the same person applying it, you end up with a gap between what was intended and what gets written. That gap shows up later, in inconsistencies and articles that don’t quite fit the structure they were supposed to follow.

Ask directly: one person or a team? If it’s a team, how does knowledge transfer between phases?

6. Is their approach built for AI, or is that something they’ve added recently?

AI support tools, chatbots, and search features pull from your knowledge base. When that content is inconsistent or poorly structured, AI surfaces wrong answers. At scale, that turns into support tickets, frustrated customers, and an AI feature that does more damage than good.

The question is whether AI readiness is genuinely built into how a consultant structures documentation, or whether it’s a line added to a website because everyone is talking about it.

Ask them to explain what specifically makes a knowledge base reliable for AI. What structural decisions matter, and why? If the answer is vague, they’re not the right fit.

7. What happens to the structure after you’re done?

A documentation engagement should leave your team with something they can maintain. Not a dependency on the same consultant indefinitely, and not a structure so complex that only one person understands how it works.

Ask what gets documented. Ask what your team will need in order to keep the knowledge base growing correctly after the engagement ends. A good answer includes things like placement rules, naming standards, and article templates that your team can apply themselves.

A final note

The right consultant will be able to answer all of these questions directly. If an answer is vague, or if the conversation jumps quickly to deliverables and timelines without addressing how the work actually gets done, keep asking.

Getting the structure right the first time is always faster than fixing it later.