How to Run a RevOps Intake Process

What is a RevOps intake process?

One door for every request that reaches the revenue operations team, with a written record attached to each one.

Without it, work arrives through direct messages, hallway conversations, and whoever finds the analyst first. Three consequences follow. The team cannot report on what it did, priority goes to the most persistent requester, and the same report gets built four times for four people who did not know the others had asked.

Intake is not a bureaucracy exercise. It is how a small team facing an unlimited request surface decides what to do with the week.

What should the intake form ask?

Five fields, and they should be hard to answer without thinking.

- What decision does this support, and who makes it? - What happens if this is not done? - When is it needed, and what drives that date? - Which systems or reports does it touch? - Who signs off that the result is correct?

The first question is the most valuable one in the process. A meaningful share of requests dissolve when someone has to name the decision behind them, and every request that dissolves at the form is capacity returned to work that matters.

Keep the form short. A 15-field intake form produces the behavior you were trying to eliminate, because people route around friction and go back to direct messages.

How should requests be tiered?

Four tiers, with a published response commitment for each. The line between analysis and project is where most intake processes fail. An analysis request that quietly turns into a three-week build consumes the capacity reserved for everything else. Set a size threshold, and when a request crosses it, it goes back through triage as a project.

Who decides priority?

One named decider, in a weekly triage, working from the queue.

Requesters do not set their own priority. When they do, every request is urgent and the queue orders itself by who follows up most aggressively. The RevOps lead runs a 30 minute weekly triage, assigns tier and owner, and publishes the result where requesters can see it.

Publishing the queue is what makes this survivable. A requester who can see that their dashboard change is fourth in line behind a broken forecast sync usually accepts the order. A requester who hears nothing escalates.

How much capacity should be protected?

Split the week explicitly, and publish the split.

A reasonable starting structure is three days for planned work that supports the roadmap and two days for the queue, adjusted from your own history. The exact ratio matters less than the fact that it exists and everyone knows it.

Two things break when capacity is unmodeled. Roadmap work never ships, because the queue always feels more urgent. And the queue itself develops a backlog that people learn to bypass, which returns you to direct messages within a month.

Track how much of the week actually goes to unplanned work. When it consistently exceeds the reserve, the problem is upstream. Recurring break/fix volume usually points at a data or process defect worth fixing permanently rather than absorbing weekly.

Which requests should be answered with a definition instead of a report?

A large share of intake is the same metric requested in different shapes.

The clearest example is a metric asked for by three teams with three different denominators. Sales wants win rate counted on closed opportunities, marketing wants it counted from qualified leads, and finance wants it dollar weighted. Building three reports guarantees three numbers that disagree in the next leadership meeting.

Publish a metric definitions document, route definition conflicts to it, and treat a change to a definition as its own request with an approver. That single move removes a recurring category of intake permanently, and it does more for reporting trust than any dashboard rebuild.

The same principle applies to ad hoc analysis. Analysis is the highest value use of an LLM in a revenue team, and the gap is trust and traceability. If a number cannot be traced back to its source, validating it costs as much as producing it from scratch, which is why definitions and a semantic layer matter more than the interface asking the question.

How do you know the intake process is working?

Four measurements, reviewed monthly.

- Median cycle time by tier, which should be stable rather than fast. - Share of work that arrived through intake rather than side channels, which should climb toward all of it. - Rework rate, meaning requests reopened because the output missed the need, which points at weak intake questions. - Backlog age by tier, which shows whether the capacity split is honest.

Add one counterintuitive measure. Track requests withdrawn after submission, and treat a rising rate as a success. It means the form is making people confront the decision behind the request, and requests without decisions behind them are the cheapest work you will ever avoid. That reclaimed capacity is what lets the team work on the things that change revenue, including the sales forecasting infrastructure everyone depends on and nobody submits a ticket for.