You've decided you need senior RevOps leadership. You're not ready for a full-time VP hire. You bring in a fractional leader.

Day one arrives. What actually happens?

Not a 90-day "listening tour." Not three months of stakeholder interviews that produce a slide deck nobody acts on. Not a reorganisation of your Salesforce dashboards.

A senior fractional RevOps leader should produce tangible architectural change within 90 days. Not recommendations. Change.

Here's the playbook I run. It's been refined across dozens of engagements from Series A startups to scaling public companies. The specifics vary. The structure doesn't.

Before Day One: The Scoping Conversation

The engagement starts before the clock does.

A good fractional leader will ask hard questions before accepting the work. Not because they're difficult. Because the answers determine whether the engagement can succeed.

  • "Who sponsors this work?" — if RevOps reports to a VP of Sales, the scope is limited by that VP's priorities. If it reports to the CEO or CRO with a cross-functional mandate, the architectural work can actually happen.
  • "What's the real problem?" — companies say "we need better reporting" when they mean "our forecast is always wrong." They say "we need a CRM cleanup" when they mean "our pipeline governance doesn't exist." The surface request and the structural need are rarely the same thing.
  • "What's been tried before?" — understanding what failed, and why, prevents repeating the same mistakes with a different face.
  • "What does success look like at day 90?" — if the answer is vague, the engagement will drift. Specificity here protects both sides.

If these questions don't get clear answers, the engagement either needs to be restructured or it shouldn't happen. A fractional leader who takes the work without understanding the mandate is setting themselves up to be an expensive CRM admin.

Days 1–14: The Diagnostic

The first two weeks are about understanding reality. Not the version of reality on the slide deck. The version that exists in the CRM, in the handoffs, in the Slack channels, and in the workarounds people use because the official process doesn't work.

The data audit

Before you talk to anyone, look at the data. It doesn't lie.

  • Pipeline data quality: How many open opportunities have close dates in the past? What percentage of deals are missing required fields? How consistent are stage definitions across reps and teams?
  • Conversion analysis: Stage-to-stage conversion rates over the last four quarters. Do they make sense? If "Qualification to Proposal" is 90% but "Proposal to Closed Won" is 15%, deals are advancing without real qualification.
  • Forecast accuracy: Compare committed forecasts to actuals for the last four quarters. Where does the miss happen? Is it in the commit category? Upside? New pipeline that doesn't materialise?
  • Data completeness: What percentage of closed-won deals have complete attribution, accurate deal amounts, and correct contract terms? If it's below 80%, the reporting infrastructure is unreliable.

This takes two to three days. It tells you more about the state of revenue operations than a month of stakeholder interviews.

The process audit

Now talk to people. But with targeted questions, not open-ended "tell me about your challenges" conversations.

  • Walk me through the last three deals you closed. Step by step. Where did it originate? How did it progress? Where did it stall? What happened at handoffs? This reveals the real process, not the documented one.
  • Where do you spend time on things that feel like waste? Reps know where the friction is. They know which approvals are pointless, which reports nobody reads, which data entry requirements are theatre.
  • What happens when something doesn't fit the normal process? This is where you find the exceptions. And the exception pattern tells you where the governance breaks.

Talk to five to eight people across sales, marketing, CS, and finance. Not forty. You're looking for patterns, not consensus.

The tech stack audit

Map every system that touches the revenue process. CRM. Marketing automation. Billing. Contract management. Forecasting. Analytics. Compensation.

For each one, answer three questions:

  • Is this tool solving a real problem or does it exist because someone bought it two years ago?
  • Is data flowing correctly between this system and the CRM?
  • Could this tool be replaced by something simpler, cheaper, or custom-built?

By day 14, you should have a clear picture of: what's broken, why it's broken, and what's costing the most.

Days 15–21: The Architecture Document

This is where the fractional model earns its value.

A full-time hire spends weeks building internal consensus before recommending anything. A fractional leader has the independence to be direct.

The architecture document is not a strategy deck. It's not fifty slides with a vision. It's a concise, specific document that answers four questions:

  • What are the three to five highest-impact problems? Ranked by revenue impact, not by who complains loudest.
  • What's the root cause of each? Not the symptom. The structural root cause. "The forecast is wrong" is a symptom. "Pipeline stages have no enforced entry criteria, so conversion data is meaningless" is the root cause.
  • What's the fix? Specific. Implementable. Tied to existing systems where possible. Not "improve pipeline governance" but "implement stage-gate validation rules for stages 2–5, requiring documented exit criteria before advancement."
  • What's the sequence? What gets done first? What depends on what? What can run in parallel? This is the 90-day execution plan.

This document gets presented to the executive sponsor and the leadership team. Not for approval in the political sense. For alignment. If the diagnosis is wrong, this is where someone says so. If the priorities are off, this is where they get corrected.

If the leadership team can't agree on the top three problems, that disagreement is itself the most important finding of the diagnostic.

Days 22–60: The First Build Cycle

This is where things get built. Not designed. Not planned. Built.

The first build cycle targets the highest-impact problem identified in the architecture document. Typically, this falls into one of three categories.

If the problem is pipeline governance

The build:

  • Redefine pipeline stages with specific, verifiable entry and exit criteria.
  • Build validation rules in the CRM that enforce those criteria. Deals cannot advance without meeting the gate.
  • Implement a forecast methodology tied to the governed stages. Define what "commit" and "best case" mean in structural terms, not subjective judgement.
  • Build pipeline snapshots — weekly automated captures of pipeline state that create the longitudinal data needed for real conversion analysis.

Timeline: three to four weeks from decision to live in the CRM.

If the problem is data architecture

The build:

  • Lock field definitions and make critical fields mandatory.
  • Fix attribution tracking — ensure lead source, campaign, and channel data flows correctly from marketing automation to CRM to closed-won opportunity.
  • Build the reporting foundation: cohort retention, unit economics by segment, pipeline generation by source. The reports that leadership should be reviewing every week.
  • Clean the backlog — close stale opportunities, deduplicate records, standardise existing data against the new definitions.

Timeline: four to six weeks, depending on the severity of the debt.

If the problem is process fragmentation

The build:

  • Map the end-to-end revenue process from lead creation to renewal.
  • Identify the handoff points where data or context gets lost — marketing to SDR, SDR to AE, AE to CS. Build structured handoff requirements into the system.
  • Implement deal desk governance for deals that meet exception criteria — above a certain ACV, non-standard terms, heavy discounting.
  • Consolidate or eliminate redundant tools that fragment the process across disconnected systems.

Timeline: four to five weeks.

Notice the pattern. Every build cycle ends with something live in the system. Not a recommendation document. Not a process deck. A structural change that's enforced by the architecture.

Days 60–90: Measure, Adjust, Hand Off

The final thirty days are about three things.

Measure the impact

Whatever was built in the first cycle, measure whether it's working. Pipeline governance live? Track the exception rate. Data architecture fixed? Run the reports and check for gaps. Process consolidated? Measure the handoff completion rate.

Hard numbers. Not sentiment. Not "the team feels better about the forecast." Did the forecast accuracy improve? By how much? What's still off?

Start the second build cycle

The architecture document identified three to five problems. The first build cycle addressed one. Days 60–90 typically starts the second build — with the confidence and credibility earned from the first.

This is where the fractional model compounds. The diagnostic is done. The architecture is understood. The team knows how the engagement works. The second build is faster than the first because the foundation is in place.

Build the handoff plan

A fractional leader is temporary by design. The architecture they build needs to outlast them.

The handoff plan covers:

  • What's been built and how it works. Documentation that the internal team can maintain and evolve.
  • What's next on the roadmap. The remaining items from the architecture document, sequenced and scoped for the internal team to execute.
  • What capability gaps exist. Honest assessment of whether the internal team can sustain and extend the architecture, or whether ongoing fractional support is needed.
  • What to watch. Leading indicators that signal whether the changes are holding. Exception rates, data quality scores, forecast accuracy trends.

The goal is not to make the company dependent on the fractional leader. It's to build architecture that the company can operate independently.

What This Doesn't Look Like

Let me be explicit about common failure patterns in fractional engagements.

  • The 90-day audit. Three months of diagnosis with no execution. The output is a recommendations document. Nothing changes in the system. The company has paid for advice, not architecture.
  • The CRM project. The fractional leader gets pulled into Salesforce configuration tickets because the internal team is overwhelmed. The architectural work never happens because the operational demand absorbs all the capacity.
  • The politics trap. The fractional leader spends their time navigating internal disagreements between sales, marketing, and CS instead of building. If the executive sponsor can't clear the path, the engagement stalls.
  • The scope creep spiral. The engagement starts with pipeline governance but expands to comp plan redesign, territory modelling, tech stack consolidation, and a data warehouse migration. Everything is important. Nothing gets finished.

A good fractional engagement is narrow, deep, and fast. Fix one thing properly. Prove the value. Then expand.

How to Evaluate Whether It Worked

At day 90, the executive sponsor should be able to answer these questions:

  • What structural change now exists in our revenue operations that didn't exist 90 days ago?
  • Is that change enforced by the system, or does it depend on people remembering to follow it?
  • Can the internal team maintain and extend what was built?
  • Do we have a clear roadmap for the next 90 days?

If the answer to any of those is "no" or "I'm not sure," the engagement underdelivered. Either the scope was wrong, the mandate was insufficient, or the fractional leader spent too much time advising and not enough time building.

The Fractional Advantage

There's a reason this model works particularly well for revenue operations.

A full-time hire takes three to six months to ramp. They need to build relationships, understand the politics, establish credibility, and navigate the org chart before they can drive change. By the time they're ready to build, a quarter or two has passed.

A fractional leader arrives with pattern recognition from dozens of similar environments. They've seen the same problems at other companies. They know what works. They don't need six months of context because the patterns repeat.

The fractional model trades organisational depth for execution speed. In the first 90 days, speed matters more.

After 90 days, the architecture exists. The internal team can operate it. And the company knows exactly what "good" looks like when they're ready to make a full-time hire — because they've seen it in action.

That's the playbook. Not a listening tour. Not a strategy deck. Diagnose in two weeks. Design in one. Build for two months. Measure, adjust, hand off.

Ninety days. Structural change. That's the standard.