Articles For sales and Sales Engineering leaders

Pre-call planning for a first enterprise software meeting

A shared pre-call plan sets out what the account executive and Sales Engineer know, what they assume and who will ask each question. Work backwards from what the customer meeting needs to establish.

Jacob Top Møller5 min read

Illustration: two paper figures fit three puzzle pieces together to form a shared plan.

A pre-call plan sets out what the account executive and Sales Engineer need to establish in their first customer meeting. Use three rows: technical, business value and qualification. For each row, name a lead and write down what you know, where it comes from and what you still assume. Write a question to test each assumption and name the person who will ask it. Agree what the meeting needs to establish before deciding what to show.

What the first meeting should establish

A first meeting should leave you with the problem in the customer's words, a possible champion to investigate and an agreed next step.

Put those outcomes at the top of the plan. A demo booking alone does not tell you which business problem matters or who would help pursue a change.

A pre-call planning template in three rows

Give each row a lead, including the rows both sellers share.

The Sales Engineer leads the technical row and shares the other two with the account executive. Agree who will lead each shared row for this meeting.

The rows follow the three puzzles in every deal. The technical row asks whether the product fits this customer's needs and environment, and where it differs from the alternatives. The business value row covers what the change is worth to their business and which outcomes the economic buyer would commit to. Qualification is about who decides, how and by when, and who inside the customer carries the deal.

In the business value row, the Sales Engineer asks what the technical problem costs the customer today, or what it holds up. Without that question, the meeting can collect requirements and leave the business consequence vague.

To prepare that question, the Sales Engineer needs what the account executive already knows. GitLab's handbook says its Solutions Architect should either join the discovery call or be given the "Outcome / Infrastructure / Challenges information uncovered by prior interactions with the account".

Mark what you know and what you assume

Keep evidence and assumptions separate in every row. Give each assumption a question that could confirm or change it, and name who will ask.

GitLab's handbook suggests researching "Annual reports and/or financial statements" before discovery. A customer's annual report can help identify the goals behind a purchase.

Illustration: a paper figure tests the next step while a colleague holds a solid stepping stone.

What to prepare to show, and when

Prepare one short example, then decide whether it is relevant after hearing the customer's problem.

In my Sales Engineering foundations course, participants practise preparing a customer meeting with the account executive. They learn to ask about the customer's business before showing the product, then explain and demonstrate the parts of the product that answer what they heard. GitLab's discovery guidance names the opposite habit as a pitfall: "Resist the urge to prematurely talk about or begin to position GitLab until you have a thorough understanding of the customer's challenges".

Illustration: two paper figures listen to a third while a box stays closed beside them.

Put the condition in the plan: which customer problem would make the example useful? If the conversation takes a different direction, keep asking questions. Agree a separate session if a relevant demonstration needs more preparation. GitLab's handbook says its Solutions Architects may sometimes combine discovery and a technical demonstration. It calls that "suboptimal" because it "does not allow the SA time to prepare for and/or tailor the discussion".

Pre-call plan example for an invented insurer

An insurer has asked for a first meeting about software that reads and routes incoming documents.

The head of claims operations will attend with an enterprise architect. The sellers want to hear the problem in her words and investigate who could carry a change internally. If the problem is worth pursuing, they will propose a working session with two of her claims team leads, prepared by the Sales Engineer.

What to show: one routing example, only if the customer describes a problem it would help address.

An invented insurer and participants: the plan for a first meeting
Puzzle and leadWhat we know, and from whereWhat we assumeQuestions to test the assumptions, and who asks
Technical, led by the Sales EngineerWhat we know, and from where The meeting request names their email platform and a claims system built in houseWhat we assume Claim documents arrive as email attachments and scans and are keyed in by handQuestions to test the assumptions, and who asks Sales Engineer: "Walk us through what happens to a claim document from the moment it arrives until someone can act on it."
Business value, led by the account executive with the Sales EngineerWhat we know, and from where The annual report sets a target to lower the cost of handling claimsWhat we assume Manual keying is part of that cost, and the head of claims carries the targetQuestions to test the assumptions, and who asks Account executive: "Where does the cost target land in your team, and what happens if it is missed?" Sales Engineer: "How much time goes into keying today, and how do you measure it?"
Qualification, led by the account executive with the Sales EngineerWhat we know, and from where She asked for the meeting and invited the architectWhat we assume She would carry a change like this internally, and the decision sits above herQuestions to test the assumptions, and who asks Account executive: "If this is worth pursuing, who would take it forward internally? Who else would need to agree, and how did the last such decision go?"

Review the plan before and after the meeting

A manager reviews a pre-call plan by its assumptions before the meeting and by the answers after it.

Before the meeting, check that each row has a lead and that each assumption has a question and someone responsible for asking it. Check the condition for showing an example too. Tom Mills's pre-meeting template for Sales Engineers and account managers includes "Internal Alignment Call Completed (SE & AM)" in its checklist. The manager can use that alignment call to review the plan with both sellers.

After the meeting, write what the customer said beside each assumption: confirmed, changed or still open. The plan for the next meeting starts from what is still open, and both sellers leave with their next steps.

In my team training on your own deals, each participant brings a current deal and works it through the three puzzles with the account executive. They leave with the next customer meeting prepared.

Sources

  1. Effective Discovery. GitLab, 24 September 2026.
  2. Solutions Architect Sales Plays. GitLab, 27 August 2026.
  3. PLAYBOOK: Pre-Meeting Template. The PreSales Professional, 25 January 2025.

Facts last checked on 27 October 2026.

Updated 27 October 2026.

If you think I could help, write to me or give me a call.