Our account executives were spending about 50 minutes a day on Salesforce admin. They now spend about 5. Field compliance on our enterprise pipeline went from 38% to 98%. I built two Agent Skills that read every call, email, and calendar invite on an account, propose the CRM updates, and then wait for the rep to approve them.
Where the problem came from
After we invested in our GTM agent, our SDR team got better at booking meetings—and did so faster than we had planned. That is a good problem until it lands downstream. Each AE ended up carrying more than 35 open enterprise opportunities. Enterprise deals do not compress. Every opportunity needs discovery, a champion, technical validation, and a decision from someone who controls the budget.
I turned my focus to this critical bottleneck in our sales funnel. We needed to give our AEs more time to spend with customers.
After auditing how AEs worked and identifying the most automatable opportunity, a pattern emerged: AEs were spending between 45 and 90 minutes a day manually updating Salesforce.
Wingspan already tracked everything needed to keep Salesforce current somewhere in our systems: call recordings, dialer logs, email threads, and calendar invites.
Rather than ask them for more hours, I wanted to strip out the part of the job that does not need a person, so the hours they already had went to customers.
What I built
I built two Agent Skills that share one set of rules. The first works a single account in depth. It assembles a validated account dossier of everything we know about that account, compares it against what is currently in Salesforce, and produces a proposed diff.
The second runs the rep's entire book overnight, fanning sub-agents out per account in waves so it covers every open opportunity instead of a sample.
Between them, they propose deal qualification fields, stage milestone dates, contacts who showed up on a call but never made it into the CRM, contact roles, next steps, follow-up tasks, and renewal opportunities. Every proposed value carries the quote it came from and the date, so a rep can check the agent's work in a couple of seconds.
Why I wrote it as Agent Skills
The whole system is Markdown instructions and reference files. There is no application code or vendor SDK involved, and I did not fine-tune anything. That keeps it model agnostic: when a better model ships, the skill can run on it the next day, and I do not have to migrate anything.
It had a second effect I did not anticipate. The people who own the sales process can read the logic and argue with it. Our CEO has filed pull requests against it.
Four critical decisions
The agent never writes on its own
Asking it to update Salesforce produces a proposed diff. Applying that diff takes a second approval, given explicitly after the rep has read what the agent wants to do. Reps will adopt a tool that cannot quietly overwrite their work, and I think that constraint is the main reason this one gets used.
Risk escalates with the proposed change
The skill sorts every proposal into one of nine categories that escalate by how much damage a wrong one would do, from filling an empty field through advancing a stage or closing a deal. It requires confirmation item by item for the dangerous ones.
Both skills share one source of truth
Both skills load one shared set of reference files instead of keeping their own copies. I learned that the hard way. The nightly skill drifted from the single-account skill within weeks and quietly lost the next-step quality check, duplicate contact-role detection, and renewal creation.
Judgment stays with the rep
Our sales process has eight stages with documented exit criteria. The agent confirms the criteria that are verifiable from records. When something rests on a verbal commitment or a read on buyer intent, the agent marks it for the rep to confirm and leaves it alone.
Getting from working to trusted
Four months and roughly 50 tracked issues separated the first working version from the one the team trusted.
I opened a Slack channel for the project and put a standing 30-minute morning meeting on the calendar with the two pilot AEs, Armeen Davoodi and Ryan Mitchell. I kept it until the system was reliable.
None of that happens if reporting a problem is expensive. Reporting one meant typing a sentence into the same Claude session where the problem showed up, and a separate skill turned that sentence into a scoped Linear issue with the account, the run, and the record IDs attached. I also gave our cloud coding agent access to the repository, so an issue could become a pull request without me in the middle. I wrote 24 graded evaluation cases covering approval safety and evidence handling, which kept the fixes from regressing.
Where it landed
Field compliance on the enterprise pipeline moved from 38% to 98%, and daily Salesforce admin per AE dropped from about 50 minutes to about 5. It runs unattended overnight across every open opportunity, and it went from two pilot reps to the whole AE team, then to the whole 20-person GTM team.
It also found problems the old process never caught: duplicate contact roles, deals a prospect had already killed that nobody had closed, and opportunities sitting behind their own call activity.
What I would do the same way again
Embed with the people doing the work, as deeply as you can stand. The standing morning meeting was the most useful thing I did on this project, and it was the least technical.
Then make reporting a problem free. If it takes a form, a screenshot, and a context switch, nobody reports anything, and you conclude the system is fine.