A product list tells someone what is being requested. A short project brief explains why. Start with the intended use, the stage of the opportunity, and the date the next decision is needed. Keep the description factual and concise. This helps the next person see which questions need an answer before the request can move forward.
Separate confirmed details from open questions
Use three labels: confirmed, proposed, and needs review. A model number supplied by the customer can be confirmed as their request without being treated as a validated design choice. An alternative should stay proposed until the appropriate person has reviewed it. This small distinction keeps assumptions from becoming accidental commitments.
Record quantities and dependencies
For each requested item, capture the quantity, the reason it is included, and any dependency that needs checking. Avoid substituting a superficially similar item without review. Compatibility, installation conditions, required accessories, and support arrangements should be confirmed by the responsible technical or commercial owner.
Treat availability as a point-in-time statement
Note when availability or lead-time information was checked and who provided it. Distinguish an estimate from a reservation or a committed delivery date. If the schedule depends on a specific item, identify the decision that must happen when availability changes. A handoff should not promise something that has not been confirmed.
Name the next owner
A complete handoff states who is acting next, what they need to do, and when the request should be revisited. Include the customer-facing communication owner so the customer does not receive conflicting updates. Share only the information needed for the task and follow the organization’s rules for customer and project data.
A compact handoff format
Use this structure: project outcome; request and quantities; confirmed requirements; proposed options; technical questions; availability checked on; commercial questions; next action; action owner; agreed date. The value comes from accurate entries, not from making the form long.
TECHNOLOGY SALES NOTES
A discovery checklist for technology buyers
Start with the decision the customer needs to make.
A useful discovery conversation begins with what needs to work differently. Ask the customer to describe the task, the people doing it, and the problem that interrupts it. “We need better meeting-room technology” is a starting point. “Remote participants cannot follow questions from the back of the room” gives the conversation a specific problem to examine. This is an illustrative example, not a customer case study.
Describe the existing environment
Record what the customer already has, what must remain, and what is still unknown. Separate an observed limitation from an assumption. If a technical detail requires a specialist, write down the question and assign an owner. Discovery should make uncertainty visible instead of turning a guess into a requirement.
Find the decision process
Ask who will use the solution, who will evaluate it, who approves the spend, and who will support it after purchase. These may be different people. Capture the decision date separately from the desired installation date. A quote can arrive on time and still miss the project if approval, purchasing, and scheduling were never discussed.
Make constraints explicit
Invite the customer to identify budget limits, procurement requirements, site access, and any existing commitments. Treat a budget range as information for planning, not permission to spend the entire amount. If the range is unknown, explain which options depend on it and agree on how to resolve that question.
Agree on a useful next step
End with a short recap: the desired outcome, the main constraint, the open question, and the next action. Name the person responsible and the agreed date. Send the recap in language the customer can correct. The goal is a shared understanding that survives the conversation.
Questions to take into the next call
What must improve? Who experiences the problem? What must stay in place? How will you judge success? Who else needs to be involved? Which dates are fixed? What is the next decision, and what information will help you make it? Use these questions as a guide, not a script to read at someone.
Customer discovery worksheet
Copy this blank worksheet into your own notes before a discovery call.
Project / conversation date:
Customer outcome:
People affected:
Current environment:
Confirmed constraints:
Open technical questions and reviewer:
Decision makers / purchasing process:
Budget information confirmed by customer:
Decision date / installation date:
Next action:
Action owner:
Agreed date:
Customer corrections to recap:
