The hygiene that nobody teaches
The previous chapter was about the demo. This one is about the rest of the call — the small mechanics that don't show up in any training material but separate the SAs who run clean meetings from the ones who don't. None of these are clever. Most of them are obvious, in the sense that you'll nod when you read them. The reason they're worth a chapter is that almost no one does all of them, and the cumulative effect of doing them is significant.
The frame for this chapter: the user is forming an impression of your company in real time, and a lot of that impression is built from cues that have nothing to do with the content of what you're saying. How prepared you seem. How calm you are. Whether your screen is a mess. Whether you remember their names. Whether you take notes. The signal-to-noise ratio of the meeting. These are all small things that compound.
Write their name down
Before any call, write the user's name and their company's name somewhere you can see while you're talking. The deck, a sticky note, the corner of a notepad. Anywhere your eye will catch it.
The reason is simple: when you're managing several deals at once, the names blur. Calling Home Depot "Lowe's" on a live call is a mistake you only need to make once to develop the lifelong habit of writing the user's name down before the meeting starts. Whoever did this first, somewhere in the history of pre-sales, did the rest of us a favor by making it a cautionary tale. Even if you're confident you have it right, write it down. The cost of writing it down when you didn't need to is zero. The cost of getting it wrong is meaningful — not catastrophic, but meaningful. Calls have started with a wrong name and never quite recovered.
This applies to people's names too. If there's anyone in the meeting whose name you might mix up, write the names of everyone in the room down at the start. Glance at the list when you address someone directly. The user notices when you remember their name; they also notice when you don't.
Take notes — for future you
Notes are the most valuable artifact you produce in this job, and they're produced for an audience of one: yourself, two weeks from now, prepping for the next call.
The notes don't have to be polished. They have to be sufficient. Specifically, they have to be enough that fifteen minutes before the next call, you can read them and reload the entire context — what was discussed, what was decided, what's open, what you committed to follow up on, what the user is worried about, what surprised you. If your notes don't do that, the notes aren't good enough.
A few things that help.
Take notes during the call, not after. Trying to reconstruct the meeting from memory afterward loses too much. Your hand should be moving — pen, keyboard, whatever — while the user is talking. The act of writing is also a form of active listening; you'll process more deeply than if you're just nodding.
Capture the unique things, not the obvious things. You don't need to write down "we discussed payments." You do need to write down the specific failure mode the user mentioned, the off-hand comment about an internal politics issue, the architectural choice they explained, the thing they said that surprised you. "Patterns will emerge; take special note of things that stand out and make this user different." The specific things are what you'll need when you're trying to remember, weeks later, why this user was different from every other user.
Capture exceptions. When a user does something unusual — a non-standard architecture, an unusual constraint, a specific concern — that's the thing to write down. The standard parts of the deal you can reconstruct from your generic mental model. The non-standard parts are what you'll lose if you don't capture them.
Write down what you committed to. Every meeting produces a list of follow-ups. Most of them are small. All of them get forgotten if you don't write them down. The user remembers what you said you'd do. If you don't deliver, even on the small things, the relationship erodes a little. Write the commitments down explicitly and act on them within a day or two.
The meeting room is also your screen
If you're sharing your screen — and in most calls you are — your screen is part of the meeting. Treat it that way.
Hide your bookmarks and tabs. A fresh bookmark to a competitor's integration page in plain view, in a meeting where you're trying to win the deal, is bad. An open tab from a different user's deal is worse. An open tab labeled "AcmeCorp Pricing — DO NOT SHARE" is the kind of thing that gets discussed at offsites. The user notices these things. They draw conclusions, sometimes correctly. The fix is to use a clean browser profile or window for user-facing meetings, with no bookmarks, no tab history, nothing that hints at other deals or competitive dynamics.
Share specific windows, not your full desktop. This is a small change in habit that prevents a long list of bad surprises. The Slack notification that pops up with a sensitive snippet. The email preview that appears in the corner. The desktop wallpaper that includes a personal photo. Sharing only the specific window you want the user to see eliminates the entire category.
Mind the account selection dropdown. If your platform has a dashboard with account or environment selection, the dropdown often contains a list of every account you've ever used — including, potentially, the names of other users you've worked with. When you click into the dropdown in front of a user, that list becomes visible. The fix is to use a dedicated demo account, ideally one created specifically for demos, or to use plus-addressing in your email so demo accounts don't appear in your "real" account list.
Keep user-named files off your desktop. If you have a file named "AcmeCorp - Architecture Review.docx" sitting on your desktop, and you share your desktop in a meeting with a different user, you've leaked confidential information. File user-specific work into folders that aren't visible during screen-share. Who you work with is confidential unless you have explicit logo rights. Treat it that way.
These are all small, and individually each one feels like overkill. Cumulatively, they're the difference between an SA whose calls feel polished and one whose calls feel messy. The user can't always articulate why one vendor felt more professional than another. The hygiene is part of why.
Pen and notes as pacing tools
I mentioned this in the demo chapter and it's worth re-emphasizing here. Picking up a real pen and starting to take notes is one of the most useful tactical moves in your kit. It serves three purposes at once.
It paces the meeting. The room follows your tempo. When you slow down to write, everyone else slows down too. If the meeting has been moving too fast, this is the cleanest way to reset.
It signals listening. The user is being heard, in a visible way. They feel attended to.
It captures information. You're actually getting the notes you'll need later.
The pen doesn't have to be analog. A keyboard works. The visible act of taking notes, with deliberate pauses, has the same effect. The point is that note-taking isn't just a record-keeping exercise — it's an active part of how you run the meeting.
Practice your introduction (again)
Yes, again. The first thirty seconds matter more than they should, and almost no SA actually practices the open. If you fumble it in even one in five meetings, that's the area where focused practice will give you the biggest return. Go practice it out loud, alone, ten times. Adjust until it feels right.
Discovery cycles can be long, and that's okay
A pattern that worries new SAs more than it should: long discovery cycles. The user keeps asking questions. The deal isn't moving as fast as the AE wants. You find yourself demoing or explaining something you've covered before.
Sometimes you are stuck. Often you're not. If the user is asking thoughtful questions in a fifth meeting, that's a sign the deal is alive, not dead.
It's okay to repeat things. "Sometimes it takes a while for the user to learn everything they need to. You might find you are demoing and repeating the same things. It's probably okay." That sentence from the original deck has stayed useful for me across hundreds of deals. Repetition isn't failure — it's how learning happens.
The exception is when repetition starts to feel like avoidance. The move is to surface it directly: "I notice we've covered this a couple of times — is there something specific that's still unclear, or something blocking you?" Sometimes the answer is illuminating. Sometimes the user just needed to hear it once more.
Encourage the user to write code
This is one of the highest-leverage pieces of advice in pre-sales for a technical product, and it's almost never deployed deliberately. Encourage your user — actively encourage them — to write some code, run a test integration, get hands-on with the product before they sign.
The reason is empirical. Users who write code before signing go live much faster than users who don't. The mental model they build by actually trying the integration is qualitatively different from the model they build from demos and docs. They surface their own questions. They hit edge cases on their own time. The signing decision becomes more informed and the implementation lands cleaner.
For some platforms, encouraging this is straightforward — there's a sandbox, a free tier, or a low-friction way to try things. Use it. Make sure your user knows it exists. Offer to walk through a quick integration with them. The fifteen minutes you spend helping them set up their first test request is worth a hundred hours of demo time.
For platforms where pre-signing access is harder, you might need to find a workaround — a guided proof-of-concept, a sandboxed environment, a partner who can give them hands-on time. The principle holds even when the implementation is harder. The deals where the user has actually used the product before signing are different deals than the ones where they haven't.
Rate your calls
After every meaningful call, rate it. One to ten. Write down what you'd do differently. Ask the AE or your manager for feedback occasionally.
This is the single highest-leverage habit I've ever picked up in this role, and I learned it years into the job, which means I went years without it. Don't make my mistake. Start the habit early.
The rating itself isn't important. What matters is the act of reflecting honestly. "That was a six. The open was rough, I rushed through the discovery section, but I recovered well in the back half and got the meeting back on track." That kind of self-assessment is how you get better. It surfaces patterns. It identifies the calls that went well so you can figure out what worked. It identifies the calls that went badly so you can figure out what didn't.
Pair the self-rating with peer feedback when you can. "Honest reflection is a great tool, and peer feedback is priceless." The willingness to ask "how did that land?" and actually hear the answer is what separates SAs who improve quickly from those who plateau.
A note for builders
The leverage point for call quality, at the function level, is creating a culture where reflection and feedback are normal.
Most teams talk about this and don't operationalize it. The SAs run their calls, the deals close or don't, and the only feedback anyone gets is the deal outcome — which is a noisy and lagging signal. The function with a real feedback loop, where SAs are reviewing each other's calls or getting structured feedback from their managers, improves visibly faster than the function that doesn't.
This doesn't have to be elaborate. A monthly call review, where each SA brings one recording of a call they want feedback on, is enough to start. The barrier is psychological, not logistical — people don't want to be critiqued. The way to lower the barrier is to model it from the top. Senior SAs and managers should be the first ones to share their own calls and ask for feedback. Once it's normalized at the top, it becomes safe across the team.