How to build a RevOps charter the executive team will actually sign

Do not draft the charter alone in a doc and then shop it. That path produces a document that reads clean on page one and dies in the first VP review because nobody who signs it feels heard. Instead, run a 30-minute interview with each of the five signers plus two or three frontline managers inside Sales, Marketing, and CS. Ask the same four questions in every interview: what do you expect RevOps to own, what is the single most painful request you have had to escalate in the last 90 days, where do you think RevOps is overreaching today, and what would make you comfortable signing a one-page charter. Capture the raw answers in a shared memo. The patterns across the interviews, especially the places where two VPs want the same work owned by different teams, are the real material the charter has to resolve.

• Run a 30-minute interview with each of the 5 signers plus 2-3 frontline managers
• Ask the same four questions every time so the answers are comparable
• Capture raw quotes in a shared memo, not just your paraphrase
• Flag every conflict where two leaders want the same work owned by different teams

A charter that runs longer than one page stops being a charter and becomes a strategy memo nobody reads. Lock the template to seven sections and keep the whole document to roughly 400-600 words. Section one, mission, is a single sentence on what RevOps exists to do. Section two, scope, lists in bullets what RevOps owns end to end. Section three, out of scope, names in bullets the work that is explicitly not RevOps, which is the single most important section in the whole doc. Section four, reporting line, names the executive RevOps reports to and the cadence of that one-on-one. Section five, decision rights, uses a short RACI-style grid for the five or six calls that would otherwise block the team. Section six, service levels, lists the response and resolution SLAs for stakeholder requests by priority. Section seven, review cadence, commits the team to an annual review and names the trigger for an off-cycle update.

• Lock the template: mission, scope, out of scope, reporting line, decision rights, SLAs, review cadence
• Keep the whole document to one page and roughly 400-600 words
• Write out of scope in the same voice and length as scope so the no is as visible as the yes
• Draft the decision-rights grid last, because it will absorb the most redlines

The scope and out-of-scope sections are where RevOps charters live or die. Write them in parallel so a reader can scan both and see the line clearly. In charter for most B2B teams: CRM administration and data model, pipeline hygiene and forecast cadence, territory and quota design, lead routing and SLAs, commission plan administration, revenue reporting and dashboarding, sales tech stack ownership, and funnel analytics across marketing, sales, and CS. Out of charter, written in the same bullet form: individual rep coaching, marketing campaign execution, CS playbook authorship, pricing strategy, product roadmap input, and ad-hoc one-off reports that bypass the intake queue. The hardest conversation in the charter review will be a VP arguing that an out-of-scope item should move to in-scope. Hold the line unless the VP is willing to trade something out, because scope creep without a trade is how RevOps teams end up with 18 priorities and zero of them delivered.

• Write scope and out-of-scope as parallel bullet lists in the same voice
• Name the 6-10 big in-scope areas by function, not by one-off task
• Name the 4-8 highest-friction out-of-scope items that stakeholders routinely ask RevOps to do
• Add a one-liner for how out-of-scope requests get routed instead of silently queued

RevOps reports to one executive, not three. The two patterns that work are RevOps reporting to the CFO (when the primary pain is forecast accuracy and commission integrity) and RevOps reporting to the CRO or COO (when the primary pain is pipeline execution and go-to-market scale). Pick one, name it in the charter, and commit to a weekly one-on-one with that executive. The decision-rights grid is a short RACI table that names, for each of the five or six highest-friction calls, who is accountable, who is consulted, and who is informed. Typical calls to pin down: territory assignment changes, pipeline stage definition changes, quota setting, CRM required-field changes, commission plan exceptions, and the quarterly forecast call sequence. Without the grid in writing, every one of these decisions re-litigates every quarter and RevOps burns a week of calendar time per cycle on political work.

• Pick one executive reporting line: CFO (forecast focus) or CRO/COO (pipeline focus)
• Commit to a weekly one-on-one with the named executive and keep the cadence
• List the 5-6 highest-friction cross-functional calls that need a decision owner
• Pin accountability for each call to a single named role, not a committee

Stakeholders will try to make every request urgent. The SLA table says in writing which requests get what response time and what delivery time, broken into three tiers. P0 is a revenue-blocking incident, like a broken forecast or an SLA-violating lead routing outage, and gets a same-day acknowledgment and a 24-hour resolution target. P1 is a cross-functional priority, like a new territory rollout or a quota reset, and gets a two-business-day acknowledgment and a two-week delivery target. P2 is a standard improvement request, like a new dashboard or a new required field, and gets a five-business-day acknowledgment and a scheduled delivery date out of the intake queue. Name the intake channel for every tier, and route every informal Slack ask through it so the queue is visible. A visible queue is the single best defense RevOps has against being treated as a help desk.

• Define three tiers (P0, P1, P2) with explicit acknowledgment and delivery SLAs
• Name the intake channel for every tier and route Slack requests through it
• Publish the current queue in the charter home space so backlog is visible to stakeholders
• Reserve 20 percent of weekly capacity for P0 so the team is not perpetually behind

Draft reviews should run one-on-one with each signer, not as a round-table working session. Round-tables surface the loudest objection and bury the real concerns. Walk the draft with the signer who has the most skin in the game first, usually the VP of Sales, and resolve their redlines before the second signer sees the draft. Then move to the VP of Marketing, VP of CS, Finance, and finally the CEO, in that order. Each review is a 45-minute working session in which you read the draft out loud together, capture every edit in a single tracked-changes pass, and commit to a short list of follow-ups before the next signer sees the doc. The CEO review happens last because by then the four function VPs have signed off and the CEO's job is to confirm the executive-level framing, not to re-litigate scope.

• Walk the draft one-on-one with each signer, 45 minutes each, in hardest-first order
• Capture edits in a single tracked-changes pass per signer, not scattered threads
• Resolve each signer's redlines before the next signer sees the doc
• Save the CEO review for last so function VPs are already on the record

A signed charter in a shared drive nobody opens is the same as an unsigned charter. Collect the five signatures in the charter itself (electronic signature is fine) and publish the signed doc somewhere every stakeholder can find it in two clicks. The home page of the RevOps internal space is the right spot. Link to the charter from the RevOps intake form, from the pinned message in the RevOps request channel, from the first page of every onboarding plan for new sales and marketing leaders, and from the agenda doc for the weekly revenue leadership meeting. The point is not that stakeholders will read the charter every day. The point is that when someone argues RevOps should do something that is out of scope, the charter is one link away and the conversation ends in 30 seconds instead of 30 minutes.

• Collect all 5 signatures (Sales, Marketing, CS, Finance, CEO) in the charter itself
• Publish to the RevOps internal home page with a stable URL
• Link to the charter from intake forms, Slack pins, onboarding plans, and the revenue leadership agenda
• Announce the signed charter in the weekly revenue leadership meeting, not just by email

The charter has to be a living doc, not a founding artifact. Lock in an annual review on the same month every year, usually one month before the fiscal planning cycle starts so the charter informs the plan instead of lagging it. Each annual review re-walks the charter with the same five signers, pulls the last 12 months of SLA data and intake queue stats, and updates the scope, out-of-scope, decision-rights, and SLA sections to match what has actually changed. Name the off-cycle triggers in the charter itself: a change in the executive reporting line, a merger or acquisition, a product line change that reshapes the go-to-market motion, or a new VP taking over Sales, Marketing, or CS. Any of those triggers an immediate review, not a wait until the next annual cycle, because the signatures on the charter are tied to the leaders who signed it and a new VP has to co-sign to carry the authority.

• Schedule the annual review one month before fiscal planning so the charter informs the plan
• Pull 12 months of SLA data and intake queue stats before the review session
• Name the off-cycle triggers (reporting change, M&A, product line change, new VP) in the charter
• Require any new VP who takes over Sales, Marketing, or CS to co-sign the current charter