Sales playbook version control for training content

Short answer

Version control for training content tracks four things: customer profiles, good-conversation standards, evaluation criteria and weights, and facts in the knowledge base. For each change it records what changed, why, who approved it and from when it applies. That answers two practical questions: "what content was this employee practising with last month?" and "can old and new scores be compared?"

Version control does not need a complex system. For a small team a spreadsheet and a simple naming rule are enough. What matters is the rule itself: content changes, but the trace of each change remains.

Why versions are needed

Training content is alive: prices change, new objections appear, the standard is improved. Each change is useful, but untracked change causes three problems. First, the progress chart lies: did the employee's score rise because they improved or because the profile got easier? Second, disputes cannot be settled: "I answered correctly" — against which standard? Third, mistakes cannot be rolled back: if the new profile works badly, the previous one is gone.

What to version

1. 1The customer profileType, behaviour, objections, knowledge, end condition. A change in behaviour changes difficulty.
2. 2The good-conversation standardThe reference point for evaluation. When the standard changes, the same conversation can get a different score.
3. 3Criteria and weightsWhen a criterion is added or removed, or a weight changes, the total score starts measuring something else.
4. 4Knowledge base factsPrice, terms, warranty — the information profiles and standards refer to.

Two kinds of change

• Minor change: a typo, clearer wording, a fact update (a new price, say). It does not break score comparability. It is logged but does not need a new version number.
• Major change: a new objection layer, a change in difficulty, a new standard, a change of criterion or weight. It breaks score comparability. It is logged as a new version and announced to the team.

Naming and the log

A simple rule: the profile name plus a version number — "Price objection v3". Each log line: date, profile or standard, old and new version, a short description of the change, the reason, and who approved it. The reason column matters — six months later nobody will remember why an objection layer was removed.

• Sample line: "12 September — Price objection v2 → v3 — second objection layer added (competitor offer) — reason: heard often on real calls — approved: head of sales".
• Sample line: "20 September — Criteria v1 → v2 — next step weight from 15 to 20 — reason: team priority — approved: sales director".

Reading scores across versions

After a major change, do not compare old and new scores directly. There are three ways. First, measure progress within a version: the first and last conversation on the same version of the same profile. Second, if criteria changed, re-evaluate old conversations against the new criteria — if the system allows it. Third, mark the version change on the chart with a line so a jump is not read as "progress".

The same problem arises when evaluation criteria for real calls change; see scorecard versions.

Approval and announcement

1. 1ProposalThe profile owner writes down the change and its reason.
2. 2TestThe new version is tested with one or two conversations — with a weak and a good answer.
3. 3ApprovalThe head of sales approves a major change; price and promise statements are approved by their owner.
4. 4AnnouncementTo the team: what changed, why, from when. Employees need to know why their scores changed.

The separate approval flow for price and promise statements is described in training content governance.

How to explain it to employees

After a major change employees' scores may drop — the profile got harder or the standard changed. Without an explanation this feels like a penalty. The announcement should be short: "We added a competitor offer to the price objection profile because it comes up often on real calls. Your scores may be lower next week — that is expected. We will measure progress within the new version." That protects trust and shows employees the purpose of the change.

The archive

Do not delete an old version — archive it. An archive has three uses: rolling back when a new version works badly, checking a disputed result against the standard in force at the time, and seeing how content has evolved. Archive unused profiles too, so employees do not practise with an old profile.

Illustrative example: a jump

This is not a real customer case. A head of sales sees on the progress chart that the team's average score jumped sharply in one week and takes it as a training success. Looking at the log shows that in that week the second objection layer was removed from the "indecisive customer" profile — the profile got easier. The manager marks the jump on the chart as a version change and starts measuring progress only within the new version.

Common mistakes

• Editing a profile without logging it.
• Not announcing a major change to the team.
• Comparing old and new scores on one chart after criteria change.
• Deleting an old version.
• Not recording the reason for a change.
• Keeping unused profiles active.

Limitations

Version control keeps the trace of changes but does not say whether a change was right — testing and real results show that. In a team that makes major changes too often, progress is hard to measure even with a version log. For a small team a simple spreadsheet is enough; a heavy process slows updates.

In Vexvon AI Training

In Vexvon AI Training each evaluation keeps the rubric version and weights it used, so it stays clear which rules an older result was calculated with. Calls scored under an older rubric are counted as "needing re-evaluation" in progress and can be re-evaluated from the panel. A profile can be deactivated without being deleted. A change log for profile content is the company's own process.

Next step

Open a spreadsheet today: profile, version, date, change, reason, approval. Mark every existing profile as "v1". For when to update see the update signals, and for criteria the scorecard; more articles are in rollout and reliability. To build it together, get in touch.