Borrow the engineering harness for revenue (L3)
When engineering has AI tooling and revenue does not, the blocker is rarely appetite. Engineering already cleared vendor review with tools like GitHub Copilot, Cursor or Claude Code, wrote the data policy, and learned the procurement path, so copying their paperwork removes roughly two months from your timeline and costs one meeting. Strongest at 200 to 5,000 employees, software and technology-forward services, where engineering adopted AI tooling 6 to 18 months before the revenue org.
The steps
- 01
Book 45 minutes with the engineering leader who owns their AI tooling
Tool: Confluence
Frame it as borrowing, not asking permission. Bring five questions: which tools got approved and which got rejected, what did legal require before signing, what does your AI usage policy actually say, who signs off on a new AI vendor, what broke in your first 90 days. Ask for links to the real documents rather than a summary. • Owner: RevOps lead • Tool options: a calendar invite with an agenda attached, and their Confluence or Notion space open • Pitfall or what breaks: running this as a favor request instead of a copy job, so you leave with encouragement and no documents. • Definition of done: you have the approved-vendor list, the signed policy document, the procurement checklist, and the name of the person who signs.
- 02
Copy the four artifacts and change only the examples
Tool: Confluence
Duplicate their AI usage policy, their data-handling rules, their vendor-review checklist and their approved-tool list. Change the examples to revenue examples: customer PII in a CRM record instead of proprietary source code, unreleased pricing instead of unreleased architecture. Keep the structure, the definitions and the escalation path identical. Send it to legal as a redline against a document they already approved, which is a 3-day review instead of a 6-week one. • Owner: RevOps, reviewed by legal • Tool options: Notion or Confluence, wherever their originals live • Pitfall or what breaks: rewriting the structure from scratch instead of redlining an already-approved document, which resets the review clock. • Definition of done: legal signs off, and the revenue version is published beside the engineering version.
- 03
Use their procurement path for your own assistant seats
Tool: Claude Code
Ask procurement whether the existing agreement can be expanded rather than opening a new vendor record. An expansion is a form; a new vendor is a security review, a DPA negotiation and a queue. Buy 10 to 25 seats monthly. • Owner: RevOps plus procurement • Tool options: the same vendor if possible; if engineering runs Copilot on the Microsoft stack or Claude Code, the same vendor's business tier often falls under an existing MSA • Pitfall or what breaks: opening a brand-new vendor record when an expansion of the existing MSA was available. • Definition of done: seats are live under an existing or expanded agreement, with the DPA already on file.
- 04
Borrow the review discipline, not just the tools
Tool: Confluence
Engineering has one habit revenue teams almost never have: nothing AI-generated ships without a second human reading it, and the reviewer is named in advance. Copy that exactly. Write down, per workflow: who reviews, what they check for, and what gets rejected outright. Then borrow their second habit, a written record of what the AI got wrong, kept in the open. Engineering calls this a postmortem. Keep yours in the same Confluence or Notion space so it is visibly the same practice. • Owner: RevOps plus enablement • Tool options: their code-review norms, translated • Pitfall or what breaks: copying the tools and skipping this step, which gets you engineering's speed without engineering's review habit, the worst possible combination. • Definition of done: every AI-assisted revenue workflow has a named reviewer and a shared failure log with at least five entries.
- 05
Build the first integration with an engineer in the room
Tool: n8n
Pick the smallest genuinely useful integration and build it as a ticket in Jira or Linear, in their board, following their branching and review norms. A good first one: when an opportunity moves to a late stage, an assistant drafts the internal deal summary from the CRM fields and the last call note, and posts it to the deal channel for the AE to correct. Two rules borrowed from them: the workflow writes to a draft field or a message, never directly to a live CRM field on version one, and it logs every run, including failures, somewhere you can query. • Owner: GTM engineer or RevOps analyst, paired with one volunteer engineer • Tool options: Zapier, Make or n8n into Salesforce, HubSpot, Dynamics, Pipedrive or Zoho, with output landing in Slack or Teams • Pitfall or what breaks: writing directly to a live CRM field on version one instead of a draft field or message. • Definition of done: the integration has run 50 times, failures are visible in a log, and one engineer has reviewed the build.
- 06
Add revenue to their existing AI review forum
Tool: Slack
Do not create a parallel AI governance committee. Get a standing 10 minutes in the forum that exists. Bring the same three things every time: what we shipped, what it cost, what it got wrong. Sharing the forum keeps one approved-vendor list instead of two competing ones, which is the failure that quietly costs the most. • Owner: RevOps lead • Tool options: whatever recurring meeting engineering already runs on AI tooling • Pitfall or what breaks: starting a second, parallel governance committee that maintains a competing vendor list. • Definition of done: revenue has presented in that forum twice, and the vendor list is maintained in one place.
- 07
Instrument the result
Track days from "we want this tool" to "it is live," measured before and after. That number is what you actually borrowed. • Where it breaks: it gets run as a favor request instead of a copy job, so you leave with encouragement and no documents; or you copy the tools and skip the review discipline step, getting engineering's speed without engineering's review habit; or engineering's policy is genuinely stricter than revenue needs and you inherit friction that does not apply, in which case negotiate the specific clause rather than starting over. • Visual guidance: a swimlane with engineering on top and revenue below, and four labeled arrows crossing down: vendor list, policy, procurement path, review ritual. Date-stamp the engineering lane earlier to show the head start you are collecting.
Tools in this playbook
Next playbooks
Unfamiliar terms are defined in the AI and Revenue Dictionary. Related frameworks live in the framework library.