Presales explained: role, process, and tools

Presales is the set of technical and strategic activities a B2B team runs before a deal closes: qualification, discovery, solution design, demos, technical validation, and every document that carries those decisions to the buyer.

Most descriptions of presales stop at the first half of that sentence. They cover the conversations (discovery calls, demos, technical Q&A) and skip the artifacts (technical proposals, security questionnaires, RFP responses, proof of concept plans, handoff documents). That omission matters, because the artifacts are where these teams lose most of their week.

This guide covers what presales is, how the roles are named, what the process actually produces at each step, why the deliverable layer is the real bottleneck, and how to choose tools for it.

What is presales?

Presales is the phase of a B2B sales cycle where technical experts validate that a solution fits a buyer's requirements, and produce the evidence that proves it. It sits between marketing-qualified interest and a signed contract, and it is owned jointly by an account executive and a technical counterpart.

The function exists because complex products cannot be sold on relationship alone. When a buyer evaluates an infrastructure platform, a compliance suite, or a managed service, someone has to answer questions the account executive cannot: how the integration works, whether the data residency requirements are met, what the migration path looks like, how the pricing model behaves at scale.

Where presales starts and where it stops

Presales starts at qualification, when a team decides whether an opportunity is worth technical investment. It ends at signature, when the deal transitions to implementation or customer success.

Two boundaries cause most of the confusion in practice:

• The front boundary. Prospecting and lead generation are usually out of scope. The function engages once an opportunity exists and needs technical validation. In smaller organizations the two blur, and a solutions consultant may run outbound technical webinars.
• The back boundary. Post-sales implementation sits outside the scope, but the handoff document that makes implementation possible is. Teams that skip this handoff pay for it in churn and scope disputes six months later.

Why the name is misleading

The term "presales" is one of the worst-named functions in B2B software, and the confusion is structural. In consumer contexts, a presale is an early ticket release or a token launch. In B2B, it describes a technical discipline that has almost nothing to do with early access.

The name also implies the work is preparatory, which understates it. Buyers routinely make their decision during technical validation, not after it. Paul Drews, who leads US investments at Salesforce Ventures, has described the shift plainly in TechCrunch: B2B buying moved from a top-down process to a bottom-up one where buyers want hands-on product access, and the technical function grew in importance as a result. The role that carries the name "pre" is often the one that decides the deal.

Presales vs. sales: what is the actual difference?

The difference is ownership, not seniority. Sales owns the commercial relationship and the close. Presales owns technical fit and the proof that supports it. They work the same deal from two angles.

The practical implication: a deal can be commercially healthy and technically dead, or the reverse. Reps who ignore the technical track discover the problem in procurement. Technical teams that ignore the commercial track spend weeks building proof for deals that were never going to be funded.

Who does presales? Sales engineer, solutions consultant, and the title problem

Presales roles carry at least six different titles for broadly similar work, and the title depends more on the company's industry than on the actual scope of the job.

This is worth understanding before you hire, benchmark salaries, or read a job description. A "solutions engineer" at a SaaS scale-up and a "presales consultant" at an IT services firm may do the same work with different words.

Sales engineer

The most common title in North American software. A sales engineer runs technical discovery, builds and delivers demos, answers integration questions, and supports proof of concept work. The role skews toward product depth and live customer interaction.

Solutions consultant

More common in enterprise software and in Europe. A solutions consultant works further up the abstraction stack: business process mapping, value engineering, and building the business case alongside the technical case. In practice, the difference with a sales engineer is often nominal.

Solution architect

Present where the sold thing is a system rather than a product, which is typical in IT services and telecom. A presales solution architect designs the target architecture, sizes the infrastructure, and produces the technical documentation that the buyer's own architects will review.

Presales and bid support

In construction, industrial services, and public sector vendors, presales is often organized around formal procurement. The technical expert works with a bid or proposal manager, and the primary deliverable is a structured response package rather than a demo. This is where the function overlaps most heavily with bid management.

The presales process, step by step

The presales process runs in six stages, and each stage produces a specific artifact. Mapping stages to artifacts is the fastest way to find where a team is losing time.

1. Qualification and go/no-go. The team decides whether the opportunity justifies technical investment. Criteria typically include budget confirmation, decision timeline, incumbent presence, and whether the requirements are winnable. The output is a short qualification memo that makes the reasoning reviewable later.
2. Discovery and scoping. A structured conversation to surface the real requirements, the constraints behind them, and the stakeholders who will judge them. Strong discovery separates stated requirements from underlying problems. The output is a requirements document that the buyer can confirm.
3. Solution design. The technical expert maps requirements to product capabilities, identifies gaps, and decides what gets addressed by configuration, by roadmap, or by partner. The output is a solution architecture document or scoping note.
4. Demo and proof of concept. The demonstration should reflect the buyer's own workflow, not a generic tour. For higher-stakes deals it extends into a proof of concept with defined success criteria. The outputs are a demo script and a POC plan with acceptance criteria.
5. Technical validation. The formal evidence stage. Security questionnaires, compliance reviews, technical proposals, and RFP or RFI responses. This is the least visible stage and the most expensive one, which is the subject of the next section.
6. Handoff to delivery. Everything learned during evaluation gets transferred to the implementation team: assumptions, commitments made, edge cases surfaced, and constraints agreed. The output is a handoff document.

A quick diagnostic: if your team can name a clear owner for stages 1 through 4 but nobody owns stages 5 and 6, you have found the gap most technical sales organizations have.

The hidden cost of presales: the deliverable layer

The presales bottleneck is not demo capacity. It is document production, and it is almost never measured.

Every stage above ends in a written artifact. A mid-market technical evaluation can generate a qualification memo, a requirements document, an architecture note, a demo script, a POC plan with acceptance criteria, a security questionnaire, a technical proposal, and a handoff document. Eight documents, each assembled by hand from files scattered across a CRM, a shared drive, past proposals, and somebody's inbox.

The macro data points in the same direction. Salesforce's State of Sales research found that reps spend roughly 28% of their week actually selling, with most of the remainder consumed by deal management and administrative work. Technical teams face the same arithmetic with an added complication: their non-selling work is expert work, so it cannot be delegated to an assistant or absorbed by a template.

What this looks like in practice

Consider a mid-sized IT services firm responding to a public sector opportunity. The buyer sends a requirements matrix with 180 line items, a security annex, and a request for a technical memorandum. Three engineers spend four days assembling a response, most of which restates content that already exists in a proposal the same firm submitted eleven months ago for a comparable scope.

That is the pattern: the knowledge exists, but it is not retrievable in a form that produces a document. Every response starts closer to a blank page than it should.

The trend is going the wrong way. Gartner's B2B buying research has documented for years that enterprise purchases are decided by buying groups of roughly six to ten stakeholders, each arriving with their own evaluation criteria. More stakeholders means more parallel evidence: a security lead wants the questionnaire, a technical architect wants the integration detail, a finance owner wants the business case, and a procurement officer wants the formal response format. The number of conversations grows linearly, but the number of documents grows faster.

Where AI actually helps

This is the layer where generative tooling has a defensible use case, and it is a narrow one. AI is poor at judgment calls like go/no-go decisions or reading a room during discovery. It is good at retrieving prior technical content, restructuring it against a new requirement set, and producing a first draft in the required format.

That distinction matters when evaluating tools. A platform that promises to replace technical judgment is selling something that does not exist. A platform that removes the assembly work and returns a reviewable draft is solving a real and measurable problem.

Cobl is built for that second job. It connects to the systems where deal context already lives (CRM, email, notes, shared drives) and generates the full set of deal materials rather than a single document: qualification notes, technical proposals, questionnaires, and slides. Adista, a French telecom and IT services group, uses it exactly this way. Frédéric L'Excellent, Regional Pre-Sales Manager, describes generating a long technical response document in under five minutes at roughly 90% accuracy, ready for review. Read the full story here.

The 90% figure is the important part. AI-generated technical content is a starting draft, not a deliverable. Human-in-the-loop review is not optional in presales, because the person signing off on a technical commitment is accountable for it. The gain is the removal of assembly work, not the removal of expertise.

Presales tools: five categories, not one shortlist

Tooling for this function is not a single market. It is five distinct categories that solve five different problems, and most teams need two or three rather than all five.

Buying in the wrong category is the most common mistake. Teams that feel overloaded often buy a demo platform, because demos are the visible part of the job. If the actual bottleneck is questionnaire and proposal volume, a better demo platform will not move the number.

What to look for in a presales tool

• Connection to your real deal context. A tool that starts from an empty text box repeats the problem it claims to solve. It should read from the CRM, email, notes, and file storage where the deal already lives. This is why CRM integration is a functional requirement rather than a nice-to-have.
• Reuse of approved content. Technical answers should improve with every deal. If the same security question gets answered from scratch each quarter, the tool is not doing its job.
• Output formats that match the buyer's request. Buyers ask for PDF, Word, and PowerPoint. A tool that only produces content inside its own interface pushes formatting work back onto the team.
• Brand and structure control. Client-facing technical documents represent the company. Consistency between a junior and a senior contributor is a governance requirement, not a preference.
• Data handling you can defend. Presales documents contain architecture details, pricing, and customer data. Check where data is stored, whether it trains external models, and what the compliance posture is. Cobl publishes its security and data residency policy for exactly this reason.
• Time to first useful output. If a tool needs a three-month content ingestion project before it produces anything, the payback period may outlast the budget cycle.

Presales metrics worth tracking

Presales is chronically under-measured because its output is not a closed deal. The workaround is to track technical progression and workload separately from revenue.

The last metric in that table is the one almost nobody tracks and the one that changes decisions. If your engineers spend 40% of their week producing documents, that is the number that justifies either headcount or tooling. Without it, tooling and hiring requests get evaluated on anecdote.

For SaaS teams specifically, technical win rate is worth isolating from overall win rate. A deal lost on price and a deal lost on integration gaps require completely different responses, and a blended number hides both.

Two practical cautions on measurement. First, do not build the tracking on self-reported timesheets alone: engineers under-report administrative work because it feels like something they should have finished faster. A two-week structured sample, logged in blocks, gives a more honest baseline than a quarterly survey. Second, resist turning these numbers into individual performance scores. The moment coverage or time-to-demo becomes a personal KPI, the data quality collapses and you lose the diagnostic value that justified collecting it.

Build a presales function that scales

Presales is where complex B2B deals are actually won, and it is still described far more often in terms of what it says than what it produces. The conversations matter, but the documents are what buyers circulate internally, what procurement scores, and what implementation teams inherit.

Teams that scale presales well do three things: they name an owner for every stage including validation and handoff, they measure how much technical time goes into document production, and they remove assembly work without removing review.

Ready to see what that looks like? You can try Cobl for free, with around 5 generated documents per month. Try it here.