SDR → AE Handover Assessment

The documentation describes the what, not the how.

Based on the documentation provided, the business process appears relatively mature, with defined ownership transitions, qualification criteria and governance controls. My concern is not the process design itself, but the limited visibility into how it is implemented across the Revenue Systems ecosystem. Today the documentation does not yet explain:

As a result, any future change carries risk, because its full impact cannot be understood before it is implemented, which reduces the organisation’s ability to innovate safely.

What questions would you have on this process?

These questions are not a checklist, they form a structured way to make change safe. Before recommending anything, I would establish how the process actually runs, in three moves.

The eight areas that follow are how I would put this framework into practice, beginning with governance and ownership, and ending with the controls that keep change safe over time.

How would you fully document what’s happening in the systems?

I’d treat this handover document as Layer 1 of a five-layer model, and build the rest as living artifacts, not a one-time document. A process this interconnected goes stale within a quarter if the documentation is static.

Built by reverse-engineering Salesforce metadata, Flows, validation rules, LeanData config, cross-checked by shadowing 2–3 SDRs and AEs. The metadata shows what is configured; shadowing shows what people actually do, and that gap is where the documentation needs to live.

How would you take this forward, innovating without breaking what’s in place?

The core idea: make the blast radius of any field or automation visible up front, then move fast on low-risk items, and gate the high-risk ones with a regression safety net.

What would you improve first, and what are the risks?

Sequenced deliberately, earn trust on something low-risk before touching anything that affects how people get paid.

Impact × Complexity

How the roadmap is sequenced: high-impact, low-complexity work earns trust and baseline data first, the complex, comp-critical rebuild is a planned major bet, never a quick edit.

How would you keep RevOps and its partners aligned on interconnectivity?

Six practices keep the picture shared, so cross-functional teams understand how the system connects before change happens, not after.

Traceability Matrix

One row per process step, mapping it to the objects, fields and automations that implement it, and the systems downstream that depend on it. Makes “what’s happening” queryable instead of tribal knowledge.

Attribution Decision Table

The SAA attribution rules rebuilt as explicit conditions → outcome. Each row is a test case, and the shared artifact that settles “why did X get the credit?” before it becomes a payout dispute.

Field-Level Data Dictionary

Every field the process touches: its type, system of record and the teams that consume it — so any change surfaces its full blast radius before it ships.

Ownership Matrix

A named owner and approver for each layer of the model, with a review cadence. Removes the “who decides this?” ambiguity that lets change slip through ungoverned.

Dependency Matrix

Reads as “if I change this field, what breaks?” — each row a field, each column a downstream system. The visible map of interconnectivity that makes blast radius obvious before a change.

Architecture Repository

A single indexed home for the artifacts above — versioned, owned and searchable, so the system of record for “how Revenue Systems works” is one place, not scattered across decks and tribal memory.

Automation Inventory

A register of every automation that touches the process — what it is, what fires it and what it does. The list you need before you can safely change any rule, because you can see what else reacts.