SE Rockstars — Presales Unleashed

< Back to Overview

>Blog

Should Solution Engineers Talk About Price?

Quoting a number to the customer is the AE's job. Knowing what the deal is worth is yours — and most SE organizations have the two backwards.

Tim BrömmeJan-Erik Jank9 min read

Two different questions get mixed up whenever pricing comes near a solution engineer: may you say the number, and do you know the number. The answers point in opposite directions.

TL;DR

  • Customer-facing pricing belongs to the AE. Not because SEs can't be trusted, but because a number said out loud becomes an anchor nobody can retract.
  • A "no" to quoting is not a "no" to knowing. An SE who can't tell you whether a deal is €20k or €2M can't build a value story, can't prioritize, and can't be moved by variable pay.
  • "400 licenses" is not a deal size. Translate seats, credits and transactions into money before your next call.
  • Guardrails beat gag orders: one owner, one sanctioned sentence, one place where today's price actually lives.
  • For installed-base work the question changes from "how big is this deal" to "how far can we move adoption" — 5% to 30% to 50%.

A friend of ours — an SE, sharp, well prepared — was walking us through a deal he'd been working for weeks. First question back: how big is it? Answer: 400 licenses.

Which tells you nothing. Is that a career deal or a rounding error? Is it €40k or €900k? He knew the seat count because the seat count was in the requirements document. The money was somebody else's business.

Around the same time, a thread went around LinkedIn about an SE who had given a customer prices with no AE in the room. The numbers were incomplete and partly wrong. Someone had to walk them back, which meant an awkward call with the customer and a more awkward one internally.

Two stories, one root cause: nobody had decided what SEs are allowed to say about price, and nobody had decided what they need to know about it. Those are separate decisions. Here's how we'd make both.

Should solution engineers quote prices to the customer?

As a default, no — with a few narrow exceptions. Not because SEs are careless with numbers, but because of what a spoken price does once it exists.

First, exposure. The moment you communicate a price on behalf of your company, it's on the record. Someone will cite it back to you in procurement three months later. If it wasn't aligned, or the list changed last quarter, you've spent credibility you didn't have to spend.

Second, anchoring. If you say €50 per license and the real number is €100, the €50 is now sitting in the buyer's head as the reference point. "Sorry, my colleague misspoke" doesn't remove it — the anchoring effect is one of the most stubborn findings in judgment research, and it does not care about your internal explanation. You've turned your own quote into a concession the customer now expects.

Third, role design. Good cop / bad cop is a real dynamic and some teams play it deliberately: the AE carries the uncomfortable topics, the SE stays the technically credible voice in the room. You can argue about whether that's healthy. But if you've built your motion that way, having the SE announce pricing burns the card.

And then there's the boring reason: price lists move. One of us started out with a monstrous Excel price list — dozens of line items, something new in it every time you opened the file. At SAP, the SKU count means you could scroll for weeks and still not reach the bottom. Whatever price you memorized last quarter is probably stale. If you want SEs quoting, you also have to keep every SE current. Most organizations don't, and won't.

What should an SE say when the customer asks for a price?

One sentence, agreed in advance, said the same way every time. Something like: "Let me flag that to my AE — she'll come back to you with a binding quote." Then do it inside the hour.

The trap isn't the blunt "what does it cost?" question. It's the friendly follow-up in a technical workshop: "and if we added 50 more licenses on top, what would that run us?" It feels like a configuration question. It's a quote.

So the guardrails an SE team needs are short:

  • Who owns pricing communication to the customer, with no ambiguity.
  • The sanctioned sentence — written down, rehearsed once in a role play so it doesn't come out defensive.
  • Where today's price lives. Note that the pricing page on your own website is usually not the price this customer will pay.
  • The explicit exceptions, if any: published list price, public tiers, a rate card the customer already has.
  • What happens after: the SE tells the AE what was asked, in what words, so nobody is surprised later.

That's a one-pager. Teams that don't have it end up with the LinkedIn story instead.

Why does an SE need to know the deal size at all?

Because three things you're already expected to do are impossible without it.

Value selling. Everyone wants value-based demos. Value is a ratio, and you only have one side of it if you don't know the price. If you're not convinced you're solving a €200,000 problem, you have no business arguing for a €20,000 solution — and you certainly can't shape a talk track that makes the price look small next to the pain.

If you can't say whether this deal is five, six or seven figures, your "business value" story is a guess with slides.

Prioritization. An SE rarely has one deal in front of them. It's 15, maybe 20. If one is worth €2M and another €20k, the €2M deal should get something like 90% of your attention and the small one a fraction of that. You cannot steer your own week on gut feel and ticket order. Deal value is the steering input.

Incentives. Most SEs we work with have a variable component tied at least partly to revenue. The whole point of variable pay is to pull the individual toward the deals that matter — extra mile on the big ones, discipline on the small ones. Withhold deal size and the incentive can't function. You're paying for a signal you refuse to send.

None of this requires the full price matrix. Order of magnitude is enough: five figures, six, seven. Get in the habit of converting seat counts into money in your head before the call, not after.

Diagram contrasting what an SE must know internally about price with what reaches the customer through the AE

Price literacy runs inward; price communication runs through the AE.

What about the pricing metric, not just the number?

The metric matters as much as the amount, because it decides what you have to discover. Seats, named users, hosted instances, credits, tokens, transactions — each one sends you looking for different evidence in the customer's business.

Seat-based, and you're chasing team sizes, roles and rollout waves. Consumption-based, and you need volumes: how many transactions per month, growing how fast, and what you earn per transaction. AI products have pushed a lot of teams into credit and token models almost overnight, and the shift toward usage-based billing has been tracked for years now (see, for example, Metronome's State of Usage-Based Pricing). An SE who still thinks in licenses inside a consumption model will build the wrong business case with great enthusiasm.

Ask your AE two questions on every new deal: which SKUs are we actually selling, and what's the metric underneath them.

How does this change for solutions teams and installed base?

It changes the question. "PreSales" is quietly giving way to "solutions" in a lot of org charts, and the reason isn't fashion — those teams also work existing customers, driving adoption, supporting land-and-expand. Contract signature is the kickoff, not the finish line.

In an adoption-driven or transactional model — e-commerce, payments, anything invoiced on what the customer actually ran last month — deal size stops being a single figure. What you need instead is a view of trajectory: where is this account's adoption today, where could it plausibly be in a year, 5% to 30% to 50%, and what does each step mean in revenue. That's the number that should shape your story and your calendar.

Still internal. Still not yours to quote.

What should an SE leader do about this?

Four moves, none of which take a quarter:

  1. Write the one-page pricing guardrail, including the sanctioned sentence.
  2. Put deal value in every SE assignment — no SE starts work on a deal without an order of magnitude.
  3. Make ACV visible in the CRM view your SEs actually open, not three clicks deep in a report they don't have access to.
  4. Check that your variable plan communicates deal weight. If SEs can't see which deals carry the number, the plan is decoration.

The default answer to "may SEs name prices?" is no. The default answer to "should SEs know what the deal is worth?" is yes, always, on day one — and the fact that so many teams have that backwards is why so many business cases arrive at procurement half-built.

Frequently asked questions

Should solution engineers know the price list? They should know the pricing metric and the order of magnitude of their deals. Memorizing a full SKU-level price list is usually pointless — lists change constantly, and stale precision is more dangerous than honest approximation. Know how price is built (per seat, per credit, per transaction) and roughly what this deal is worth.

What if a customer pressures an SE for a number and no AE is in the room? Use the agreed sentence, route it to the AE, and follow up the same day. That's not evasion; a binding number from the person who owns commercials is faster and safer than an estimate that has to be corrected later. If the pressure happens weekly, that's a signal your AEs need to be in more technical sessions.

Can an SE build a business case without knowing the price? Not a credible one. ROI is a comparison between the cost of the problem and the cost of the solution. Without the second half you can describe pain, but you can't tell the customer why the pain is worth paying to remove.

Should SE variable pay be tied to revenue? Many SE organizations tie at least part of it to team or individual revenue attainment, and that can work — but only if the SE can see deal sizes. An incentive tied to information you withhold is a tax on trust, not a motivator.


If you want your team to run the value conversation that makes the price look small — pain chains, mutual evaluation plans, positioning as an advisor rather than a demo monkey — that's the core of the Trusted Advisor Academy. Book a free discovery call, or trade notes with other leaders in the PreSales Leader Community.

Tim Brömme & Jan-Erik Jank are the co-founders of SE Rockstars, with 30+ years in enterprise PreSales and 350+ SEs coached.

Listen to the full episode

The original German-language conversation, including the price-list war stories: PreSales Unleashed: Sollten SEs die Preise kennen? (271)

Turn frameworks like this into everyday practice.

The Trusted Advisor Academy gives your SE team weekly training, coaching, and a community of 350+ solution engineers.

Book Your Free Discovery Call

100% free | No commitment required