Feature
A Structured Approach to Selling
By Mike Unwalla
High-value goods and services are not impulse purchases. Both the purchaser and vendor may need to invest significant time in the purchasing process. When I first started working for myself, I wasted much time. Now I make the process as efficient as possible, both for myself, and for enquirers (I use the term 'enquirer' to mean 'potential client'). This article cover three broad areas:
- managing expectations
- defining the need (business case)
- producing the proposal
Managing expectations
Sometimes, enquirers do not know what they want or what to expect, so education is important. They know that their documentation needs to be improved, but usually, they have never used an external company before.
Early in the discussions, enquirers often ask about typical time scales and fees for projects. Until I have investigated their problems, I do not know (and they know that I cannot know). I tell them about previous projects, and that usually satisfies them. They have enough information to know whether they want to continue the discussion.
Enquirers sometimes have unrealistic expectations of what consultants can do. They think that if they provide source material, I can convert that into user documentation. In feedback from clients, a common comment is, "we didn't realise how much effort would be required on our part." That occurs despite telling them that they will need to make a significant investment of time.
Some enquirers do not understand the real value that technical communicators (technical writers) bring to a company. They focus on skills such as language ability, editing, and ability to use software tools. Certainly, those skills are important. However, the real value that technical writers bring is in the ability to gather information from disparate sources, clarify conflicts and ambiguities, and then present the information to readers in a clear manner. To help enquirers to see this, the TechScribe website contains many articles and case studies that explain the issues.
Occasionally, enquirers are not sure whether to employ a technical communicator or use the services of a freelance. My company's niche is helping software companies that do not have enough work to employ a full-time technical communicator. For long projects, I direct people to recruitment agencies that specialise in finding technical communication professionals.
The Business Case: Defining the Need
What is the enquirer's need for the documentation? What problems will it solve? Is documentation the best solution? What is the cost to the company of not having documentation? If no business case exists, the project will not start.
In the past, I wasted much time on potential documentation projects. In my naivety, I would spend two or three days investigating software and the existing documentation. Then I would discover that the enquirer had no real need, or did not have authority to spend, or was just testing the market to see what was available.
Therefore, early in the process, the enquirer completes a business requirements checklist. That helps to establish the needs of the company. Only the enquirer can do the numbers to make the business case, but I can help the enquirer to become clear about objectives. If the likely cost of designing documentation is greater than (or even the same as) not having documentation, no business case exists.
The enquirer, or someone else in the company, completes a documentation requirements checklist. That gives me an overview of the enquirer's vision of the documentation, the users (the audience), and the software. Getting to the core of the enquirer's problem is essential.
The two checklists are the starting point for more discussion. When the real issues are clear, and the constraints within which a solution must exist are defined, I can suggest solutions that will work for the enquirer.
At this stage, I know that the enquirer has the money, the authority, and the need. Based on the information supplied by the enquirer, I give an estimate (one metric that I use is the number of unique screens, tabs, and dialogs in the software). If the estimate is acceptable to the client, I visit the enquirer for detailed discussions, to learn more about the software, and to meet people who will be involved in the project.
Producing the proposal
After the site visit, I produce a proposal. This reflects back to the enquirer the information that I gathered about their problems, their software, and the people who use the software. One section deals with the deliverables. (The proposal also deals with time scales, the fee, the validity period, and terms & conditions. For more information, see www.techscribe.co.uk/ta/HowToWriteATender.pdf.)
You may wonder how it is possible to specify deliverables at this stage. I still do not have a deep understanding of the software, and I do not know how big it is (although enquirers supplied a number in the documentation requirements checklist, the number is often an estimate). Therefore, it would be foolish to state what I will produce and to offer to do this for a fixed fee. However, the enquirer naturally wants to receive a firm quote.
To resolve this conflict, the first deliverable is a documentation plan (project plan), for which I charge a fixed fee. I investigate the problem in detail and scope the project. The documentation plan will include the draft structure for each document that I intend to produce. I also provide a fixed-price quote to produce the documentation that is specified in the documentation plan. The enquirer (now a client) is not tied to using my company to produce the documentation, and is free to take the documentation plan to another provider (of course, that is extremely unlikely to happen).
For detail about the process, and to read the checklists, see www.techscribe.co.uk/techw/purchasing-process.htm.
In summary, to produce a proposal that has a good chance of being accepted, and to avoid wasting both my time and the time of an enquirer, I do the following:
- Educate the enquirer about what I can do and what I cannot (or will not) do.
- Understand the true needs of a company and help an enquirer to define a business case for documentation.
About the author
Mike Unwalla operates a software documentation consultancy in the UK. He helps software companies to improve the quality of their user documentation. Email: mike@techscribe.co.uk Web: http.www.techscribe.co.uk
************
Mike Unwalla operates a software documentation consultancy in the UK. He helps software companies to improve the quality of their user documentation. Web: http://www.techscribe.co.uk.