Software Sales Training: Teach the Permission, Not Just the Product

Most software sales training is product training with a sales module attached. New reps spend their first weeks learning features, integrations and the demo script, then get a few sessions on discovery and objection handling, then go live. It is an understandable design. The product is what the company knows best, it is easy to teach, and it is easy to test.

It is also aimed at the wrong half of the sale.

A software deal has two halves. The first is the decision: does this team want this product? The second is the permission: is this company allowed to buy it? Security has to approve it, IT has to support it, legal has to sign the contract, procurement has to process it, and increasingly someone has to confirm what the vendor's AI does with company data. Product training prepares reps for the decision. Deals routinely stall, slip and die in the permission — in front of people the rep was never trained to talk to.

This guide covers what software selling actually requires, the four modules most programmes miss, why the security review should be taught as a sales stage rather than paperwork, and a 30-day curriculum built around both halves.

What software selling actually requires

Three things make software different from most of what gets sold B2B, and each should shape the training.

The product changes how people work. Buyers are not purchasing a thing; they are agreeing to change a workflow, migrate data, retrain staff and live with the result. That is why the strongest opponent in most software deals is not a competitor but the current way of doing things — which costs nothing to keep and something to leave.

The buyer is a group, and some of its members have veto rather than enthusiasm. A champion can want the product badly and still be unable to buy it. The people who can stop a purchase — security, IT, legal, finance — are often not the people who wanted it.

The product touches company data. Almost every piece of business software stores, processes or connects to something the company would not want leaked. That makes every software purchase, however small, partly a risk decision. And the person who owns that risk is usually not in the first meeting.

The asymmetry training ignores

Here is why the permission half is so hard, and why it needs its own training.

A champion is rewarded if the purchase goes well: their team works better, their project succeeds. The people in the permission layer face a different payoff. A security reviewer who approves a vendor that later causes a breach owns that decision. A security reviewer who slows down a vendor that would have been fine faces, at worst, an impatient colleague. Approving gains them very little. Approving wrongly can cost them a great deal.

The champion is paid for the upside. The reviewer is blamed for the downside. A rep who sells the upside to the reviewer is answering a question they did not ask.

So the reviewer's default is caution, and the rep who treats them as an obstacle to be pushed past makes the default slower. The rep who treats them as a buyer with a different job — reduce risk, and be able to show they checked — gets through faster. That is a learnable skill. Most programmes never teach it.

The four modules most programmes miss

1. Selling to the permission layer

This is the module that pays back fastest, because the stakeholders are predictable and their needs are documented.

Security. A reviewer needs evidence, not reassurance. That means knowing which documents your company has and what each answers: an independent audit report such as SOC 2 or ISO 27001, a penetration-test summary, a data-flow description, the list of subprocessors, the data processing agreement, authentication options such as single sign-on, data residency, retention and deletion terms. In 2026, add the question almost every reviewer now asks: what does your AI feature do with our data, and is it used to train anything? A rep does not need to answer these personally. They need to know the documents exist, send them early, and recognise which questions need their security team on a call.

IT. IT's questions are about support and integration: how it is provisioned, how it connects to existing systems, who maintains it, what happens when it breaks. They are often the people who will live with the product after the champion has moved on to the next project. Our page on selling to a CTO covers the technical-buyer conversation in more depth.

Legal and procurement. Procurement's job is a fair price and a defensible process; legal's is acceptable risk in the contract. Reps should know which terms the company will move on and which it will not, how long the standard paper usually takes, and when to involve their own legal team. We wrote about selling to the head of procurement separately — the short version is that procurement is not the enemy of the deal, it is the enemy of an unprepared one.

2. Value, translated for each seat

The same product needs a different one-sentence reason for every person in the buying group. The champion cares about the workflow. Finance cares about cost and payback — see selling to a CFO. IT cares about support burden. Security cares about risk. The end users care about whether their day gets easier or harder.

A simple drill: give a rep the product and five seats, and have them write one sentence of value for each, in that person's language, with no feature names. Most new reps can write the first one. Few can write all five on their first attempt, and that gap is where multi-person deals are lost. How to actually work those people across a long deal is a separate subject — the motion itself — and belongs to enterprise selling; this module is only about being able to speak to each of them.

3. Discovery on the workflow, not the feature list

Product-heavy training produces reps who demo features, because features are what they were taught. Software is bought to change a workflow, so the demo that works is a rehearsal of the buyer's own workflow with the product in it — which is only possible if discovery found out what the workflow is.

Train discovery as the thing that earns the demo. A rep should be able to describe, before showing anything, how the buyer does the job today, what it costs them, and which step the product changes. Our guide to discovery calls covers the practice side.

4. The status quo as the opponent

In most software deals the real alternative is not a competitor. It is doing nothing: keeping the spreadsheet, the existing tool, or the manual process. Doing nothing has no switching cost, no migration, no retraining and no risk, which makes it very hard to beat on those terms.

Training should teach reps to quantify the cost of staying put, take migration and adoption seriously as objections rather than dismissing them, and recognise an incumbent objection when they hear one — we covered that in handling "we already have a vendor" and the wider set in SaaS sales objection handling.

The security review is a sales stage

Most sales processes treat security review as an administrative step that happens after the buyer says yes. That one sequencing decision makes deals longer than they need to be.

An illustration, with invented durations. The champion reaches a verbal yes in week 6. The security review takes four weeks. Procurement takes three.

	Run in sequence	Run in parallel
Champion's verbal yes	Week 6	Week 6
Security review	Weeks 6-10	Weeks 3-7
Procurement	Weeks 10-13	Weeks 5-8
Signed	Week 13	Week 8

Same buyer, same reviewers, same durations. Starting the review in week 3 and procurement paperwork in week 5 brings the signature forward five weeks. For a deal that begins in week 3 of a 13-week quarter, that is the difference between closing in week 11 of this quarter and week 3 of the next. A great many deals that "slipped because of security" slipped because of a decision made in the first fortnight.

Taught as a stage, the security review has entry criteria (the champion confirms the buying process), work the rep owns (sending the standard pack, booking the call with their own security team), and exit criteria (the reviewer's sign-off, in writing). It can be forecast, inspected and coached like any other stage. Treated as paperwork, it is invisible until it is late.

A 30-day curriculum

The design principle: every week covers both halves of the sale, and nothing is certified by quiz. A rep who can answer questions about the security review and a rep who can handle a sceptical reviewer on a call are different reps.

Week 1 — the customer and the product as a workflow. Who buys, why, and how they do the job today. The product taught through three or four customer workflows rather than as a feature list. The ideal-customer profile. End of week: the rep demos one workflow to a colleague playing a buyer.

Week 2 — discovery and the status quo. Discovery drills daily: the rep must find the workflow, its cost and the step the product changes before they are allowed to demo. The cost of staying put, and the incumbent objection. End of week: a recorded discovery call against a buyer who is happy with what they have.

Week 3 — the permission layer. A session with your own security team walking through every document in the security pack and what question each answers. The AI-and-data question. Legal's movable and fixed terms. A mock security call where a colleague plays a reviewer who asks for evidence and is not interested in the product's benefits. End of week: the rep runs that call and identifies which questions need their security team.

Week 4 — the whole buying group. The five-seat value drill. A full deal simulation, compressed into an afternoon: champion, finance, IT, security and procurement, each played by a different colleague, in sequence. Certification is this simulation, scored on whether the rep would have kept the deal alive in each seat — not on the demo.

Practise every day of the 30, not only in the weekly milestones. Skills built under pressure come from repetition with feedback, and a curriculum that is mostly listening produces reps who know a great deal and freeze on a call. If you are building a wider onboarding programme around this, our sales onboarding page covers the practice structure.

Where our tool fits

We build an AI roleplay tool, so read this section with that in mind.

The four modules above are mostly conversations with people new reps do not yet have access to: a CISO, a head of IT, a procurement lead, a CFO. That is where practice matters most and is hardest to arrange — the colleagues who can play a convincing security reviewer are busy, and the rep needs more than one attempt.

With SalesArmor, a rep can paste the LinkedIn profile of the actual security lead or CTO at a target account, or of someone in the same role, and run the conversation against an AI buyer built from that profile — as many times as it takes, before the real meeting. It is scored after each call, so a manager can see who is ready for the permission half of the sale and who is still only ready for the demo. For the wider market context, see SaaS sales.

Common questions about software sales training

What should software sales training cover? The product, taught as customer workflows rather than features; discovery; handling the status quo as the main competitor; translating value for each member of the buying group; and selling to the permission layer — security, IT, legal and procurement — including the security review as a sales stage.

Why do software deals stall after the buyer says yes? Usually because the permission half of the sale starts too late. Security review, IT approval, legal and procurement each take time, and if they begin only after the champion's verbal yes, they run one after another. Starting them early, in parallel, can take weeks off the cycle.

What is a security review in software sales? The buyer's assessment of whether a vendor can be trusted with company data and systems. It typically involves a security questionnaire and documents such as an independent audit report, penetration-test summary, data processing agreement and subprocessor list, and increasingly questions about how the vendor's AI uses customer data.

How do you speed up a security review? Ask about the buying process in the first meetings, find out who reviews security and what they need, send the standard documentation early, and bring your own security team onto a call for technical questions. Treat the reviewer as a stakeholder whose job is reducing risk rather than as an obstacle.

How long should software sales onboarding take? The core curriculum can be covered in about 30 days if every week includes daily practice and ends in a roleplay rather than a quiz. Full productivity takes longer and depends on deal cycle length; the first month should prove the rep can handle both the decision and the permission halves of a sale.

What is the biggest gap in software sales training? Most programmes teach the product and the demo well and barely touch the people who can stop a purchase — security, IT, legal and procurement — even though that is where many deals stall or are lost.

How do you train reps to sell to technical buyers? Teach them which questions they can answer, which documents answer the rest, and when to bring in a technical colleague. Then practise the conversation against someone playing a sceptical technical buyer who is uninterested in benefits and wants evidence.

Should software sales reps be certified? Yes, but by roleplay rather than quiz. Knowing the answers about a security review and handling a sceptical reviewer on a call are different skills, and only a simulated conversation tests the second.

A note on sources

This guide contains no figures for buying-group size, sales cycle length, security-review duration, onboarding time or no-decision rates. Those numbers are widely quoted in software sales, mostly from vendor and analyst surveys whose definitions of a "buying group", a "deal" or a "review" vary and are rarely published alongside the headline. They also vary enormously with deal size and the buyer's industry.

The sequencing table uses invented durations, labelled as such; its point holds for any durations, because running two steps in parallel instead of in sequence shortens the total whenever both take time. The arithmetic was checked before publishing.

The security documentation described — independent audit reports, penetration tests, data processing agreements, subprocessor lists, single sign-on — reflects common practice in B2B software procurement. The decision-and-permission split, the reviewer's asymmetric payoff, the security review taught as a stage and the 30-day curriculum are ours.