Tiana Clemons · Oct 27, 2026 · Case Studies
About this engagement
Our client is a B2B API company in the HR and payroll space. They sell to software companies that need access to employment data, across industries.
Their new VP of Sales came to us with two things on his plate: standardize how the team sells, and get an AI project under his belt that actually had impact. We built a solution that did both, starting with the data underneath it. Claude now reads the client's own Salesforce and Gong call library, and three custom skills turn that data into the three documents every deal runs on: a mutual action plan, an ROI business case, and a proposal.
Our partnership enabled the following results:
The Challenge
The team had a playbook they liked, but they did not have consistency in how reps used it. Mutual action plans and business cases were built by hand in Excel and Google Docs, so formats drifted from rep to rep. Brand, styling, and the selling points that mattered in each target industry were applied differently every time, meaning two prospects in the same industry could receive documents that looked like they came from two different companies. At times, internal notes made it into external-facing documents.
Building any one of these documents meant pulling from five places. The deal sat in Salesforce. The numbers the buyer had quoted on calls sat in Gong. Context was scattered across Slack, Notion, and Google Drive. A rep gathered all of it manually, did the math themselves, and formatted the result themselves. How good the document was depended on who built it and how much time they had that week.
The VP of Sales wanted a baseline: one standard for how every rep proves value, built on data the company already had. The question they brought to us is one we hear often now: can AI standardize this without making everything it touches read like generic AI output?
The Solution
The team went from documents built by hand across five systems to three branded deliverables generated on request, with every number traceable back to the CRM or a call.
In working sessions they showed us the best version of each document, and we worked backwards from there, stripping each one to its base elements and rebuilding it as a template in code. Whatever the best rep was already doing became the default for everyone.
At a high level, here is what changed:
| Before | After | |
|---|---|---|
| Built by hand in Excel and Google Docs, formats drifting rep to rep | → | Generated on request from live deal data, one template per document |
| Data pulled from five systems, manually, for every single document | → | Salesforce and Gong read directly, with Slack, Notion, and Drive for context |
| Brand applied by hand, differently by each rep | → | One brand file setting fonts, logo, and tone on every document |
| Internal notes reaching customers, with nothing to catch them | → | A quality check that blocks any file exposing internal data |
And now, here is how we got there.
One plugin holding three skills
A skill is a packaged set of instructions, templates, and rules that teaches Claude to produce one specific document the same way every time. A plugin bundles related skills together with the files they need to run. This one holds three skills, the client's brand assets, and the scripts that handle the calculations.
The plugin connects to Salesforce through MCP, an open standard that lets an AI model read from business systems securely, and to Gong for call data, with Slack, Notion, and Google Drive supplying deal context where they are connected. The plugin reads only. It writes nothing back to Salesforce or anywhere else, and the only things it produces are files.
The three skills line up with three stages of a deal, and each one uses the output of the last, so by the end of the cycle the proposal is built from work the rep has already reviewed and the buyer has already seen. A rep does not need to know any of this. They ask Claude for the document in plain language, answer a question or two, and review the file.
What the skills are allowed to read
Before any of it could be trusted, we had to settle what the plugin reads. This CRM had a specific issue: years of changes had left duplicate fields where only one of the pair was still maintained, so an automated read would pull the abandoned copy and come back with nothing, or with something out of date. Any generic AI integration would have hit that on day one.
The audit we ran before building found the same pattern in how completely records were kept. Account level data was strong, with company size and tier populated on roughly 97 percent of accounts. Opportunity level data was thinner: fewer than a quarter of open opportunities had next steps or a business outcome recorded. That is normal for a fast-moving sales team. It is why the skills read call recordings and internal channels as well as the CRM. Where a field is empty, the information usually exists in a call recording or a Slack thread.
So we set the data rules before building anything on top of them.
- A verified field list. The skills read only the fields the team actually maintains, and skip the dead duplicates. We checked every one against the live org before launch.
- No invented numbers. Every figure in every document has to exist in Salesforce or in a Gong call. When something is missing, the skill tells the rep in chat instead of filling the gap itself.
- Math in code. Calculations run in bundled scripts rather than being worked out by the model, so the same inputs always return the same output.
- A quality check on every file. No file can be delivered until it passes a check for structural errors and for internal data or internal system names appearing in a customer-facing document.
That is why a rep here can send one of these documents without checking it line by line.
Early in the deal: the mutual action plan
A mutual action plan is the shared roadmap between buyer and seller, covering every stage the two teams need to hit to get from first conversation to signature and go-live. A rep names the account. The skill pulls the deal from Salesforce and the call history from Gong, works out who the champion is, and checks whether this is a new customer or an existing one, confirming its read with the rep in one plain-language question. Then it builds the plan backwards from the go-live date, laying out every milestone, owner, and deadline in between.
From that one specification it produces two files. The internal version keeps the deal economics and the source notes the account team needs. The customer version has all of it removed, and the quality check will not release the file until it is clean. One request covers both audiences, with no manual cleanup before sending.
Mid-deal: the ROI business case
When the conversation turns to value, the ROI skill sizes the business case from the account's own Salesforce data: headcount, revenue, and account tier. It adds the metrics the buyer stated on calls, pulled from Gong and cited by call date, so every assumption traces back to something the buyer said or something the CRM holds.
The math runs in code, across three scenarios from conservative to upside, with the value levers changing depending on what the account uses the product for. If an input is missing, the skill asks the rep for it instead of guessing. The finished file comes out in the client's brand as a Word document, spreadsheet, or PDF.
End of the deal: the proposal
At the close, the proposal skill picks up the customer action plan and the ROI case and adds the quoted pricing, pulled from the quotes the client's CPQ system writes into Salesforce. If no quote exists yet, the skill stops and tells the rep to configure it rather than substituting an estimate. It spots multi-year ramps and adds a per-year summary, then composes everything into one branded proposal covering the plan, the value, and the price. The rep sends their champion one document instead of three.
The Results
Building a plan, a business case, or a proposal used to mean a rep collecting data across five systems, doing the math, and formatting the result. Now it is a request typed to Claude and a few minutes of review. The sourcing and the math happen in code, and the brand is applied for them.
Reps get those hours back for selling. The client's internal team is out of the document work entirely. And leadership got the baseline the VP of Sales came in to build, which is that every buyer sees the same standard of proof whichever rep they are working with.
Those hours add up because of the volume. In a year the team produces around 187 proposals and 294 technical validations, plus the action plan refreshes that go with them. Building those by hand costs over 1,000 hours of administrative work annually. At 75 percent adoption across the team, the three skills give back about $57,000 of seller time a year, or roughly $4,800 a month.
The team runs it themselves
None of this depends on us. The plugin sits in the client's own environment and reads from their own systems, and reps run it in plain language without anyone from Lean Layer in the loop. When the documents need to change, the things to edit are the brand file and the field list, not the model.
That was the point. A sales team that has to call an agency every time a template changes has not gained much. The capability stays with the people who sell.
Request a free consultation to discover how we can help you put AI to work inside your own revenue systems.