Day 1 begins by stopping the unsafe reservation path and naming the one decision the thirty-day route must repair. The retained result is a bounded charter, not a new department.
Write the RevOps Decision Charter
Begin with a decision people already argue about. Do not begin with an organization chart or a list of tools. If Sales uses Commit to express seller confidence while Operations uses it to reserve labor, write down both uses and the consequence before proposing an owner.
Research on data decision rights separates distinct decision domains instead of assuming one universal owner (Khatri & Brown, 2010). A decision domain is a bounded class of decisions assigned to one qualified owner. A RevOps Charter applies that principle to a small set of cross-functional decisions. It states who decides, whose specialist approval is required, who implements the choice, where it takes effect, and how it can be challenged or changed.
Start With Costly Disagreements
Collect three to five recent cases. For each one, capture:
- the exact decision that stalled or produced rework;
- the records and definitions each party used;
- the person currently making the decision in practice;
- the customer, financial, capacity, compliance, or reporting consequence; and
- the smallest shared rule that would make the next case resolvable.
Include a decision only when ambiguity has a material cost. Common candidates are handoff acceptance, lifecycle states used in executive reporting, identifiers needed for reconciliation, a shared metric, forecast eligibility, the authority for a contested fact, and approval of a temporary exception. Leave local preferences with their local owner.
Write exclusions with the same care as scope. A default charter may exclude go-to-market strategy, offer and price choices, sales methodology, compensation, customer-success practice, legal conclusions, accounting policy, privacy, security, and commercial targets. RevOps may carry data or configure a workflow for any of those decisions without owning the decision itself.
Assign One Owner Per Decision
A shared rule needs one final owner. Choose the arrangement that fits the decision:
- Central owner. RevOps or another cross-functional owner decides and publishes the rule. Use this when several workflows genuinely need one definition and the owner has authority to resolve the trade-offs.
- Domain owner with a maintained interface. Sales, Operations, Finance, Legal, or another specialty owns the decision; RevOps maintains the mapping, record, or publication method. This is the usual pattern for specialist conclusions.
- Split approvals with one escalation owner. Named owners approve separate parts and one executive resolves deadlock. Use it only when a decision truly combines material authorities.
Avoid labels such as partner or shared owner unless the record also says who closes the decision. Name the decision owner, required contributors, specialist approver, implementer, steward, and escalation owner. In a small company one person may fill several roles, but each role still carries a different duty.
Tool access is not authority. An analyst can implement a validation rule owned by the Sales director. An engineer can encode a Finance policy. The release record must retain the owner who approved the rule, the person who implemented it, the effective date, the test result, and the reversal path.
An owner can be accountable for publishing a current definition, applying an approved change, monitoring its operation, and resolving cases within an agreed response time. That owner cannot guarantee growth, retention, forecast accuracy, or factual correctness when customers, markets, and other decisions also determine the outcome.
Publish a Bounded Record
The minimum charter row for each decision is:
| Field | What to record |
|---|---|
| Decision | The exact rule or policy question |
| Business use | The decision, report, or handoff that depends on it |
| Decision owner | The role with final authority |
| Required contributors | Domain experts or affected owners who must be consulted or approve a specialist conclusion |
| Executor and steward | Who implements the rule and who monitors it |
| Enforcement point | The policy, field, workflow, calculation, or review where the rule takes effect |
| Exception path | Who can approve a deviation, for what scope, and until when |
| Change path | Who may propose, approve, test, publish, and reverse a revision |
Add the current conflict, affected records, consequence, effective date, review date, and version. A chief executive or delegated sponsor resolves assignments that cross existing authority. If no authorized person will own a consequential decision, stop; a workflow cannot solve an executive ownership gap.
Track a few operating facts: rules without current owners or versions, handoff rejections by reason, open exceptions by age and exposure, unexplained reconciliation differences, and elapsed time from approval to verified release. They show whether the decision path is usable. They do not prove that RevOps caused a commercial result.
If the same team owns a performance target and the definition used to report it, require independent approval for a material definition change and preserve the prior result under the old definition. This prevents an optics-driven edit from rewriting history.
HarborWorks: Three Decisions, Three Owners
HarborWorks separated three decisions that Commit had collapsed:
- The Sales director owns inclusion in the commercial Commit view.
- The founder owns whether an agreement is executed under the counsel-approved signature policy.
- The Operations director owns acceptance of service intake and the decision to reserve technicians.
The operations analyst maintains the fields, mappings, and tests. Finance owns accounting conclusions and the receivable records. One commercial label no longer grants authority over the other decisions.
Conclusion and field test
Run one real disagreement through the charter. Without inventing an answer in the meeting, identify the owner, required evidence, effective record, permitted exception, escalation deadline, and revision path. Then ask each domain owner to name one consequential decision deliberately left outside the charter. Failure on the first test means the charter is incomplete; failure on the second means it has absorbed too much authority.
The RevOps Charter makes a decision domain executable by fixing its authority, evidence, boundaries, and change path.
Chapter glossary
- Decision domain: A bounded class of decisions assigned to one qualified owner.
- RevOps Charter: The record of ownership, specialist approvals, implementation, effect, challenge, and change for selected cross-functional decisions.