Our sales team started using Claude on their own.
The output was all over the place. Two people researching the same company produced two documents that looked nothing alike, neither looked like Rootline. A deck going out to a prospect might follow our brand guide, or might follow whatever Claude thought looked good that afternoon.
I wanted two things: that the least Claude-savvy person on the team produces something usable, and that what leaves the building looks like it came from one company. Every option I looked at could do the work. They differed in whether a salesperson would ever end up inside the thing.
I built something and two weeks in, the team told me they weren't using it. They were wrong.
Four options I considered
Claude Design. Best-looking output of anything on the list, and it lives in its own window. Our sales team works in the chat, sometimes in Cowork. The instruction: "go somewhere else first" was a non-starter. Marketing picked it up and uses it a lot. Sales forgot about it and barely touched it.
A project. Put the brand guide, the product knowledge and the instructions in a project and tell everyone to work there. Close, but a new chat is the default, a new project is a new way of working. Same as before.
Individual skills. Everyone installs what they want, everyone ends up on a different combination of versions, and updating anything means asking seven people to go and re-install.
A Git repository of CLAUDE.md files. The way I would naturally go as a developer. Anyone can contribute easily and get new changes with barely any effort. However, it confuses anyone who does not use Git, it rots because nobody pulls unless you instrument the pull, and it only applies inside that one folder.
All four ask the salesperson to remember something before the tooling applies. Working with sales for some time has taught me this will not work.
Why I chose plugins
A plugin is skills, instructions and assets in one versioned bundle. Installed once, active everywhere in Claude after that.
Engineers and product people go through Claude Code: add a marketplace, add the plugin. The marketplace can be any repository. Ours is an internal repository, so giving everyone read access was enough.
Sales gets the workspace route, and that's the part that matters. I zip the plugin and upload it as workspace administrator. It shows up for everyone under Customize, with our own plugins sorted to the top under the company name. A salesperson opens Customize, sees Rootline, clicks install. When I upload a new version they get it without doing anything.
The Git option was going to need instrumentation and nagging to stay current. Here there is nothing to keep current for individual reps, the work is on my side.
What is in it
Design. Our brand guide, encoded. Colours, type, spacing, the rules. Everything visual goes through it, which is why I never have to check whether the deck skill and the research skill agree on what a heading looks like.
Decks. Slide types with templates, plus rules for what belongs on a slide. Decks from two different people now look like they came from the same company.
Knowledge base. Vetted answers about Rootline, the product and pricing, derived from what we already had: internal docs, public docs, sales enablement material, the website, the blog, and the product documents and epics in GitLab. It goes stale, so I re-derive it with a script from my laptop every couple of weeks. A question about our own product now gets a vetted answer instead of one assembled on the spot from whatever is public. The public docs are shipped with the plugin instead of being fetched on every question. This reduces latency and the cost is almost zero since Claude can copy it over from the internal repo.
Company research. A brief before the first call: profile, funding and growth signals, fit scores, the provider they run today, and what our CRM already knows.
PSP detection. Which payment provider a company uses. It finds the checkout and reads what the page loads. This is checked for tokens or artifacts pointing to one of our competitors. For a platform it goes a level down: find shops running on it, probe a few, report whether payments are embedded at platform level or every merchant brings their own. That decides whether a platform is worth a conversation. It used to be someone clicking through checkouts by hand.
Building one
A plugin is a directory with a manifest and a set of skills. That sounds more sophisticated than it is. Most of it is markdown. A skill is a folder with a markdown file saying when to use it and what to do, plus whatever it needs alongside: templates, reference files, scripts. If you have written a decent CLAUDE.md you have most of a skill.
Three things to keep in mind when writing a skill:
Tune the trigger. The description is all Claude sees when it decides whether a skill applies, and it gets matched against however the salesperson happened to phrase things. Most of my tuning went there. Write the phrasings people actually type. The opening of ours for decks:
name: deck
description: >-
Build an on-brand Rootline presentation (pitch deck) as a single self-contained
HTML file. Use when the user asks to make a deck, pitch, presentation, or "slides for {company}", a demo deck, or a post-call follow-up deck.
Also let the descriptions hand work to each other. Our research skill ends with "For a bare 'which PSP do they use', /rootline:psp answers without the full brief", and design hands anything shaped like a presentation to the deck skill. Those lines fixed most of my wrong-skill-fired problems.
Call scripts where you can. Anything a skill can get from a deterministic script, have it call the script. Same answer every time, faster, cheaper. Same lesson we learned on the engineering side.
Ship the assets with it. Docs, templates, brand files. If the model has to go and find something on every run, you pay for that on every run.
Then zip it and walk to people's desks. I installed it for seven people, sitting next to each of them while they clicked through it. Two minutes each. Everyone ended up with it, and several of them later forgot the install had happened.
Two weeks later
I asked people what they thought of it. Nothing formal, just at their desks.
They said they did not really use it. Mostly I got blank stares. One person told me they thought they had to click something first, or open some project, to switch it on.
I believed that for about a day.
Then I sat down next to them while they worked. Skills actually fired, decks came out on brand, product answers coming from the knowledge base. I could see it in what they were sending out, which followed the brand guide in a way it did not before.
They did not know, because using it feels like using Claude. There is no moment where you enter the tool. You ask for a deck and a deck arrives. The only visible sign is the skill name appearing while it works. Once I pointed at that line and said "that is the plugin", everyone got it.
Nobody notices it, so the feedback loop is gone
Internal tooling has worked when it stops reading as tooling. I would not design it any other way.
It does break the obvious way of checking. Asking the team whether they use it gave me the opposite of the truth. What told me was the output, and sitting next to people.
I have no way of seeing usage. I do not know how many decks came out of the deck skill last month, which skill fires most, or which one never fires at all.
Because it is so seamless, I don’t get any complaints either. People just work around the things that annoy them, not realizing we can fix it structurally.
If you have rolled tooling like this out to a non-engineering team, how do you find out whether it is being used? Is there a way to get metrics on plugin usage?
