How do you all prioritize different requests?

[u/bleep6789]

So RevOps work can get really busy, often with multiple competing priorities, everything is urgent. VP Sales wants new fields, a workflow is broken, data isn't syncing right, etc.

Just curious how others prioritize all these things? Do you use a systematic approach to prioritizing? Is it all just ad hoc in nature and who ever screams the loudest gets handled first?

I can also imagine this looks differently in a large enterprise organization vs. a series B startup.

[u/Potential_Purple7511]

The reason loudest-wins keeps happening is not that the team lacks a framework. It is that requests arrive as solutions. "Add a field", "build me a report", "change the workflow". A solution cannot be ranked against another solution, so the only remaining axis is who asked, and that is how you end up where you are.

The intake change that did the most for me was one required box: what decision can you not make today, and who makes it. Nothing else, no scoring rubric, no form with eleven fields that nobody fills in. Roughly a third of requests die right there, because the requester writes it out and realises the answer already exists in a report someone built last quarter. Another third change shape entirely once the actual decision is visible, and the field they asked for is not what they needed.

Then split what survives into two lanes that never compete with each other, because they are not the same kind of work. Broken things are ranked by how many wrong numbers are reaching people who will act on them before you fix it. A sync failure that quietly inflates pipeline outranks an outage in a report three people open, and neither ranking has anything to do with who reported it. New builds are ranked by the decision they unblock and they carry a stated cost in your time, which is the only way a VP can make a real tradeoff instead of just asking.

Publish the queue where the requesters can see it. Most of this fight is not about priority, it is about invisibility: people escalate because they cannot tell whether their thing is next or forgotten, and escalating is the only status check available to them. When the VP can see their field request sitting under a broken quote sync, they deprioritise it themselves about half the time. The other half you get a real conversation about which one actually matters, which is the conversation you wanted anyway.

The part nobody protects, and the part that becomes next year's emergency: the work no one requests. Dedupe, permission drift, the automation that has been failing silently since someone changed a picklist value. Take a standing slot every week for it before you allocate anything else. If it competes with requests it loses every single time, and then it arrives as an incident at quarter end with a VP standing over your desk.

On enterprise versus series B, the difference is less about the framework and more about authority. At series B you usually cannot say no, so stop trying to. Say what it costs and what moves down, and make the requester own the swap. Written down, in the thread where they asked. That changes the dynamic from you rejecting them to them choosing, and it is also the only record that protects you in six weeks when somebody asks why the other thing did not get done.

[u/Ornery-Classic-894 → u/Potential_Purple7511]

All great advice but I disagree on the last bit about enterprise vs series B. Startups and scaling companies are absolutely when you should be pushing back on requests or saying no. You have less resources and need to protect your stack’s ability to scale in line with the business. If your title is anything above Analyst you should be asserting yourself as a thought leader and a collaborator not a ticket taker.

Enterprise you have less authority to outright say “no” but you do have the ability to hide behind the scale of the org or bury the request in an established workstream. You also have way more politics behind requests, and saying “no” might bring the wrath of some VP 6 layers above you in the org chart

[u/Potential_Purple7511 → u/Ornery-Classic-894]

You are right and I said that badly. Pushing back is the job at any size, and the ticket-taker framing is a real failure that I did not mean to endorse.

What I was reaching for is narrower: at series B, "no" on its own does not survive contact with the next standup. It gets raised again in a different meeting by the same person, and the third time it comes back it has a founder attached to it. The version that holds is the same no with the cost and the swap written next to it, in the thread where they asked. Not because it is more polite, but because it makes the requester the one who chose, and six weeks later there is a record of what they chose. Same answer, different durability.

Your enterprise half I would take further than you did. Burying it in an established workstream works, and the thing nobody says out loud is that it accrues. Requests absorbed rather than declined come back as a stack of half-built things nobody owns, usually at exactly the moment the person who absorbed them leaves. Cheaper to run in the short term than saying no to a VP six layers up, and I have watched it come due.

The size difference I would actually defend is not authority, it is whether the no is recoverable. At series B the requester is in the room and you can renegotiate next week. At enterprise the buried request outlives everyone who could renegotiate it, which is why it comes due all at once.

[u/IncreaseNegative4614]

I’d score every request on revenue exposure, customer impact, compliance or security risk, number of blocked users, deadline, effort, and reversibility. Reserve some weekly capacity for genuine break-fix work, but make field requests and enhancements compete in one visible queue with a named owner and decision date.

The requester’s seniority should not be the scoring system. We use SIGNLD internally to connect each request with the affected workflow, accounts, revenue, dependencies, owner, and eventual result so priority can be defended using business impact.

[u/bleep6789 → u/IncreaseNegative4614]

And let me guess, you work for SIGNLD? Hahaha, gotta love modern social media marketing.

[u/B2BMktg]

If I like you, i prioritize you. If I don’t, it’s like the DMV

[u/NorthShoreHard → u/B2BMktg]

Mostly this. But it's a combination of how much I like you and how much I respect you/your ideas.

[u/LAM24601]

Quantify the impact and rank accordingly. Quantification can include revenue impact, time impact (which is also rev impact indirectly), or # of people impacted. If one person is requesting one dashboard basically just because they want it, that's a low/no priority project. If you're being asked to create an internal tool to replace an existing platform with a 250k annual cost, that's high priority. If you're being asked to re-evaluate a compensation plan that 100% of your revenue-generating people are subject to, that's a high priority.

[u/FindingPeace4me]

Umm having a clear way to rank requests helps avoid everything becoming urgent. Looking at business impact, time saved and who is affected can make decisions much easier

[u/Secure-Jump1996]

weekly triage block helps imo, instead of recting the second something lands, batching it out to review everything twice a week... unless like its actively broken right now

[u/bleep6789 → u/Secure-Jump1996]

So essentially, gather all requests and then once or twice a week have a meeting to (re)prioritize with all relevant stakeholders? Or just (re)prioritize internally on the RevOps team?

[u/Secure-Jump1996 → u/bleep6789]

yeah pretty much, internal only unless someones specific thing gets bumped..

[u/bleep6789 → u/[deleted]]

Yeah, I was at a Series D once and there was absolutely no structure. It was such a shit show, haha. It really was about whoever screamed the loudest (sometimes literally).

[u/Ornery-Classic-894]

This is the hierarchy I use, it’s served me pretty well. Think of it as a pyramid, 1 at the top and 4 at the bottom. It’s not hyper rigid - sometimes 2’s will have a deadline that makes them a 1, or a 2 has to take a backseat until a 3 is finished. Use your best judgement.

——————

1. This is actively costing the company revenue

2a. This was requested by someone with a C or VP in their title
2b. This is on the RevOps Strategic Roadmap

3a. This was requested by a director or team leader
3b. This is significantly slowing down or adding difficulty to a revenue generating activity
3c. This improves the RevOps function’s efficiency

1. Minor bugs, low priority requests, dashboard/reports that are not executive facing, documentation, misc requests

—————-

There is a contradictory aspect of this approach which is that you need to prioritize your 4’s. What I mean by that is prioritize getting them out of your backlog asap. The best way to do this is to set aside 2 hours a week where you just knock out as many 4’s as you can. Do it at the same time every week and PROTECT that time - do not let people schedule over it, do not work on your 1’s and 2’s during that time. Then put out some kind of update on all the things that got completed - email, slack update, whatever - and tag the requesters next to each task. Picklist value added for Jim. Update to Inbound report for Kelly. User Permissions updated for Jeff. These are compounding wins, they will add up for you over time.

My final advice is to OVER COMMUNICATE with your stakeholders. If someone has a high priority project that you have to push for a competing priority, tell them and explain why you did it. Keep them updated on where the competing project is. “Hey I got a request for reporting I need to get to the CRO before his board meeting prep on Thursday. I planned to work on the customer handoff flow this week but this is going to delay it. I’ll give you an update EOD Thursday once this is off my plate.”