Why your sales content never gets used
The battlecards exist. The pricing history exists. Somebody wrote the security answers and somebody else wrote the process docs. Reps still message a colleague instead. That is not a discipline problem, it is a friction problem, and buying a nicer place to store the content does not touch it.
The repository graveyard
The pattern repeats almost word for word across companies. A team buys a content management system. Launch goes well. Six months later adoption is low and the system has quietly become a place marketing parks assets. Nobody deletes it, so it sits there getting older.
The next move is usually a search layer on top: index the wiki, the docs drive and the chat tool, and give everyone one search box. That is a real improvement over four search boxes. It still assumes the behaviour that never happens. Reps do not go looking. They ask a person.
Asking a person is cheaper. One message, an answer summarised for the exact situation, no risk of reading three out of date documents first. Any solution that still requires the rep to stop, switch tools and search is competing with that, and it loses.
The test for any enablement tool: is it lower friction than messaging the colleague two seats over? If not, the content stays unused no matter how good it is.
Where the content lives and why it stays there
| Where it lives | Why the rep does not use it | What changes when the model can read it |
|---|---|---|
| Battlecards in a wiki | Written for a launch, filed under a page tree nobody remembers. Finding the right card takes longer than improvising an answer. | The objection gets answered from the card during drafting, with the page named, so the rep sees which card it came from. |
| Pricing history in a docs drive | Buried in old proposals with inconsistent file names. Reps ask the deal desk instead. | One question returns the last quote for that account with the file it came from, before the renewal call rather than after. |
| Security answers in a spreadsheet | Owned by one person who becomes the bottleneck for every questionnaire. | A first draft comes back from the approved answers, with gaps flagged rather than invented. |
| Process docs for onboarding | New reps do not know what exists, so they interrupt whoever is nearest. | The question gets answered at 11pm from the actual doc, and the colleague keeps their afternoon. |
| Deal context in chat threads | Searchable in theory. In practice nobody scrolls back through four months of a channel. | The thread that mattered gets surfaced alongside the answer instead of being lost to scroll depth. |
None of that requires new content. It requires the existing content to be readable from where the rep already is. That is an access problem, and access problems have a plumbing answer. The list of what to connect covers the docs drive and wiki connectors that do this part.
Content in the flow of work, four examples
Each of these assumes the model has read access to a shared drive and a wiki. Nothing here is a new document. It is the same content, requested at the moment it matters.
1. Answer a competitor objection from the actual battlecard
The prospect said our reporting is weaker than [Competitor]'s.
Find our battlecard for [Competitor] in the wiki and answer the
objection using only what that card says. Quote the card's own
wording where it is strong enough to send as is.
End with the page title and last-modified date of the card you
used. If the card does not cover reporting, say so and stop.“using only what that card says” is the line doing the work. Without it the model writes a plausible competitive answer from general knowledge, which is exactly the freelancing the battlecard was written to stop. The last-modified date is the second control: it tells the rep whether they are quoting something from this quarter or from two product cycles ago.
2. What did we quote this account last year
Search the shared drive for any proposal, order form or quote
addressed to [Account] in the last 24 months.
Give me, per document: date, list price, discount applied,
term length, and which products were included. Table format.
Do not average or summarise across documents. If two documents
disagree, show both rows and flag the conflict.“Do not average or summarise across documents” prevents the most expensive failure here. A blended discount number is useless in a renewal conversation and dangerous if the rep repeats it. Showing conflicting rows is more honest than a tidy single answer, and the conflict itself is usually the thing worth knowing.
3. Draft a security questionnaire answer
Here are 12 questions from [Account]'s security review.
Draft an answer to each using only our security documentation
in the shared drive. Cite the document and section for every
answer.
Where the documentation does not cover a question, or covers it
only partially, write NEEDS INPUT and name what is missing and
who is likely to own it. Do not fill gaps from general knowledge
about how software companies usually handle this.NEEDS INPUT is the whole design. A security questionnaire answered confidently and wrongly is worse than one answered slowly, because it goes into a compliance record. The explicit instruction not to fill gaps from general knowledge is what turns a drafting tool into something the security owner will actually sign off, since their review is now a short list of flagged gaps rather than a full reread.
4. Onboarding question without interrupting anyone
I am in week two. A prospect wants a 45 day trial instead of
the standard 14.
Read our process documentation and tell me: is that allowed,
who approves it, what the approval needs from me, and how long
it usually takes.
Answer only from the documentation and link each part of the
answer to the page it came from. If the docs are silent on any
part, say which part and tell me who to ask.“tell me who to ask” matters more than it looks. The model will not have every answer, and a new rep given a dead end goes back to guessing. Routing them to a named owner keeps the human in the loop for the genuinely undocumented parts while removing the twenty questions a week that were already written down.
The stage by stage versions of these, from first meeting through renewal, are on the sales stage workflows page. Salesgear's write-up of CRM workflows run through Claude covers the same shape where the source is the CRM rather than a docs drive.
What this does not fix
Three honest limits, because the argument above is easy to oversell.
Habits
A rep who does not want to change how they work will not be moved by a better answer arriving faster. Lower friction helps the willing. It does not convert the unwilling.
Measurement
A model reading your docs gives you no usage analytics by default. You will not know which battlecard got used, by whom, or in which deals, unless you build that separately.
Stale content
Wrong content becomes wrong answers delivered fluently and with a citation. Old docs do not get safer when a model reads them. They get more dangerous.
The measurement point deserves more than a card, because it is the strongest argument against the whole approach. Stitching together a wiki, a docs drive and a chat tool leaves you with no analytics on who used what and when, and if you cannot measure whether content is working you cannot improve it. The big enablement suites solve that part properly. Connecting a model to those same sources does not solve it at all. You trade measurement for adoption.
That trade is worth making when your current measurement is honest zero, which is where most teams are, because nobody was using the repository anyway. It is not worth making if you have content analytics that are driving real decisions. The stale content risk has one mitigation: make every prompt ask for the source and the last-modified date. That does not fix the document, but it puts the age of the answer in front of the rep, which is how out of date content gets reported rather than repeated.
Enablement as a system, not a programme
Programmes have a start date, an end date and a completion certificate. After the certificate everyone returns to what they did before, because nothing about their daily conditions changed. Systems change the conditions people operate under, and conditions are what actually change behaviour.
Adoption gets reinforced from two directions at once. Top down through managers who inspect and coach. Bottom up through systems that make the right behaviour the path of least resistance. Either one alone stalls.
The counterweight is human and it is where most of these efforts die. A senior rep refuses to adopt the new way of working. Their front line manager will not hold the line, because that rep is the top biller and the manager is afraid of losing them. Once one person is exempt, the system is optional, and optional systems decay. Remote work made this considerably harder. Managers have far less in person time with their teams, and some have never met their reps face to face, which removes most of the informal coaching that used to carry adoption.
Worth saying plainly: connected access is a system change, not a culture change. It fixes the friction argument. It does not fix a manager who will not have a difficult conversation.
Why certification does not stick
A knowledge check proves someone learned something once. It does not prove they can apply it three months later in front of a customer who is pushing back. The gap between those two is where most training budget disappears. Reinforcement through coaching and deal reviews outperforms more quizzes, because it happens against a real deal rather than a hypothetical one.
A three layer measurement model is more useful than a pass rate:
Readiness before the field
Can the rep deliver the message in a practice setting before they take it to a customer. This is a leading indicator, which is the only kind you can act on in time.
Execution in real calls
Does the message appear in actual conversations, in their own words, when the moment calls for it. This is where certification and reality usually part company.
Business outcomes
Win rate, cycle length, deal size. Real, but slow, and confounded by positioning, competition and whatever marketing did last quarter.
A deal dashboard alone cannot tell you whether the training worked, because too many other variables moved at the same time. Layers one and two are what let you attribute anything at all.
The buyer side of the same problem
A set of figures circulates widely in enablement discussions, attributed to Forrester and Gartner: buyer dissatisfaction around 81 percent, purchases that stall before closing around 86 percent, buyers running roughly 80 percent of the journey without a seller across about seven sources, and around 69 percent going back to a rep to validate something an AI told them. We are repeating those as second-hand attributions and we have not independently verified them. We could not find the primary reports behind every number, so treat them as directional rather than as evidence. This site's rule is that every claim names how we know it, and here the honest answer is that we know it because other people keep citing it.
The concept underneath is useful whatever the exact percentages turn out to be. Buyers do most of their work between conversations, from sources nobody on your side governs. They assemble a picture that feels confident and is often wrong. By the time it reaches a call it has hardened into an objection that nobody had the chance to correct while it was still a question.
The buyer arrives already holding a position. If the rep's response is slower and vaguer than the source the buyer used, the position stands. The case for content in the flow of work is not only internal efficiency, it is whether your side can answer with specifics at the speed the buyer formed the objection.
A starting point that is small enough to work
Point the model at one shared drive. Not the whole workspace, not every system at once. One drive holding three things: current battlecards, pricing and quote history, and the approved security answers.
Those three earn their place because they are asked about constantly, they are painful to search, and each has a clear owner who will notice if an answer is wrong. That last part matters most. A narrow scope with an owner produces corrections. A whole workspace with no owner produces silence, and silence is indistinguishable from working.
Two weeks is enough to know. If reps are asking the connected drive instead of messaging a colleague, the friction argument held and you can widen scope. If they are still messaging a colleague, widening scope will not help and something else is wrong.
Once that works, the next layers are the ones that put content near execution rather than near storage: shared team context so the same instructions apply for everyone, covered in the write-up on running Claude Cowork with a sales team, and packaged instructions for repeated tasks, covered in the guide to Claude skills for sellers. Both are the same principle applied one level up: the process travels with the work instead of waiting in a library for someone to come and find it.
Prompts on this page were run against a connected docs drive and wiki, July 2026. The buyer-side percentages above are second-hand attributions we have not verified, and are labelled as such in the text.