From Claude licences to working sales and marketing workflows
Building the shared knowledge Claude needs to understand what the consultancy sells, and the governed plugins that use it.
Background. Licences in place, little finished work.
The consultancy already had Claude licences in place, but sales and marketing used Claude for one-off tasks rather than for the processes that take up their time. Most of its Claude skills were reference material, and only two produced finished work.
- 74%
- of active Claude seats using the new plugins within 30 days
- 17
- offerings now readable by Claude, up from 3
- 5 weeks
- from first session to fifteen tested workflows in production across five plugins
The challenge. Claude knew the brand, not the business.
Claude could describe only 3 offerings in depth, so account research was unreliable for most accounts. Sales named proposals, statements of work and case studies as its biggest time sinks.
The consultancy already knew about the gap. What Nascent Group added was working out how much reference material is enough to start, and which processes to build first.
Key requirements
- Research that covers every offering the consultancy sells.
- One shared source of reference material that every skill draws on.
- Branded output built from the consultancy’s own templates.
- A voice that fits informal formats as well as formal ones.
- A build order set by evidence about where the time goes.
- A skill catalogue that stays reliable as it grows.
- The ability to run and extend it without Nascent.
Key challenge areas
Claude couldn’t see what the consultancy sells
Most offerings were not described in enough depth for Claude to use. Research steered every account towards the few offerings Claude did know, missing most of what the consultancy could sell.
Off-brand output
Decks generated by Claude did not hold the brand, so finished material still depended on design time.
One voice for every format
A single formal corporate voice was wrong for newsletters and other informal formats, so drafts in those formats needed heavy rewriting.
Sales knowledge in people’s heads
How the team qualifies and pursues work was not written down anywhere Claude could read.
Reference material Claude couldn’t use
What Claude needed to know was spread across separate repositories, with no service catalogue in a form it could use.
Our approach. Three rules decided what got built.
Processes, not wish lists
We mapped each function’s work as a set of distinct processes, and every skill traces back to one of them.
Measure before choosing
We measured how often each process runs, who does it and how long it takes, then ranked each one by value against build cost. That ranking set the build order.
Cap the catalogue
The more skills Claude carries, the worse it gets at picking the right one, so each plugin has a fixed limit. Working within that limit forces a decision about what matters most.
How it ran. Five weeks to live skills.
- Weeks 1 and 2
Discovery
Working sessions with sales and marketing on how the work gets done today.
- Week 3
Measure and prioritise
Measuring where the time goes and agreeing a build order.
- Weeks 4 and 5
Build
Fifteen skills across five plugins, built in ranked order.
- From week 6
Test and hand over
Testing with sales and marketing, a playbook for the sales team, and a governance model the consultancy runs itself.
Before and after. What changed in the work.
Before
- 3 offerings described in enough depth for Claude to use.
- Two skills produced finished work.
- One formal voice for every format.
- Claude used for one-off tasks.
After
- 17 offerings described in a form Claude can use.
- Eight skills produce finished work.
- A house style with a register for each kind of format.
- Skills built around the processes that take the most time.
Results. Fifteen skills, in use within a month.
- 74%
- of active Claude seats using the new plugins within 30 days
- 17
- offerings now readable by Claude, up from 3
- 5 weeks
- from first session to fifteen tested workflows in production across five plugins
Fifteen skills in five plugins
Two shared plugins act as a knowledge hub for everyone, covering the brand, the voice, and the consultancy’s offerings and customers. Each function then has its own plugin, so each person carries only the skills for their own work.
Sales skills
Account research, covering prospecting, existing-account review and target-list building. Alongside it: outreach drafting, meeting preparation, meeting summaries and proposal drafting.
On-brand marketing output
Case studies and battle cards, each built as PowerPoint and PDF from the consultancy’s own templates.
A voice for each format
The single corporate voice became a house style with a register for each kind of format, plus a ban list of the constructions that mark text as machine-written.
Guardrails
Account research labels every claim by its source. Skills never generate pricing. Outreach drafts are never sent automatically.
Tested and governed
A suite of 149 test cases checks that the right skill fires and follows its own rules. Every change is checked automatically and released by hand from the consultancy’s own repository, and each function has a named owner for its skills.
Every member of the marketing team was active on their plugin within 30 days. Adoption in sales is still building, and testing with the wider team is under way. So far, testing has produced fixes rather than rejections. Nascent holds no standing role once those fixes are complete.
What the data changed
Proposal writing is a whole-team job.
The assumption was that a few people write most proposals. The data showed the work is spread across the whole sales team, so the proposal skill went to everyone.
The most-requested automation ranked last.
RFP responses were the task people most wanted automated. They are dreaded but infrequent, so they ranked bottom once time was measured. Building them anyway is a legitimate choice, but it should be a deliberate one, not a request mistaken for a measurement.
Start with where the time goes. Then build the skills that win it back.
We measure your teams’ processes first, so what gets built is chosen by evidence rather than by request.