There a lot of firms producing training and technical literature; quite a few are darned excellent . . . but some are not. Here is why we are different.
Some firms are simply regurgitators who follow a pattern: They meet with SMEs for interviews, gather documents and notes you've already made, and then disappear for a few months. When they return, you have the same material all over again, only it has a new layout and is stuffed in a pretty binder with a fancy cover and spine. If you had wanted an expensive desktop publisher, you would have asked for one.
Another issue is training on your part. With some firms and writers, you spend so much time teaching them the system that you could have just done the work yourself. Later, when you get your desktop-published work in the binder and you ask, "Can you add a chapter on [whatever]," they answer, "sure, just supply us with the information." What that means is they want you to write it for them. What you want is people who can figure it out for themselves!
If you find during meetings that the firm's representative simply stares at you and takes notes -- never asking a question along the way -- then he or she may not really understand the material, or may simply be a regurgitator. The writer should be as comfortable with the subject matter as you desire your end users to be. Indeed, another way to put it is that you want a knowledgeable end user who can communicate to others how to do the job.
You all know the saying about "I just want to know what time it is, not how a clock works." Sometimes that's valid (as in the case of procedure documents), but we don't think that's the way to train. You've seen training materials that are really just a list of steps: Press x. The whatever screen appears. Press Y. The next screen appears . . . and so on for pages and pages. That's not training. That's a procedure.
While procedural steps are usually a part of training, there should be supporting information embedded within the steps that explains why you press x. When users understand how and why something works as it does, they don't have to rely on procedures to get the job done -- they'll know what to do because they know how the clock works.
Consider for example training on entering information into a database. If you can guarantee that 100% of the source information is received exactly as planned, then maybe procedures are all you need. But sometimes information doesn't arrive in the way you expect, and the trainee needs to know what to do in special cases. If the users know how the system really works, then they won't have to bug you with questions about issues that fall outside of the "expected" realm of incoming information.
Your rep should ask questions like "why does this work this way?" or "how is the data stored?" If the rep doesn't ask, then the rep doesn't care, and you will find that the result of your meeting is once again a nicely formatted list of steps -- something you could have typed up (and probably already have).
Along these same lines, some firms won't even go so far as to pose a question to something they know is incorrect. If you supply a bit if information that says "press [Enter] and this happens," but it turns out that something else happens, they'll put it in the book anyway, even though they know it's wrong. Some firms do this because when the book goes to press and the error is discovered, they can say, "Well, that's what you told us, so it's your fault. If you want it fixed, it will cost you $xx."
That's called working for you. TechKnowledge prefers to work with you. We not only want our product to be the best it can be, we want your product to be the best it can be. So if during development we discover issues -- error, omissions, or areas where the user could be confused -- we bring it to your attention. Now, not later.