Buyer's Guide
Choosing a Technical Publications Vendor
The Short Answer
Judge the Work, Not the Pitch
Technical publications work is hard to evaluate from a brochure. Every vendor says it knows the standards, and the difference only appears when it is asked something specific or handed a real file. So the strongest evaluation method is also the simplest: ask concrete questions, require a sample from your own material, and compare proposals on assumptions as well as on scope.
Before you start, settle what you are asking for. The scoping guide lists the inputs a vendor needs, and in-house versus outsourced helps with the earlier question of whether to outsource at all.
Criteria
Eight Things to Evaluate
- Standards depth
- Ask which standards and revisions the team has delivered against, and ask a working question about one: how a business rule is expressed, what tailoring in a TMCR changes, why one element sits where it does. Fluency shows in specifics. A vendor that lists every standard on the page but cannot discuss the one in your contract is a risk.
- A sample you can review
- Insist on a representative sample from your own material, including the hardest pieces, before committing to the full scope. Review it against your specification and your validation tools, not the vendor's. A sample is also the best test of how the team handles comments.
- Handling of controlled data
- If your data is export-controlled, marked, or distribution-limited, ask how the vendor receives, stores, and shares it; who can access it; where it is processed; and what is documented. Ask for written answers and what evidence backs them. A vendor should be able to say plainly what it can and cannot take on.
- Toolchain neutrality
- Ask which authoring environments, validators, and viewers the team has used, and whether the work can be done in yours. The right tools come from your program, not the vendor's preferences. Be cautious of a proposal that quietly requires you to adopt a proprietary format.
- Evidence of conversion and authoring work
- Ask for a description of comparable work: the source format, the target, the volume range, what broke, and how it was fixed. Specific lessons are better evidence than a logo slide. Where references are confidential, ask how the vendor would demonstrate the work instead.
- Staffing
- Ask who will write, who will review, and who your day-to-day contact is. Find out whether named people stay for the duration, how the team scales, what happens when someone leaves, and how writers get access to engineers. Staffing is where an otherwise good proposal most often thins out.
- QA and verification process
- Ask what is checked, by whom, and when: validation against the schema and business rules, technical review, editorial review, and verification against hardware where the contract requires it. A defined process with named gates beats the promise of being careful.
- Data ownership and handover
- Settle who owns the source files, the illustrations, and any business rules or scripts built for the project. Ask what the handover package contains and whether you could take the work to another vendor or in house. Our guide to technical data rights covers the contract side.
Controlled Data
Ask About Data Handling Early
Technical data often carries distribution limits or export controls, and the vendor becomes part of how that data is protected. Read distribution statements and ITAR technical data before you write the requirement, and take legal and security advice for your own case. This site cannot tell you what your data requires. What you can do is ask each bidder to state in writing how it would handle yours, and weigh the answers on clarity and evidence.
Warning Signs
Red Flags in a Proposal
- A price offered before anyone has seen your source material.
- Compliance claimed in general terms, with no discussion of how it is checked.
- No willingness to do a paid, bounded sample first.
- A deliverable that works only inside the vendor's tool or format.
- Vague answers about where your data lives and who can reach it.
- A proposal that is silent on review cycles, acceptance, and what happens when requirements change.
For tool decisions that sit alongside the vendor decision, see choosing S1000D tools. If the work is conversion, read what drives conversion cost. If you are weighing a hire instead, see hiring technical writers. For defense work, the contract review checklist shows what to pin down on your side first.
FAQ
Questions We Hear
What should a technical publications RFP ask for?
The deliverables and their specification and revision, the source data and its condition, the outputs and formats, the review and acceptance process, the data rights and handover terms, and the controlled-data handling you expect. Ask each bidder to describe its approach to your hardest material, not only to restate the requirements. Our guide to how manual work is scoped lists the questions to settle first.
Is it better to pick a specialist or a generalist?
Match the vendor to the risk in your program. A standards-driven defense or aviation deliverable rewards deep experience with that specification; a broad enterprise content program may benefit more from architecture and platform skills. Many programs need both, which is a reason to ask how the vendor would bring in the missing one.
Should we hire writers or outsource?
It depends on volume, continuity, and how specialized the standard is. Our guides to in-house versus outsourced technical publications and to hiring technical writers cover the trade-offs, including the cases where building the team is the right call.
How do we compare proposals fairly?
Score every bidder against the same list: the criteria above, weighted by your risks. Compare the assumptions as closely as the prices, since proposals that look different often rest on different assumptions about source quality, review rounds, and customer-furnished inputs.
Get In Touch
Ask Us the Hard Questions
We are happy to be evaluated on this list. Send a sample of your source and the specification, and we will show how we would approach it and what we would want to settle first.