The problem in revenue operations
Revenue teams adopted AI early and unevenly. Some reps paste a company name into a chat assistant and get a confident summary of its strategy. Others use the CRM’s built-in assistant to write call notes. A few have tried tools that draft outreach. RevOps, who own the CRM and the forecast, see the side effects: a brief that cited last year’s funding round as news, a stakeholder field filled with someone who left the company, an email that quoted a “recent announcement” nobody can find.
The useful work is real. Account research before a call is repetitive. Updating the CRM after a call is the job everyone postpones. But two things have to hold before you scale it: every claim about an account has a source, and nothing reaches a customer or the forecast without a person approving it.
What the work involves
Source-backed account briefs. We design one brief template for your sales motion: company context, recent events, current relationship from the CRM, open opportunities, known stakeholders and suggested questions. Every factual line carries a source and a date. Anything the model infers (“likely evaluating vendors because they posted a platform-engineering role”) is labelled as an inference so the rep treats it as a question, not a fact.
The CRM update review queue. After a call, the assistant reads the rep’s notes or the approved transcript and proposes changes: next step, stakeholders mentioned, risks, a suggested close-date change. Proposals land in a queue. The rep or RevOps accepts, edits or rejects each one, and the decision is logged. Rejection reasons tell us where the rules need tightening.
The permission matrix. This is the control document. It lists CRM objects and fields, and for each says whether the assistant may read it, propose a change, or never touch it. It also lists external sources that are allowed and those that are not. It follows the principle I have published as the Substrate Pattern: decide in advance what an AI system can do, and put approval at the boundaries that matter.
The signature deliverable
You end with a source-backed account brief, a CRM update review queue and a permission matrix. Illustrative example of a permission matrix extract:
| Object / field | Read | Propose change | Write without review |
|---|---|---|---|
| Account: industry, size, website | Yes | Yes | No |
| Opportunity: next step | Yes | Yes | After pilot, if approved |
| Opportunity: amount, stage, close date | Yes | Yes | Never |
| Contact: personal notes, sensitive attributes | No | No | Never |
| Email / sequences | No | No | Never: people send messages |
Illustrative example. The rules are set with your RevOps owner.
How acceptance is judged
Before the pilot, we sample current account briefs and recently updated opportunities for accuracy and completeness. During the pilot we sample again the same way. The measures are:
- unsupported or wrong claims per brief, checked against sources
- share of proposed CRM updates accepted unchanged, edited and rejected
- completeness of key opportunity fields after calls
- rep time on call preparation, by their own log for a sample week
The RevOps owner accepts the pilot. The adoption measure is whether the pilot reps keep using the brief and queue unprompted, and whether the forecast meeting trusts the fields more.
Ownership and handover
RevOps owns the template, the matrix and the queue rules. I pair with a named RevOps analyst throughout so they can change the brief, add a field to the matrix or retire a rule. The handover note covers the sampling method so the accuracy check keeps running.
Boundaries
This is staff enablement for research and CRM hygiene, not outbound automation. If you need a broader integration between CRM, billing and support systems built and maintained, use AI workflow automation and systems integration. If your marketing team is preparing research and content for campaigns, see AI enablement for marketing teams. For reconciliation work between operational systems, see AI enablement for operations teams.