Technical Sales & Pre-Sales

Introduction

A company wins a three-room installation with a proposal that promised "excellent speech coverage throughout". On handover day the client's facilities manager stands at the back of the largest room, says it is not excellent, and withholds the final payment. Nobody can prove them wrong, because nobody wrote down what excellent meant.

That is a pre-sales failure, and it happened months before a cable was pulled. Pre-sales is the technical work done before a sale closes: finding out what the client needs, turning it into something that can be designed and checked, surveying the place it has to work in, estimating what it will take, and writing it down so that the client, the salesperson and the crew all mean the same thing.

Technicians are well placed to do this work, because every part of it rests on knowing how a system really behaves in a real room. What most technicians have not been shown is the method. There is one, and it is older and better documented than the AV trade: engineers have a way of writing a requirement so that it can be tested, a sales textbook sets out who is inside an organisation's buying decision and what each of them wants to hear, and procurement rules state exactly how a written proposal is scored.

This book teaches that method in AV terms. It follows one piece of work from the first conversation to the day the crew takes it over, and at each step it gives you the thing to write down.

How to Use This Book

Read it in order the first time. It follows the work: what the role is, who is buying, what they need, how to write that need as requirements, the site survey, the design, the estimate, the tender, the proposal, and the handover to delivery.

After that, four chapters work as documents to keep open while you do the job. Writing the Requirement is a checklist to run over any specification before it goes out. The Site Survey is a list to carry into a building. Estimating the Work is a list to run over a number before it becomes a price. And Answering a Tender is worth rereading the day a tender document lands.

Keep a notebook

One page per opportunity. Write the need in one sentence, the people in the decision and what each cares about, the constraints you found on site, the assumptions your estimate rests on, and, when the job is over, which of those assumptions turned out wrong. After ten jobs the last line is the most valuable thing you own, because your estimates are wrong in the same direction every time and only a written record shows you which.

A note on the words

"Pre-sales" in this book means the technical work before the sale closes, whoever does it. In a large integrator that is a named job; in a small company it is the senior technician on a Tuesday afternoon. "The salesperson" means whoever holds the client relationship and the price, which may also be you. A "requirement" is a statement of what the system must do, written so that somebody can check it. A "constraint" is a condition the design has to live with and cannot trade away. And "tender" is used for any formal written competition, including the document North American buyers issue as a request for proposal, or RFP.

A note on safety

The pre-sales person decides, on paper, how heavy the load is, how high it hangs, how much power it draws, how many people lift it and how long they have. Every one of those is a safety decision made by somebody who will not be in the room.

So three rules run through this book. A structural question — what a ceiling, a truss or a floor will carry — is answered by a person qualified to answer it, in writing, before the design is priced, and never by the person selling. Electrical capacity is confirmed with the venue's own electrician or engineer, and never read off a breaker label and assumed. And crew numbers and working hours in an estimate are set by what the work safely needs. They are the last thing to be cut when a price has to come down, and in practice they are not cut at all.

If a client's budget only works with fewer people or less time than the job needs, the honest pre-sales answer is a smaller system, and saying so is part of the job.

What Technical Sales Is

Two people win a technical sale between them. This chapter is about which of them owns what, and why the join between them is where most bad jobs begin.

Selling solutions as the technical expert.

Selling technical solutions

Technical sales (and pre-sales) is selling technical AV solutions — not just products, but systems and solutions that meet a client's needs. The technical sales/pre-sales professional is the technical expert in the sales process: they understand what the client technically needs, design or scope the right solution, and help sell it (often supporting a salesperson, or selling directly). Where general sales sells and relationship-manages, technical sales brings the technical expertise to design and propose the right solution. Technical sales sells the right technical solution to the client's need.

This matters because AV is technical — clients buying AV systems need a solution designed and scoped to their needs, and the technical sales/pre-sales professional provides that expertise in the sales process, making sure the right solution is proposed and the client's technical needs are met. It's essential to selling AV systems (as opposed to simple products). Technical sales is the technical expertise that wins AV solution sales.

Pre-sales and the role

'Pre-sales' refers to the technical work before the sale closes — understanding the client's technical needs, designing/scoping the solution, preparing the technical proposal and quote — that supports winning the deal. The pre-sales/technical-sales professional often works with a salesperson or account manager (who manages the relationship and commercial side) as the technical expert (designing the solution and handling the technical aspects), or combines both roles. Pre-sales is the technical solution work that supports and wins the sale.

This role (the technical expert in the sales process) is key in AV selling: the salesperson/account manager owns the relationship and deal, and the pre-sales/technical person owns the solution (what's actually being sold technically). Together they win solution sales. The technical sales professional provides the solution expertise that wins deals.

Two people and their opposite numbers

The sales textbook this book draws on describes how technically complicated products are sold to organisations: selling is sometimes performed by a team, with each member working with their opposite number in the buying team, and its example is a sales engineer working with the engineers in the buying company.

That is the shape of most AV sales above a certain size. The salesperson or account manager talks to the person who holds the budget and signs the order. The pre-sales person talks to the client's technical people: the IT manager, the facilities manager, the in-house AV technician, the venue's production manager. Each pair speaks its own language, and the sale is won when both pairs are satisfied.

The reason for the pairing is credibility. A client's IT manager can tell within a few minutes whether the person opposite them has configured a network switch, and no amount of charm replaces the answer. Your opposite number is the person who will be asked afterwards, in private, "does this lot know what they are doing?" Your job in the meeting is to make that an easy question.

Who owns the solution

The cleanest way to divide the work is this. The salesperson owns the relationship and the commercial terms: who the client is, what they can spend, when they will decide, what the price and payment terms are. The pre-sales person owns the solution: what is being promised, whether it will work in that room, what it takes to deliver, and what it will not do.

"Owns the solution" has a hard edge to it. It means no statement about what the system will do goes to the client without your agreement, and it means that when the crew arrives and something promised cannot be built, the question comes back to you. That is uncomfortable and it is the protection the whole company depends on, because the salesperson is rewarded for the order and somebody in the room has to be answerable for whether it can be delivered.

The trouble starts in the gaps. A salesperson, alone in a meeting, is asked whether the system can also stream to three overseas offices and says yes because it sounds reasonable. Nobody tells pre-sales. The proposal goes out without it, the client signs believing they bought it, and the argument arrives on site. The fix costs nothing: a standing agreement that any technical yes given without you is repeated to you the same day, in writing.

In a small company one person holds both roles. The division still matters, because the two roles pull in different directions and you will feel it: the half of you that wants the order will want to say yes, and the half that owns the solution has to be allowed to check first.

Why a show or a system is hard to buy

Most of what AV companies sell is a service, even when boxes are involved, and the textbook is specific about what makes services different. It lists four characteristics. A service is intangible: it cannot be displayed or handled in advance. Production and consumption are hard to separate: much of it is made as it is used. It is variable: services are not standard and are harder to assess for value. And it is perishable: it cannot be stocked, in the way an unsold hotel room cannot. Its table adds a fifth difference, ownership: the buyer of a service does not come to own anything, and pays for access to its use.

Put those in AV terms. A client buying sound for a conference cannot hear it before the day. The service is made live, in front of their own audience. The same crew with the same equipment will produce a slightly different result in a different room. A crew that was booked and not used on Tuesday cannot be sold again on Wednesday. And a hire client owns nothing when the truck leaves, which is why the memory of how the day went is the whole of what they bought.

The textbook's conclusion is the one to hold on to: unlike a physical product, it is never possible to know precisely what will be received until the service is rendered, so an element of trust is essential. It also notes that those who provide a service are often the ones who sell it, which is the case for the technician doing pre-sales.

The same passage names what a seller can do about intangibility. It adds three things to the usual marketing list for services: people, process and physical evidence. In pre-sales those are your tools. People: the client meets somebody who will be on the job. Process: you show them how the work will be run, step by step. Physical evidence: drawings, a written requirement, photographs of a comparable job, a clean and specific proposal. Each one turns a promise the client cannot inspect into something they can.

How to do it

1. Agree with the salesperson, by name, who owns the relationship and who owns the solution.
2. Find out who your opposite number is on the client side and ask to meet them.
3. Agree that any technical yes given without you is passed to you in writing the same day.
4. Agree that nothing describing what the system will do goes out without your review.
5. Decide what physical evidence this client will see before they decide, and who prepares it.
6. Keep one shared record of everything promised, and date each entry.

What goes wrong

Practice it

Think of the last job your company won that went wrong on site.

Who Is Buying

An organisation does not buy; several people inside it do, and each of them is listening for something different.

More than one person decides

The textbook sets out what distinguishes selling to businesses, institutions and public bodies from selling to a household. There are fewer customers and each purchase is worth more. And the purchasing decisions are complex: they often involve a large number of people, particularly in a public authority, where a purchasing committee may be involved in a major purchase.

It then names who tends to be in the room. Many decisions involve more than the buyer: the technical specifier, production personnel and finance personnel are involved too. And it says what each wants. Specifiers need to be convinced of the technical merits. Production people want to be assured of delivery. Buyers will be looking for value for money.

The consequence the textbook draws is that this can prolong negotiation and decision-making, and that the seller has to communicate with people in a variety of positions and tailor the approach to each. A single presentation aimed at one of them leaves the others unanswered, and any of them can stop the purchase.

The same people, in an AV job

Translate those roles into a corporate installation. The specifier is whoever wrote down what the rooms need, often the IT or facilities manager and sometimes an outside consultant. The production people are the ones who will use and look after the system every day: the reception team who book the rooms, the in-house technician, the executive assistant who will be telephoned when it does not work. Finance is the person who has to justify the money. And the buyer is procurement, who may never have seen the rooms.

For a live event the names change and the pattern holds. The event producer specifies. The venue's technical manager and the show caller live with the result. The client's finance lead approves the spend. And an agency or a procurement team may place the order.

The table below is a working version. Before any proposal is written, fill in a name beside each role, and if a row is blank, that is your next question to the salesperson.

Systems engineers reach the same place from a different direction. NASA's handbook defines a stakeholder as a group or individual affected by, or with a stake in, the product, and observes that the customer and the users of a system are usually easy to identify while the other key stakeholders may be harder. In AV the hard-to-find ones are nearly always the people who maintain the system and the people whose network or building it has to live in.

A long relationship, and losing well

Two more points from the same section shape how a pre-sales person behaves. The first is that selling in these settings builds long-term relationships in which each side comes to depend on the other, and that high-pressure technique is likely to be counter-productive. A more considered approach, identifying each customer's needs and showing how they are met, is the one the textbook expects to succeed, and it adds that the ability to deal with complaints and provide reliable after-sales service is important.

The second concerns work that is made to order. The textbook describes job or project production, where an item is constructed to an individual customer's requirements, and every AV installation and every show is exactly that. Its observation is that losing such an order is not normally critical: as long as the firm has been professionally represented, it should be invited to quote for the next one.

That is a practical instruction. In project work you will lose more often than you win, and the client's technical people will remember how you behaved while losing. A survey done properly, a question that showed you understood their building, a proposal that was honest about what the budget would and would not buy: those get you invited back. A design padded to hit a price, or a promise their own technician knew was wrong, does the opposite.

How to do it

1. Ask the salesperson who signs, who specified, who will use it and who will support it.
2. Write a name beside each of the five roles, or mark the row blank.
3. For each name, write the one thing they most need to hear and whether they have heard it.
4. Ask to speak to the daily user and the support person, even briefly.
5. Check the proposal answers every row, including the rows whose owners you never met.
6. After the decision, win or lose, note which person carried it.

What goes wrong

Practice it

A hotel is replacing the AV in its ballroom. The general manager has asked your company for a proposal.

Understanding the Need

A client arrives with a list of equipment. The need is the problem behind the list, and it is written in one sentence before anything is designed.

Understand the client technically and commercially.

Technical needs

Technical sales starts with understanding the client's technical needs — what AV system or solution they actually need to achieve their goals (the technical requirements, the use case, the space and constraints, the technical specifics). The technical sales professional uses their expertise to understand and define what the client technically requires, often better than the client can themselves. This technical understanding is the basis for designing the right solution. Understanding the technical need is the first job of technical sales. The technical sales professional understands what the client technically needs.

This requires technical expertise plus the consulting skill to draw out and understand the need (listening, questioning, assessing). A correct understanding of the technical need leads to the right solution; a poor one leads to the wrong proposal. The right solution starts with understanding the technical need.

Commercial understanding

Technical sales also requires commercial understanding — grasping the client's budget, business case, decision process, and what they value commercially, plus the deal itself (pricing, margin, terms). The technical sales professional balances the technical (the right solution) with the commercial (a deal that works for the client and the company), proposing a solution that meets the need within the budget and wins the business. Understanding the commercial side (not just the technical) is essential to technical sales. The technical sales professional understands the client commercially as well as technically.

This dual understanding (technical + commercial) is what makes technical sales effective: the solution must be technically right and commercially viable (fitting the budget, making business sense, winning the deal). The technical sales professional bridges both. Technical sales balances the technical solution with the commercial deal.

One sentence that is not a solution

Clients describe what they want as equipment, because equipment is what they can picture. "We need two big screens and a better microphone." The first job in pre-sales is to get from that list to the problem it is meant to solve.

NASA's systems-engineering handbook gives the cleanest definition available. A need is the answer to the question "What problem are we trying to solve?" The handbook's fuller definition is a single statement that drives everything else, which should relate to the problem the system is supposed to solve but not be the solution.

It also insists the need statement is singular. Trying to satisfy more than one need requires a trade between them, which can easily end with at least one expectation unmet.

Take the two screens and the microphone. Ask why, and then ask why again. The screens are because people at the back cannot read the slides. The microphone is because the chief executive could not be heard at the last staff meeting. One need statement covers both: "Everybody in the atrium must be able to see and hear a presenter at the quarterly staff meeting." No equipment is named, and the client will recognise it as their own problem the moment they read it.

Write that sentence at the top of the page and read it back to the client. If they correct it, you have just saved the job.

Goals, objectives and limits

The handbook builds two more layers on the need. Goals are an elaboration of the need: a specific set of expectations for the system, which need not be measurable but should let you assess whether the system achieved them. Objectives are specific target levels the system must achieve, each relating to a particular goal.

It gives four tests for an objective. It should be specific enough to give clear direction. It should be measurable and verifiable. It should be aggressive but attainable. And it should be results-oriented, focused on the outcome and not on the method: what, not how.

For the atrium, a goal might be that every seat can read the slides. An objective under it gives the number: the smallest text on a standard company slide is legible from the furthest seat, which is twenty-eight metres from the screen position. A second goal is that the presenter is heard clearly, with an objective about speech level and evenness across the seating area.

The handbook asks for traceability between the three: if a goal does not support the need, or an objective does not support a goal, it should not be in the set. That rule is how you deal with the extra requests that pile up in a discovery meeting. A director asks for colour-changing lights in the atrium. Does that support the need? If not, it is a separate piece of work with its own price, and you can say so without refusing.

Then come the limits. The handbook says stakeholders put bounds on the achievement of goals, and lists the kinds: what can be spent, the time to deliver, support over the system's life, operational constraints, training. In practice those are five questions. What is the budget? When must it work? Who looks after it afterwards? What can we not touch or change? And who needs to be taught to use it?

The handbook's reason for doing all this in the open is worth quoting to a doubtful colleague: when the customer, the other stakeholders and the engineer agree on what the product will do, it sets more realistic expectations on the customer's part and helps prevent significant requirements creep later.

The business case, and how they will decide

Commercial understanding, alongside the technical, means knowing the client's budget, their business case and their decision process. Those are three separate questions, and a pre-sales person needs the answer to each before designing anything.

The business case is the reason the money is being spent, in the client's own accounting. It is nearly always one of four things. Something is costing them now: meetings that start late, a technician called out every week, equipment hired in for every event because the installed system cannot be trusted. Something is at risk: an annual meeting that failed in front of the board. Something new has to happen: staff in three cities who now have to be in one meeting. Or something has reached the end of its life and can no longer be repaired.

Ask which, and ask what it is worth to them. You are not looking for a number to quote back. You are finding out how large an answer the problem can pay for. A client losing ten minutes at the start of every meeting in a room used six times a day has a problem worth a reliable control system. A client who holds one town-hall meeting a year may be better served by hiring a crew for the day than by any installation, and telling them so is the kind of advice that brings the next enquiry to you.

The business case also tells you what to protect when the budget tightens. If the reason for the purchase is that the chief executive could not be heard, speech is the last thing to be cut and the colour-changing lights are the first.

The decision process is the third question, and the salesperson will usually hold the answer, so ask them. Who decides, and who only recommends? Is it one signature or a committee? Is there a formal tender, and if so when is it issued? When does the client's budget year end, and does this money have to be spent before then? Has the money been approved, or is your proposal the document that will be used to ask for it?

That last answer changes what you write. A proposal that will be used to request funding has to make the business case for the person carrying it upstairs, in a paragraph they can lift out. One going to a client with approved money can be shorter on why and fuller on how and when.

Walk through the day

The strongest tool in the handbook for finding what nobody told you is what it calls the concept of operations: a description of how the system will be used, written as scenarios, which states what is expected without saying how the design will achieve it. Its claim is that thinking through the use cases often reveals requirements and design functions that might otherwise be overlooked.

In pre-sales that is a conversation you can have in twenty minutes. Ask the client to walk through the day with you, from the first person who touches the system to the last. Who arrives first and switches it on? Where does the presenter stand, and do they bring their own laptop? Who is watching remotely? What happens between sessions? Who switches it off, and what happens if they forget?

Each answer is a requirement nobody had stated. The presenter brings their own laptop, so there must be a connection at the lectern for whatever they carry. Forty people watch from another office, so there must be a camera and a way to send sound. The receptionist switches it on, so the control must be one button and not a rack of equipment.

Then ask the question the handbook is firm about. The concept of operations should include known off-nominal situations: malfunctions and degraded operation. In plain terms, what happens when something has failed? If the presenter's laptop will not connect, what do they do? If the network is down, can the meeting still run in the room? If the one person who knows the system is on holiday, who starts it?

Clients seldom raise these themselves and are always glad to be asked. The answers decide whether the design needs a spare input, a local recording, a printed start-up card. They also tell you, more honestly than any other question, how much failure this client can tolerate, and that sets how much backup the budget has to carry.

How to do it

1. Take the client's list and ask why for each item, twice.
2. Write one need statement that names the problem and no equipment.
3. Read it back to the client and correct it until they agree.
4. Write the goals under it, and one measurable objective under each goal.
5. Ask the five limit questions, covering budget, date, support, what cannot change, and training.
6. Find out the business case behind the money, and how and when the client will decide.
7. Walk through a full day of use with the client, first person to last.
8. Walk through it again with something broken, and write down what they expect to happen.

What goes wrong

Practice it

A school principal writes to you. "We need a new projector and speakers for the hall."

Writing the Requirement

A promise the client cannot check is a promise you cannot prove you kept. This chapter is how to write one that can be checked.

Shall, will and should

Engineers use three ordinary words with fixed meanings, and NASA's handbook sets them out in a single line each. Shall is a requirement. Will is a fact or a declaration of purpose. Should is a goal.

Used with care, those three words sort a proposal into what you are bound to deliver, what you are simply stating, and what you will aim for. "The system shall display a laptop image on both screens within ten seconds of connection" is a commitment. "The client will provide a network connection at the rack" is a statement of fact about the job. "Cable routes should be concealed where the building allows" is an aim.

The handbook's form for a requirement about a product is "The product shall", followed by a verb and a description of what should be done. Its examples run "The system shall operate at a power level of…" and "The structure shall withstand loads of…". It asks for complete sentences with a single shall in each.

You do not have to write a whole proposal in this style, and a client would find it stiff if you did. The place for it is the short list of things the system must do, usually ten to twenty lines, which sits inside the proposal and becomes the test on handover day.

What, how well, and why

The handbook separates two kinds of requirement that people run together. Functional requirements define what functions need to be performed. Performance requirements define how well the system needs to perform them, and are expressed as a quantitative measure.

Its worked example starts from a single function statement about a rocket's steering and turns it into four lines, each with a number and a tolerance. The AV equivalent takes a minute. Function: "The system shall reproduce speech from the lectern microphone throughout the seating area." Performance: "Speech level across the seating area shall not vary by more than six decibels, front row to back row." The first says what. The second says how well, and it is the one you can measure.

The handbook's editorial checklist adds the rule that keeps a requirement honest. Requirements should state what is needed, not how to provide it: state the problem, not the solution. And it gives the question to ask when one creeps in, which is "Why do you need the requirement?" A client's document that says "the system shall use four ceiling loudspeakers" has specified a solution. Ask why, and the real requirement is even coverage, which four ceiling loudspeakers may or may not give in that room.

It also asks that each requirement carry its rationale, the reason it exists, together with any assumptions behind it, because the reason is often not obvious and is lost if it is not recorded at the time. In a proposal that is one short clause. "…within ten seconds of connection, because meetings in this room start on the hour with no technician present." Six months later, when somebody proposes a cheaper switcher that takes forty seconds, that clause is what stops them.

One more idea from the same section earns its place. The handbook asks for the key driving requirements to be identified: those that can have a large effect on cost or schedule. In most AV jobs two or three lines carry half the money. "Shall be operable by untrained staff" drives a control system. "Shall be readable in daylight" drives the display choice. Mark them, and tell the client which they are, because those are the lines where a small change in what is asked makes a large change in the price.

Words that cannot be checked

The most directly useful thing in the handbook's appendix is a list of words. It asks whether the requirements are free of unverifiable terms, and names them: flexible, easy, sufficient, safe, adequate, user-friendly, usable, fast, portable, robust, quickly, easily, clearly, when required, if required, appropriate, along with others ending in "ly" and "ize".

Read that list again as an AV person and you will recognise every proposal you have ever seen. "User-friendly control." "Clear, even coverage." "Robust wireless." "Sufficient inputs." None of them can be tested, so none can be shown to have been delivered, which is how the facilities manager in the Introduction came to withhold the payment.

The repair is always the same: replace the word with the test you would accept. "User-friendly" becomes "a member of staff who has never used the system shall be able to start a presentation from the printed card without help". "Sufficient inputs" becomes a number. "Robust wireless" becomes a count of channels that shall operate at once, in that building, without dropouts over a stated period.

The handbook's check for this is that every requirement can be verified, and it names four ways: the system can be tested, demonstrated, inspected or analysed to show that it satisfies the requirement. For each line you write, note which of the four you would use. If you cannot pick one, the line is not finished.

Two smaller rules from the same checklists are worth adopting. Express one thought per requirement, so that a line cannot be half met. And keep "to be determined" to a minimum: the handbook prefers a best estimate marked "to be resolved", with a note of who will resolve it and by when. In a proposal that reads "ceiling load capacity to be confirmed by the building's structural engineer before order", which is honest and puts a name on the open question.

Last, the handbook lists six questions for validating a set of requirements before design begins. Are they written correctly? Are they technically correct? Do they satisfy the stakeholders? Are they feasible? Are they verifiable? Are any redundant or over-specified? Run the six over your list before the proposal goes out. The fourth is the one that protects you, since a requirement you cannot meet in that room is far cheaper to find now.

How to do it

1. Start from the agreed need, goals and objectives, and the walk through the day.
2. Write each thing the system must do as one sentence with one shall.
3. For each function, add how well, with a number and a tolerance.
4. Strike every unverifiable word and replace it with the test you would accept.
5. Add the reason to any line whose purpose is not obvious.
6. Beside each line, note how it will be checked, whether by test, demonstration, inspection or analysis.
7. Mark the two or three lines that drive the cost, and anything still to be resolved, with a name and a date.
8. Run the six validation questions over the whole list.

What goes wrong

Practice it

A draft proposal for a boardroom contains these four lines. Rewrite each so it can be checked.

The Site Survey

The room decides what can be built. A site survey is how you find out what the room has already decided before you put a price on it.

What a constraint is

NASA's handbook defines a constraint as a condition that is to be met, and it describes where they come from: sometimes external factors, sometimes an existing system that must be used, sometimes a regulation, sometimes the budget. When it reaches the design stage it adds the property that matters most. Constraints typically cannot be changed based on trade-off analyses.

That is the difference between a requirement and a constraint in practice. A requirement can be negotiated: the client can accept a smaller screen for less money. A constraint cannot. The ceiling carries what it carries. The loading door is as wide as it is. The electrical supply to the room is what was installed in 1998.

The handbook's first design step is to establish the design boundary, and it lists what that involves: defining the constraints the design must adhere to, identifying the elements that are already fixed and cannot be changed, and identifying the external systems the new one must interact with, along with the interfaces to them.

A site survey is that step, done on foot. You are there to find the constraints, the fixed elements and the interfaces, and to find them before the design is priced. Every constraint found afterwards is paid for by the company that quoted.

What to look at

A survey covers seven subjects. Six are things you measure, record and photograph; the seventh, the people, is a conversation. Work through them in the same order every time so that nothing depends on memory.

• The room itself. Length, width and height, measured and not paced. Where the audience sits and where the furthest and widest seats are. Windows, and which way they face. Surfaces: glass, hard plaster and polished floors make a room that is hard to hear in.
• Structure. What is above the ceiling, what the ceiling is made of, and where anything could hang from. You record what is there. A structural engineer says what it will carry.
• Power. Where the supply is, how far it is from where the equipment will go, and who can tell you its capacity. You ask the venue's electrician or the building's engineer and write down their answer and their name.
• Cable routes. How a cable gets from the equipment to the screen, the loudspeakers, the lectern and the control position. Floor boxes, trunking, ceiling voids, fire barriers that must not be breached, and listed or protected finishes that must not be touched.
• Network and existing equipment. These are the external interfaces. What the new system must connect to, who owns it, and what they require before they will let you connect.
• Access. How equipment gets in. Door widths and heights, lift size and weight limit, stairs, distance from the vehicle, hours during which work is allowed, and where a truck can stand.
• The people. Who holds the keys, who has to approve work in the building, what induction or permit is needed, and who else will be working in the space at the same time.

Photograph everything, and photograph it so that somebody who was not there can understand it: a wide shot of each wall, the ceiling, the floor boxes open, the power panel with its door open and its labels readable, the route from the door to the room. Put a tape measure or a person in the frame for scale.

For a live event in a venue, the same seven apply with different weight. Structure becomes the rigging points and their rated loads, which come from the venue in writing. Power becomes the house supply offered to visiting productions. Access becomes the dock, the get-in route and the hours the venue allows. And the people include the venue's own technical manager, who has seen every production that came through and will tell you what went wrong for the last one if you ask.

Writing up what you found

A survey that stays in your head is worth nothing to the person who estimates the job or the crew who build it. Write it up the same day, in three short lists.

The first is constraints: conditions the design must meet, each with where it came from. "Maximum load at the ceiling grid to be confirmed by the building's structural engineer." "Work permitted 18:00 to 06:00 only, per the facilities manager." "No fixings into the east wall, which is a protected finish."

The second is interfaces: every existing thing the new system connects to, who owns it, and what they need. The client's network and its IT team. The building's fire alarm, if the sound system must mute when it sounds. The existing lighting control. The furniture supplier whose table the connections will be built into.

The third is open questions, each with a name and a date. This is the handbook's advice on unknowns applied to a building: it prefers a best estimate marked to be resolved, with what should be done to resolve it, who is responsible and by when. An open question written down with an owner is a managed risk. One left in your head becomes a surprise on site.

Then go back to the requirements you wrote and run the handbook's feasibility question over them with the survey in your hand. Are the requirements technically feasible, here? A requirement for a projected image readable in daylight, in a room with a south-facing glass wall and no blinds, has just met a constraint. That is a conversation to have with the client this week, with a photograph, and it is a much easier one now than after the order.

How to do it

1. Before you go, read the need and the requirements, and list what you must come back knowing.
2. Arrange to meet whoever looks after the building, and ask for drawings if any exist.
3. Measure the room and mark the furthest and widest seats.
4. Record structure, power, cable routes, network and existing equipment, access, and the people.
5. For structure and power, write the name of the qualified person who will confirm capacity.
6. Photograph each wall, the ceiling, power, routes and access, with something in frame for scale.
7. The same day, write up constraints, interfaces and open questions with owners and dates.
8. Check every requirement against the survey for feasibility, and raise any clash with the client at once.

What goes wrong

Practice it

You are surveying a first-floor function room in a nineteenth-century building for a permanent sound and projection system.

Designing & Bridging

A design is an answer to the requirements, inside the constraints. Anything in it that answers neither is either a mistake or a sales opportunity, and you should know which.

Design the solution and bridge tech and client.

Designing/scoping the solution

The core technical-sales task is designing or scoping the solution — determining the AV system that meets the client's need and defining it (the system, the equipment, the scope of work), drawing on systems knowledge (and Systems Design). This produces the solution being sold: what the client will get, designed to meet their need within their budget. A well-designed/scoped solution is right for the client and winnable; a poorly scoped one is wrong or uncompetitive. Designing/scoping the solution is central to technical sales. The technical sales professional designs the right solution to meet the need.

This applies technical and design expertise to the sale: scoping the right system, equipment, and work to solve the client's problem within their constraints. The solution is the heart of the technical sale (it's what's being sold). The technical sales professional scopes the solution that meets the need and wins.

Bridging technical and client

A defining skill of technical sales is bridging the technical and the client/commercial — translating between the technical solution and the client's understanding and needs. This means explaining technical solutions clearly to non-technical clients (so they understand and trust the proposal), translating client needs into technical solutions, and connecting the technical and commercial sides. The technical sales professional is the bridge — making the technical accessible and the solution compelling to the client. Bridging the two worlds is central to technical sales. The technical sales professional bridges the technical solution and the client.

This bridging (clear technical communication, translating needs to solutions and back) is what makes technical sales work — the client must understand and trust the technical solution to buy it, and the technical person must understand the client to design and sell it. The technical sales professional connects the technical and the client to win the sale.

Every line traces to a requirement

NASA's handbook asks, of a set of requirements, whether each is traceable back to a need, goal or constraint, and whether each is necessary. It suggests a blunt test for anything doubtful: "What is the worst that could happen if the requirement was not included?" Its instruction is to distinguish between needs and wants, and it is blunt about the result: if it is not necessary, it is not a requirement.

Carry that one level down and you have the discipline of pre-sales design. Every item in the design should trace to a requirement, and every requirement should be answered by something in the design. The quickest way to check both is a two-column table: requirements down the left, the part of the design that meets each on the right.

Two kinds of gap show up. A requirement with nothing beside it is a promise the design does not keep, and it is far better found at your desk than at handover. An item in the design with no requirement beside it is equipment the client did not ask for. Sometimes that is right, such as a spare that the walk through the day showed they need, and then the requirement was missing and should be added. Sometimes it is habit: the processor you always specify, the extra pair of loudspeakers that would be nice. Those make you expensive against a competitor who read the requirement more carefully.

The handbook's validation questions include whether anything is over-specified, and its checklist asks whether tolerances are tighter than they need to be, with a question worth keeping on a card: what is the worst thing that could happen if the tolerance was doubled or tripled? In a boardroom, a display twice as bright as the room needs costs money and meets no requirement.

Options the client can choose between

Most clients do not know what things cost until you tell them, so a single design with a single price is often the start of a negotiation you did not need to have. A more useful thing to bring is two or three designs that differ in which requirements they meet, each with its price.

The honest way to build them uses the work already done. The first option meets every requirement. The second leaves out or relaxes one of the key driving requirements, the lines you marked as carrying the cost, and says so in plain words. A third might add something the walk through the day suggested that the client has not asked for.

What makes this honest is that each option is described by what the client gains or gives up, in their terms. "Option B is eleven thousand dollars less. The image will be readable with the blinds closed and washed out with them open." The client can make that choice. They cannot make a choice between two model numbers.

Safety and the constraints stay outside this exercise. Crew numbers, working hours, structural margins and electrical capacity are the same in every option. The handbook's point that constraints cannot be traded applies to you as much as to the design.

Saying it in their words

Bridging the technical and the commercial is, in practice, one habit: for every technical statement, say what it means for the person in front of you.

The chapter on who is buying gave you the audience. The specifier wants the statement itself. The daily user wants to know what they will press. Finance wants to know what it does to the cost. So one design decision is explained three ways. "We have specified two wireless microphone channels on a managed frequency plan" becomes, for the user, "two people can speak at once and you will not have to retune anything", and for finance, "this is the part that avoids a technician call-out when the room next door is also in use".

A plain test helps. After each technical sentence in a proposal, ask "so what?" on the client's behalf. If the answer is not on the page, add it. If there is no answer, the sentence is there for your benefit and can go into an appendix.

Bridging runs the other way as well. When the client's finance lead says the budget has dropped by fifteen per cent, you are the one who turns that into a technical consequence the salesperson can take back: which requirement is relaxed, what the client will notice, and what stays untouched. A price cut with no stated consequence is a cut in your margin or in the crew's safety, and you are the person placed to stop it becoming either.

How to do it

1. Lay the requirements and the survey's constraints side by side before drawing anything.
2. Design the option that meets every requirement inside every constraint.
3. Build the two-column table of requirement and the part of the design that meets it.
4. Resolve every gap, whether a requirement unmet or an item with no requirement.
5. Build a second option by relaxing one cost-driving requirement, and describe the difference in the client's terms.
6. Leave crew, hours, structure and power identical across the options.
7. For each main design decision, write what it means for the user and for finance.

What goes wrong

Practice it

Your design for a training room includes a ceiling microphone array, two displays, a camera, a control panel, and a second camera at the back of the room. The requirements mention remote participants seeing the presenter and hearing the room, and local participants seeing the content from every seat.

Estimating the Work

Equipment is counted. Labour is estimated, and the estimate is where the money is made or lost.

From the design to a list

An estimate begins as a list of everything the job needs, and the commonest reason an estimate is wrong is that something was not on it. Build the list in the same four parts every time.

• Equipment. Every item in the design, with its quantity. This part is usually right, because the design drawing counts it for you.
• The small things. Cable, connectors, mounts, brackets, fixings, rack hardware, plates, labels, consumables. No drawing shows them and every job needs them. Either count them or carry an allowance worked out from past jobs, and say which you did.
• Labour. Every task a person performs, covered in the next section.
• Everything else. Transport, parking, access equipment such as a lift or scaffold tower, accommodation and travel time, permits, waste removal, and other people's fees such as a structural engineer's letter or a venue's charge for its own electrician.

Then walk the job in your head, from the warehouse to the handover, using the survey photographs. The handbook's advice about walking through how a system is used, to find what would otherwise be overlooked, works just as well on how a system is built. The van arrives. Where does it stop? Who carries what, how far, through which door? What is the first thing fixed to the building, and what is needed to reach it? Each step either matches a line on your list or adds one.

Hours, and who is working them

Labour is harder than equipment for a reason the sales textbook gives about services in general: they are variable, which is to say not standard, and so harder to assess. The same task takes a different time in every building. Pulling a cable through an open ceiling void and pulling it through a finished plaster ceiling are both one line on a drawing.

So estimate labour by task and not by a percentage of the equipment value. List the tasks in the order they happen: preparation and rack building in the workshop, loading, travel, getting in, first fix of cables and mounts, hanging and placing equipment, termination, power-up, configuration and programming, testing against the requirements, training the client, documentation, getting out, and the return visit that nearly every job needs.

For each task write three things: how many people, for how many hours, at what skill. A programmer's day and a cable puller's day are different costs, and an estimate that only counts "days" hides which one you have run out of.

Take the hours from somebody who does the work. This is the most reliable improvement available to any estimate. The person who will lead the crew looks at the survey photographs and says "that ceiling is a two-person job on a tower, so allow double". Ask before the number goes out, and record who you asked.

Then apply the safety rule from the front of this book. The number of people on a task is set by what the task safely needs: two to lift, two when anybody is working at height, a rest period before a long drive. Those numbers go into the estimate as fixed, in the same way a constraint from the survey does, and they stay there when the price is discussed.

Tasks people forget, in rough order of how often: testing, training, documentation, travel time, waiting for other trades, and the return visit. Every one of them is real work that somebody will be paid for, whether or not the estimate mentioned it.

Assumptions, exclusions and the unknown

An estimate is a number resting on a set of beliefs about the job. NASA's handbook asks, of any requirement, that its assumptions be stated and that they be confirmed before the set is fixed. Do the same with an estimate. Write the assumptions down, and put them in front of the client.

An assumption is something you have taken to be true that would change the price if it were not. "Work can be carried out during normal working hours." "The ceiling void is accessible throughout." "Existing cable containment has spare capacity." "The client's network will be ready on the first day of installation." Each is a sentence the client can read and correct, and each turns a later argument into an agreed change.

An exclusion is something a reasonable client might think is included and is not. Electrical work to provide power. Building work, making good and decoration. The furniture. Network switches. Content for the screens. Licences. Write them plainly, because the items clients most often assume are included are the ones that belong to another trade.

That leaves what you do not yet know. Use the survey's open-questions list. For each open item decide one of three treatments and say which you chose. Price it on a stated assumption. Carry a named allowance for it, a sum the client can see, which is adjusted when the answer is known. Or leave it out, as an exclusion, until it is resolved.

What you should avoid is the fourth treatment, which is adding a hidden percentage to everything to cover what you have not thought about. It makes you expensive on the simple jobs and still short on the difficult ones, and it teaches you nothing. A named allowance against a named risk can be compared with what happened, and that comparison is what the notebook from the front of this book is for.

The pre-sales person hands the estimate to whoever sets the price. Your part ends with a list of what the job needs, the hours and who works them, the assumptions, the exclusions and the allowances. What margin goes on top and what the client is finally charged is a commercial decision. What you must not allow is for the hours or the people to be changed without coming back to you, because those were set by the work.

How to do it

1. List equipment from the design, then the small things, then labour, then everything else.
2. Walk the job from warehouse to handover against the survey photographs and add what is missing.
3. List labour by task, with people, hours and skill for each.
4. Fix the crew numbers that safety requires, and mark them as fixed.
5. Have the person who would lead the crew review the hours, and record their name.
6. Write the assumptions and the exclusions in plain sentences.
7. Give every open question a treatment, whether an assumption, a named allowance or an exclusion.
8. Hand over the estimate with a note that people and hours do not change without you.

What goes wrong

Practice it

You are estimating the installation of a projector, screen and four ceiling loudspeakers in a meeting room with a finished plaster ceiling, on the third floor, with work allowed only after 18:00.

Answering a Tender

A tender is marked by people who were not in any meeting, against a list they published in advance. Most of the skill is reading that list.

How a written proposal is scored

Larger clients, and nearly all public ones, buy through a formal written competition. They issue a document describing what they want, several companies answer in writing, and a panel scores the answers. In North America the document is usually a request for proposal, or RFP.

The clearest published description of how that scoring works is the United States federal rule for it, Subpart 15.3 of the Federal Acquisition Regulation. It binds federal purchases only. A university, a city, a hotel group or a corporation writes its own rules. It is used here because it states openly what most formal tenders do in practice, and because a great many buyers have copied its pattern.

Four statements in it explain nearly everything about how to answer. First, the objective is to select the proposal that represents the best value, which is a different thing from the lowest price. Second, proposals are evaluated solely on the factors and subfactors contained in the solicitation. Third, all the factors that will affect the award, and their relative importance, must be stated clearly in the solicitation. Fourth, the evaluation is carried out by a team that includes contracting, legal, technical and other expertise.

Read the second statement twice. Solely on the stated factors. Under a rule like that, the excellent site visit, the rapport with the facilities manager and the clever idea you mentioned on the telephone score nothing unless they are written into the answer to a stated factor. And the fourth statement tells you who is reading: several people, some of them not technical, each marking the part they understand.

The rule also says what the factors generally are. Price or cost is evaluated in every selection. Quality is addressed through one or more non-cost factors, and it lists examples: past performance, compliance with the solicitation requirements, technical excellence, management capability, personnel qualifications and prior experience. Finally, the solicitation must state whether the non-cost factors, taken together, are significantly more important than price, approximately equal to it, or significantly less important. What it does not have to reveal is the rating method, so you will usually know what is scored and roughly how heavily, and not the marking scheme itself.

That last sentence tells you what kind of answer to write. Where quality outweighs price, a better design with a clear explanation can win at a higher figure. Where price outweighs everything, the tender is asking for the cheapest answer that complies, and the extra option you were proud of is a cost with no score attached.

The compliance matrix

The working tool for a tender is a table that bid teams call a compliance matrix. It has nothing clever in it. Down the left goes every instruction, every requirement and every evaluation factor in the tender document, one per row, each with the page or clause it came from. Across the top go three columns: do we comply, where in our response is it answered, and who is writing that part.

Build it on the day the tender arrives, before anybody writes a word of the response, and it does four jobs for you.

• It decides whether to bid. If the rows show a mandatory requirement you cannot meet, such as an insurance level, a certification, or a completion date, you find out on day one and not after a week of work.
• It finds the questions. Every row you cannot fill in is a question for the buyer, and tenders set a deadline for questions that is usually well before the deadline for answers.
• It shapes the response. Order your response the way the evaluation factors are ordered, and use their wording for your headings. A marker scoring "management capability" should find a heading that says so.
• It is the final check. Before the response goes, every row has a place where it is answered.

Requirements in a tender deserve the same reading you gave your own in an earlier chapter. Look for the word shall, or must, and treat each as a row. Look also for the unverifiable words, the "user-friendly" and "robust" that a client's author has left in, because you will be held to them. Where you find one, state in your answer the test you propose to meet: "We have taken 'intuitive control' to mean that a first-time user can start a meeting from the touch panel without instruction, and will demonstrate this at handover."

Where you cannot comply, say so in the matrix and in the response, and say what you offer in its place. A panel marking against compliance will find the gap whether or not you point to it. Pointing to it yourself, with an alternative and a reason, reads as competence.

Evidence, questions and the answer you cannot change

The federal rule is unusually frank about what a panel records as it marks. It documents the relative strengths, deficiencies, significant weaknesses and risks in each proposal. That is a useful way to read your own draft. A strength is something specific that exceeds what was asked. A deficiency is a requirement not met. A weakness or a risk is anything that makes the panel doubt you can do what you say, and vague writing creates those out of nothing.

On past performance the rule says the currency and relevance of the information are to be considered. Recent work like this job counts for more than old work or different work. So choose your examples for likeness to the tender, and describe them in the tender's own terms: the same kind of room, the same scale, the same kind of client.

It also provides that offerors are allowed to give information on problems encountered on those past contracts and the corrective actions they took. Clients who run tenders tend to know when a past job had trouble. An account of what went wrong and what you changed afterwards is evidence of management capability, and it is much stronger when it comes from you first.

And for a newer company it says something encouraging: an offeror without a record of relevant past performance may not be evaluated favourably or unfavourably on it. Under the federal rule, having no history is neutral. Private buyers are not bound by that, so where you have no comparable job, offer the experience of the named people who will do the work, which the rule also lists as something a panel may consider.

Three procedural points catch technical people out. After a tender is released, the rule makes one named official the focal point for inquiries, and most tenders do the same: questions go to that person, in writing, and asking your friendly contact inside the client instead can get a bid disqualified. Second, the rule allows an award to be made without any discussion with the bidders at all, so the response you submit may be the only thing the panel ever sees from you.

Third, where the panel does come back with questions, the rule limits what those exchanges are for. Clarifications are limited exchanges, used to resolve minor or clerical errors, and communications before the shortlist, which the rule calls the competitive range, shall not be used to cure proposal deficiencies or material omissions. In plain terms, you may be asked what you meant. You will not be given a chance to add what you left out.

When a tender is lost, ask for a debrief. The federal rule gives excluded bidders the right to request one, and most private buyers will give some feedback if asked politely. Ask which factors you scored lowest on. The answer is nearly always a section of the response and seldom the design.

How to do it

1. Read the whole document once, then find the evaluation factors and their relative importance.
2. Build the compliance matrix with every instruction, requirement and factor as its own row.
3. Decide whether to bid, on the mandatory rows and on how the factors are weighted.
4. Send questions to the named contact, in writing, before the question deadline.
5. Lay out the response in the order of the factors, using their wording as headings.
6. Answer every unverifiable word in their requirements with the test you propose to meet.
7. Choose past work for its likeness to this job, and include what went wrong and what you changed.
8. Check every row of the matrix has an answer, then submit before the deadline with time in hand.

What goes wrong

Practice it

A city issues a tender for AV in its council chamber. It states that technical approach, past performance and personnel together are significantly more important than price.

Proposing & Winning

Outside a formal tender nobody tells you how the proposal will be marked, so you build one that each person in the decision can find their own answer in.

Propose the solution and win the deal.

Proposals and quotes

Technical sales produces proposals and quotes — the documents that present the solution to the client: the proposal (describing the solution, how it meets their needs, and why to choose you) and the quote (the pricing). These must be clear, compelling, accurate, and competitive — presenting the right solution at the right price in a way that wins. A great proposal and quote (technically right, clearly presented, well-priced) wins deals; a poor one loses them. Producing winning proposals and quotes is central to technical sales. The technical sales professional presents the solution in a winning proposal and quote.

This combines the technical solution with persuasive, clear presentation and accurate, competitive pricing — turning the designed solution into a compelling offer. The proposal/quote is how the solution is presented and the deal is made. The technical sales professional turns the solution into a winning proposal.

Winning and supporting the sale

Technical sales supports winning the deal — presenting and defending the solution to the client (answering technical questions, addressing concerns, demonstrating value, building confidence in the solution and the company), and helping close the sale (with the salesperson/account manager). After winning, the technical sales professional often hands off to delivery (the project/integration team) with a clear understanding of what was sold. Supporting the sale to a win is the payoff of technical sales. The technical sales professional helps win the deal and hands it off well.

This means being the technical expert who gives the client confidence to buy (the solution is right, will work, and is from a capable company), helping convert the opportunity into a won, well-understood deal. Combining understanding the need, designing the solution, bridging, and proposing/winning is technical sales. The technical sales professional wins solution sales by providing the right solution and expertise. This is technical sales in action. Technical sales wins the deal with the right solution, well-proposed and supported.

What goes in, and in what order

A proposal is the written record of everything the earlier chapters produced, arranged for the people who will read it. Those people were named in the chapter on who is buying, and they read different pages. The order below puts each reader's part where they will look.

• The need, in their words. The single need statement, and two or three sentences showing you understood why. Every reader starts here, and it is the page that tells them whether to trust the rest.
• What the system will do. The short list of requirements, each a line that can be checked. This is the specifier's page and it becomes the handover test.
• How it does it. A plain description of the design, a drawing or two, and for each main decision what it means for the people using it.
• The options, if there are any. Each described by what the client gains or gives up.
• Who does the work and when. The people, the programme, the working hours, and what you need from the client and by when.
• Why this company. One or two jobs like this one, chosen for their likeness to it, and the named people who did them.
• What it costs. The price, what it includes, the named allowances, and the cost of looking after the system once it is in.
• Assumptions and exclusions. In the body, where they will be read.
• Acceptance. How both sides will agree the job is finished.
• The detail. Equipment schedules, data sheets and calculations, at the back.

The equipment list goes last deliberately. It is the part a technician most enjoys writing and the part a client can do least with. When it leads the document, it invites a line-by-line price comparison with a competitor's list and hides the understanding that would have set you apart.

This is also where the sales textbook's point about physical evidence is put to work. A service cannot be inspected in advance, so the proposal is most of what the client has to judge you by. A specific need statement, a requirement list they can check, a drawing of their own room and a photograph of a comparable job are all evidence. A generic company profile and a long equipment list are not.

Being the technical answer in the room

Once the proposal is out, the pre-sales person's job is to be the technical answer whenever one is needed: in the presentation, in the demonstration, and in the questions that come back afterwards by email.

In a presentation, divide the meeting with the salesperson beforehand, in the same way the roles were divided at the start. They open, handle the commercial questions and ask for the next step. You explain what the system will do and answer technical questions. Decide in advance who answers a question that falls between you, because two people answering at once looks like a company that has not spoken to itself.

Answer the question that was asked, at the level it was asked. A finance director who asks "will it work with our laptops?" wants yes or no and one sentence. Their IT manager asking the same thing wants connector types and supported resolutions. Both are your opposite numbers for that moment.

When you do not know, say "I do not know, and I will come back to you by Thursday", and then do it. In a technical sale that sentence builds more credibility than a confident guess, because the client's technical people can usually tell a guess, and because the guess becomes a promise the crew inherits.

And when the client asks for something that will not work, say so, kindly, with the reason and an alternative. "A projector there would be shining into the presenter's eyes. If we move it here, or use a display on that wall, you get the same image without that." The role exists so that somebody in the room is answerable for whether the thing can be built. Agreeing in order to be agreeable hands that problem to the crew.

Technical Sales Fundamentals covers the conversation itself: the phases of a sale, the kinds of question, how to handle an objection, negotiation and how to ask for the decision. This book assumes those and adds the part that belongs to the technical expert.

Keeping the record straight after it is sent

Proposals change after they go out. The client asks for a third room, drops a camera, moves the date. Each change is small, arrives by email or telephone, and is agreed by whoever answered.

NASA's handbook treats this as a matter of control. Once the requirements are agreed they are baselined, and the team must be able to show that a process for managing change to them is established, documented and communicated to the stakeholders. Scaled down to an AV sale, that is one rule: there is one current version of the proposal, it has a number and a date, and every agreed change produces a new one.

For each change, do three things before saying yes. Check it against the need: does it still serve the problem the client came with? Check it against the constraints from the survey. And work out what it does to the estimate, in equipment and in hours, so that the salesperson can attach a price to the yes.

Then reissue. The requirement list, the drawing, the estimate and the price are updated together, because a proposal in which the price was changed and the requirement list was not is the commonest source of the argument on handover day. When the order finally arrives, it should refer to one numbered version, and both sides should be able to open it.

How to do it

1. Open with the need statement and why it matters to this client.
2. Set out the requirements as a short list that can be checked.
3. Describe the design plainly, with a drawing of their room.
4. Give people, programme, price, allowances, assumptions and exclusions in the body.
5. State how the job will be accepted as finished.
6. Put equipment schedules and data sheets at the back.
7. Agree with the salesperson who answers what before any meeting.
8. Give every agreed change a new numbered and dated version of the whole proposal.

What goes wrong

Practice it

You have sent a proposal for a two-room system. The client replies by email. "Looks good. Can we add the small meeting room next door, and drop the ceiling microphones in the main room to save money?"

Handing Over to Delivery

On the day the order arrives, almost everything known about the job is in the heads of two people who are about to start on the next one.

What gets lost

By the time a sale closes, the pre-sales person knows a great deal that is written nowhere. That the facilities manager is the real decision-maker and the IT manager is nervous. That the east wall cannot be drilled. That the client was promised the boardroom would be usable every morning during the installation. That the price assumed the goods lift.

The people who build the job, the project manager and the crew, were not in any of those conversations. If the handover is a forwarded email with the proposal attached, they start with the equipment list and discover the rest one surprise at a time, in front of the client.

NASA's handbook asks for the work products of the requirements stage to be captured along with the key decisions made, the rationale and assumptions behind them, and the lessons learned. That is a description of a handover. The reasons matter as much as the decisions, because a crew that knows why a thing was specified can solve a problem on site without breaking the promise behind it.

The handover pack and the meeting

If the earlier chapters were followed, the handover pack already exists and only needs collecting. It has seven parts.

• The final numbered proposal, as ordered, and the order itself.
• The need and the requirement list, with the reason beside each line that has one.
• The people: each person in the decision, your opposite number, the daily users, and who to telephone about access.
• The survey: measurements, photographs, constraints, interfaces and their owners.
• The design: drawings, and the table showing which part of the design meets which requirement.
• The estimate: tasks, people and hours, with the assumptions, exclusions and allowances.
• The open questions, each with its owner and date, and every promise made in conversation that is not in the proposal.

The last item is the one most often missing and the one the crew most needs. Go back through the shared record of promises from the first chapter and list them. "Told the client the boardroom stays usable each morning." "Agreed to label the floor boxes to their numbering."

Then hold a meeting, in person or on a call, and walk the project manager and the crew lead through the pack. Half an hour is usually enough. Walk the job the way you walked it for the estimate: the route in, the first fix, the difficult ceiling. Invite them to challenge the hours while there is still time to tell the client about a problem.

Go to site on the first day if you can, and introduce the crew lead to your opposite number. The client has spent months learning to trust one person. That trust is passed on by an introduction far more surely than by an email.

Acceptance, against what was written

The handbook defines a verifiable requirement as one stated so that, after the product is built, it can be tested, demonstrated, inspected or analysed to show that it has been satisfied. Every requirement you wrote carries a note of which of the four applies. Acceptance is nothing more than doing that, line by line, with the client present.

So the acceptance test is written before the sale, by you, and it is the requirement list. On handover day the crew lead and the client's representative go down it together. The laptop image appears on both screens within ten seconds: demonstrated, and ticked. Speech level front to back is within six decibels: measured, and the readings recorded. A first-time user starts a presentation from the printed card: somebody from the client's own staff is asked to try.

This is where the care taken over wording pays for itself. A line that can be checked gets a tick, and a list of ticks is a finished job and a final payment. A line that said "excellent coverage" gets an opinion, and an opinion is how the job in the Introduction ended.

Anything not met is written down with what will be done and by when, and the client signs the list as it stands. A short, agreed list of outstanding items is a normal end to a job. An unwritten sense that it is "nearly there" keeps a job open for months.

One task remains for pre-sales. Get the actual hours from the project manager and compare them with your estimate, task by task, and find out which assumptions held. Write the result in the notebook. Nothing else improves an estimator as quickly, and the next client's price depends on it.

How to do it

1. Collect the seven parts of the pack, starting from the final numbered proposal.
2. List every promise made in conversation that is not in the proposal.
3. Walk the project manager and crew lead through the pack and the job, and invite challenge.
4. Tell the client at once about anything the crew lead finds that changes the plan.
5. Introduce the crew lead to your opposite number, on site if possible.
6. Give the crew the requirement list as the acceptance test, with how each line is checked.
7. After handover, compare actual hours with the estimate and record what you learned.

What goes wrong

Practice it

You have won the school hall job from the earlier chapter. The installation is in three weeks.

Technical Sales Mastered

The work in this book is a set of documents, each built from the one before. Done in order, they are the job.

Solution selling that bridges tech and business.

The technical sales professional

Pulling it together, technical sales and pre-sales is selling technical AV solutions — understanding the need technically and commercially, designing/scoping the solution, bridging the technical and the client, and proposing and supporting the deal to a win. The technical sales professional combines technical/solution expertise, commercial understanding, clear communication and bridging, and selling skill. This makes them essential to selling AV systems — the technical expertise that turns client needs into won solution sales, a valuable, well-rewarded role. Technical sales mastered is winning solution sales by providing the right solution and expertise. The technical sales professional sells the right solution to the client's need.

Technical sales is essential and valued in AV (selling systems requires technical solution expertise), and skilled technical-sales/pre-sales professionals are well-compensated. It's a role for those who combine technical knowledge with client and selling skills (a valuable, somewhat rare blend). Understanding technical sales — the need, the solution, the bridge, the win — is a valuable business-technical capability. The technical sales professional bridges technology and the client to win deals.

Developing in technical sales

Developing in technical sales means building technical/solution expertise (AV systems and design — the technical foundation), commercial and selling skills, communication and bridging ability (explaining technical things clearly, understanding clients), and proposal/quoting skill, gaining experience in technical-sales/pre-sales work. It connects to Technical Sales Fundamentals, to system design, and to the business and client books. The best technical-sales professionals combine deep technical/solution knowledge, strong commercial and selling skills, and excellent client communication, built over time. Deliberately developing these is the path forward.

From here, growing means selling bigger and more complex solutions, building towards senior technical-sales, pre-sales, and solution-architect roles, and mastering solution selling. It's a valued, well-rewarded career bridging AV technology and business. The skills this book brings together — needs, solution, bridge, proposal, win — are the foundation; mastery comes from winning many solution sales over time. Keep building your technical and selling skills, keep winning the right solutions for clients, and you grow into a technical-sales professional. (Remember: this is professional guidance, not legal/tax/financial advice.)

Glossary

Practical sign-off

Technical sales is learned doing it. The learner understands needs technically and commercially, designs/scopes a solution, bridges tech and client, and proposes to win. A mentor signs off when the learner can support and win technical solution sales.

• Understood a client's needs technically and commercially
• Designed/scoped the right solution for the need
• Bridged the technical and the client clearly
• Produced a winning proposal and supported the sale

The whole job on one page

Every chapter of this book produced something written. Laid end to end they are the pre-sales file for a single opportunity, and each one is the input to the next.

On a small job the whole file may be three pages, and that is fine. What should not happen on any job is a step with nothing written, because that step will then be done from memory by somebody who was not there.

Growing into the role

Almost nobody starts in pre-sales. People arrive from the crew: a technician who is good at explaining things gets taken to a site visit, then asked to check a design, then asked to write one. That route is the right one, because every chapter in this book rests on knowing what happens when the equipment arrives in a real building.

If you are a technician now, three habits start the move without anybody's permission. Read the proposal for the job you are on, and note where what was sold differs from what you found. Offer to go on a survey, and write it up in the three lists. And when an estimate turns out wrong, tell the person who made it what the hours really were, politely and with numbers. Estimators remember the technicians who do that.

From pre-sales the paths widen. Some people move towards design and become the engineer who draws the system in full. Some move towards the commercial side and hold accounts of their own. Some become the consultant a client hires to write the requirement before any integrator is asked to bid. All three are built on the same skill, which is being trusted by both the client and the crew to say what will work.

How to do it

1. Agree the pairing and meet your opposite number.
2. Put a name beside every role in the decision.
3. Write the need statement and have the client agree it.
4. Write the requirements so each can be checked.
5. Survey the site and write up constraints, interfaces and open questions.
6. Design to the requirements and trace every item.
7. Estimate by task, with assumptions, exclusions and allowances.
8. Issue one numbered proposal and reissue it after every change.
9. Hand over the pack and the spoken promises to delivery.
10. Compare actual hours with the estimate and record what you learned.

What goes wrong

Practice it

Choose a job you worked on as a technician and can remember well.

Where to Go Next

This book covered the technical work before a sale closes. Technical Sales Fundamentals covers the conversation that runs alongside it: the seven phases, the types of question, objections, negotiation and closing. Account Management covers what happens once a client is worth keeping. Client & Stakeholder Communication covers the conversations themselves, and Freelance Business Fundamentals covers rates, terms and getting paid.

Three sources stand behind the method here and each repays reading. NASA's Systems Engineering Handbook is free to read on nasa.gov; sections 4.1 and 4.2 and Appendix C are short, and the appendix's checklists can be used as they stand. Chapter 4 of Jobber and Lancaster's Selling and Sales Management sets out how selling to organisations and selling services differ from selling goods to households. And Subpart 15.3 of the Federal Acquisition Regulation, on acquisition.gov, is the plainest account available of how a written proposal is scored.

The first ninety days

Four things, none of which takes a day. For the next opportunity you touch, write the need in one sentence and read it to the client. Take one proposal your company has already sent and underline every word from the unverifiable list. On your next site visit, write up the three lists the same day. And for one finished job, get the actual hours and set them beside the estimate, task by task.

Then start the notebook, one page per opportunity, with the last line filled in after the job: which assumptions turned out wrong.

Where this leads

A technician who can write down what a client needs, in words the client agrees with and the crew can build from, is doing the work that decides what gets built. That is the route into system design, into consulting, and into running the technical side of a company, and it starts with the next survey you are asked to help on.

What the gear actually looks like

Every device named in this book, in one place. Recognition is the whole point of Chapter 4 — use this page to attach a picture to each name before you meet it on a dock at six in the morning.

Audio

Dynamic microphone

Condenser microphone

Wireless handheld

Radio rack

Mixing console

Stage box / snake

Power amplifier

Main loudspeaker

Subwoofer

Stage monitor wedge

In-ear monitors

DI box

Video

Camera

Video switcher

Scaler / processor

Projector

LED wall panel

Confidence monitor

Lighting & control

Conventional fixture

Moving-head fixture

Lighting console

Dimmer

Show controller

Media server

Networking & infrastructure

Network switch

Patch bay

Equipment rack

Power distribution

Cable tester

A properly coiled cable

Connectors, close up

XLR

TRS / TS ¼-inch

SDI on BNC

HDMI

Cat5e / Cat6 (RJ45)

Fiber optic

DMX (5-pin XLR)

AC power — not signal