Workflows by role and team

Meeting notes for sales engineers and technical discovery

Notes for sales engineers: capture requirements and objections in the customer's own words, separate what they need from what they asked for, and follow up.

By the Notey team at AInject · · 5 min read

In short

A sales engineer's discovery call produces the document everything else depends on: what the customer actually needs, in enough detail to design a solution, scope a proof of concept and answer the security questionnaire. The failure is familiar.

The account executive's notes say "needs SSO and an API"; the proposal promises both; three weeks later it turns out the customer meant a particular identity provider, a particular audit requirement and a write API nobody discussed.

Good technical discovery notes capture requirements and objections in the customer's own words, keep what they need separate from what you might build, and end with the questions still open. This guide gives a template and the habits that make it work.

What to capture

Their current setup

Before requirements, write down what exists today: the systems involved, how data moves between them, who operates them, and what they are replacing. Requirements only make sense against this, and it is the part most often skipped because it feels like small talk.

Requirements, in their words

For each requirement, write what the customer said as close to verbatim as you can, then, separately, what you think it means. Keeping the two apart matters. When the proposal is challenged, "you said X" carries weight; "we understood Y" does not.

Mark each requirement as:

  • Must: a deal-breaker, stated as one.
  • Should: wanted, with room to negotiate.
  • Asked about: raised, but no sign it matters.

Constraints

Security, compliance, hosting, integration, scale, budget cycle. Constraints are usually stated by someone other than the champion and usually late. Ask for them directly.

Objections

Write down every objection, even the ones you answered on the call. An objection you handled well today is the one the customer's security team raises again next month, and you will want to know exactly what was said the first time.

People

Who was on the call, who they mentioned, and who decides. Note anyone whose approval was mentioned in passing: "IT will want to look at this" is a name you do not have yet.

A template

# Technical discovery — <customer> — <date>

**On the call:** names and roles
**Also involved:** people mentioned who were not there

## Current setup

- Systems, data flow, who runs it

## Requirements

| # | In their words | What we think it means | Must / Should / Asked |
| - | -------------- | ---------------------- | --------------------- |
| 1 | "…" (12:40)    | …                      | Must                  |

## Constraints

- Security / compliance:
- Integration:
- Scale:

## Objections

- "…" — how we answered — resolved / open

## Open questions

- Question — who can answer — by when

## Next step

- One thing, owner, date

The timestamp beside each quote lets you or a colleague go back to the moment it was said. Sales call notes covers the commercial side of the same call — the prospect's problem, the next step and who else decides — and the two fit together.

A fictional example

Priya Shah, a solutions engineer, runs discovery with Northwind for Harbour. One row of her requirements table:

  • In their words: "Every change to a customer record has to show who did it, and our auditors want to export that themselves." (18:02)
  • What we think it means: A per-record audit log, with export available to a role that is not an administrator.
  • Must.

Her first draft had said "audit log". The quote shows the requirement is really about who can export it, which changes the proof of concept.

After the call

  1. Write the questions you still need answered. Group them by what is at risk: the deal, the scope, the timeline, the security review. The questions to ask after a meeting has a way to sort them.
  2. Send the customer your understanding of the requirements and ask them to correct it. Short, numbered, in plain language.
  3. Hand over to the account executive and the delivery team with the template, not a verbal summary.
  4. Log the objections where the next person to talk to the customer will see them.

Recording discovery calls

A recording makes verbatim notes possible, but it has to be agreed. Say it at the start: "I'd like to record this so I get your requirements exactly right. Is that all right?" Some customers' policies do not allow recording, especially in security reviews; take notes by hand and send them for correction instead. How to ask for consent to record has more wording.

Wear headphones. On speakers, the customer's voice reaches your microphone and ends up on your side of the transcript.

How Notey fits into this

Notey records your microphone and what your Mac plays as two separate tracks and transcribes both on the Mac. On a customer call your questions are labelled You and the customer's answers Them, because they arrive on different tracks. If several people speak on the customer's side, their voices are told apart after the recording and you name them.

The parts that help with discovery:

  • Timestamps that play. Click the line where the requirement was stated and hear it again before you quote it.
  • Search across every call with the customer by what was said.
  • Notes when you ask. With an account, ask for a summary, minutes, "Tough questions" (the questions worth going back with, grouped by what is at risk), or "Where you differed" (each point the two sides did not agree on). Only transcript text is sent, never audio. Everything the AI wrote is labelled; check it against the transcript before it goes into a proposal.
  • Ask Notey a question about the meeting, such as "what did they say about the auditors?"; the answer is drawn from that meeting's transcript and says so when the transcript does not cover it.

Notey has no CRM integration. Export the note as Markdown and paste it into your CRM or the deal's shared document.

Many sales engineers also brief product teams on what they heard; meeting notes for product managers covers the receiving end. For the wider client-facing workflow, see AI meeting notes for consultants.

Frequently asked questions

What should technical discovery notes include?

The customer's current setup, the requirements in their own words, the constraints (security, integration, scale), objections, who else decides, and the questions you still need answered. Keep requirements and your proposed solution in separate sections.

Why do requirements need to be in the customer's words?

Because paraphrase drifts. "Must support single sign-on" and "we use Okta for everything and IT won't approve anything that doesn't" are different requirements, and the second tells you who can block the deal.

Should I send my discovery notes to the customer?

Send a short written summary of the requirements as you understood them and ask them to correct it. It catches misunderstandings before they reach a proposal, and it gives the customer's technical lead something to forward.

Can I record a customer's technical call?

Ask first, at the start of the call, and respect the answer. Some customers' policies rule it out, especially on security reviews. If they say no, take notes by hand and send your summary for them to correct.