Operational Excellence Without Bureaucracy: Building the Muscle to Maintain What You've Built

There's a lot of excitement around building things in Revenue Operations, some chosen by us as operators, some requested by the business. And we usually love the challenge and dive straight into building. I think that says a lot about the RevOps profile overall, but that's a story for another day.

The thing is, whatever gets built needs maintaining. And it often just so happens that the "small" builds end up being business-critical, or at least a steady part of the operational infrastructure the business depends on. Building something new from scratch is the best feeling for an operator, and it usually gets a lot of attention as the "sexy" new thing. But do you know what's not so sexy? Maintaining what you've built while working on five other new things.

In my first article I wrote about how small inefficiencies quietly pile up as a company grows, and in the second about why AI won't clean them up for you. This time I want to get practical.

How do you build the discipline to maintain scalable operations without turning your RevOps function into a bureaucratic bottleneck?

In my experience, it rarely takes more governance, more meetings or more sophisticated project management. It starts with a few relatively simple habits.

1. Define your operational non-negotiables, and challenge them regularly

Every Revenue Operations function has activities that simply need to happen – daily, weekly, monthly or quarterly. Perhaps every Wednesday you review opportunities with outdated close dates. Perhaps every month you reconcile bookings between Salesforce and your billing system, and every quarter you validate territory assignments, review commission calculations or audit your critical integrations.

Whatever those activities are, they shouldn't depend on someone remembering them. Write them down, make them recurring and give each one an owner. Jira, Asana, Notion, a simple ticketing system or a spreadsheet all do the job; visibility and accountability matter far more than a sophisticated framework. If you need a head start, my free RevOps Maintenance Calendar comes with 19 starter routines (more on that at the end).

Once a routine is written down, it's also worth asking whether a person needs to do it at all. Many of these checks are repeatable by nature: flagging opportunities with close dates in the past, comparing bookings with billing, alerting someone when an integration stops syncing. Those are good candidates for automation, or for an AI agent that performs the repeatable steps and hands the exceptions over to a person. The ownership stays, though. Someone still owns the routine, checks that the automation does what it's supposed to do, and decides what happens with the exceptions.

And here's the part that matters just as much: review those activities regularly, at least once a quarter. Ask yourself:

• Does this activity still serve a business purpose?
• Are we doing it at the right frequency?
• Can we simplify or automate it?
• Has something changed that makes this control unnecessary?
• Are there new operational risks we should be monitoring instead?

There's a big difference between operational discipline and going through the motions. Of course, business-critical processes and integrations need monitoring far more often than once a quarter. The quarterly review is about challenging the routines themselves; spotting breakages happens continuously.

A non-negotiable is something you commit to maintaining, and that commitment includes questioning it regularly.

2. Documentation is part of the job

I know, nobody gets particularly excited about documentation. But if you've ever inherited a CRM with dozens of undocumented workflows, or tried to make sense of an integration built by someone who left the company two years ago, you know exactly why it matters. I keep repeating this: documentation isn't optional. It's an essential part of delivering operational work in the first place and should be treated as mandatory, because the definition of done includes "documented"!

Btw, today there's really no excuse for not documenting. We have tools that transcribe meetings, summarize decisions and help maintain knowledge bases, so you can use AI to write a first draft of technical documentation, explain automation logic or turn messy working notes into structured instructions. Okay, you still need to check what it wrote, but the effort it takes to get started has dropped dramatically.

And AI doesn't only help you write documentation, it can help you keep it up to date, which is usually the harder part. A few ways to set that up:

• Capture decisions where they happen. Record and transcribe the meeting where a change is agreed, and let AI turn it into a short change note: what changed, why, and who owns it.
• Document as part of the change. When you update a workflow, a field or an integration, give AI the old and the new version and ask it to update the matching documentation page, so the docs move with the system.
• Let AI look for gaps. Once a quarter, give an AI assistant your documentation together with an export of the current setup and ask it to flag what no longer matches: fields that no longer exist, owners who have left, workflows nobody has documented.
• Make the documentation answer questions. Connect it to an assistant your team can ask ("How does lead routing work?"). When it can't answer, or answers wrong, you've found the next page to fix.

My rule is simple: if you change a business-critical process, you update its documentation as part of the same change. And good documentation answers practical questions:

• What does this process do, and why does it exist?
• Who owns it?
• Which systems does it affect?
• What happens when it fails, and how do we know it's working?

Nobody needs a 40-page manual. Every workflow needs enough information for someone else to understand, maintain and troubleshoot it, and that documentation should describe how things work today, including every change made since the system went live.

3. Use AI where the business needs it

Let me be clear first: I'm all for AI in operations. Used well, it can finally take on the foundational work nobody ever had time for: cleaning up data, documenting processes, running routine checks and catching exceptions before they turn into problems. That's exactly where I'd point it first.

What I'm less convinced by, and this might be an unpopular opinion in today's GTM technology environment, is spending most of our time playing with the latest tools and launching shiny new AI projects on top of foundations that aren't ready for them. If you're responsible for an operational function, your business relies on what you deliver. Sales needs accurate information, Finance needs reliable numbers, Customer Success needs processes that work, and leadership needs systems it can trust. AI should help you carry that responsibility first, and the experiments come after.

So the vast majority of our AI effort should go into solving real operational problems, starting with the foundations. I call it the 90/10 principle.

90% of your AI effort

• Solves a real business problem
• Builds on a reliable process
• Has an owner and a way to measure it

→

10% of your AI effort

• Exploration and experiments
• Testing new tools in a safe space
• Finding the ideas worth scaling

In my last article, I walked through the questions to ask before introducing a new AI-powered workflow: what problem it solves, whether the underlying process is reliable, and how you'll measure the result. Two more deserve a place on that list: what happens if the automation makes a mistake, and who is accountable for its output?

An AI agent that saves five hours of manual work every week can be incredibly valuable. An AI agent that creates five hours of troubleshooting, manual corrections and uncertainty probably isn't. And when you're dealing with revenue reporting, customer data, billing or other business-critical systems, the stakes are even higher.

Secure the foundation before you build on top of it.

4. Listen to your GTM leaders, and let business impact define your roadmap

One of the most important responsibilities in Revenue Operations is understanding what the business actually needs, and you can't do that by sitting inside your CRM all day. You need regular conversations with Sales, Marketing, Customer Success, Finance and sometimes Product or IT. Enough structured alignment to understand what's working, what's frustrating people and where the business is heading, without adding yet another series of weekly meetings.

And please, capture those conversations somewhere. A request that comes up three times across different teams might point to a genuine operational problem. A recurring complaint about a particular workflow might tell you the process no longer fits how people actually work.

But this is where judgment comes in, because not every stakeholder request should become an operational priority. A CRO might want a new dashboard, a Sales Manager an additional automation, Marketing a new attribution model, and Customer Success might be struggling with handovers. All of these deserve attention.

The roadmap should be decided by business impact, not by who holds the most senior title, who asks most often or who shouts loudest.

A few questions help:

• Does it improve revenue performance?
• Does it reduce operational risk?
• Does it remove meaningful inefficiency?
• Does it support a strategic priority?
• And what happens if we don't address it now?

Sometimes the right answer is yes. Sometimes it's not yet, and sometimes it's no. Being a good operator means being able to explain the difference.

5. Build a roadmap that fits your organization's size

I don't believe every Revenue Operations function needs the same operating model. If you're the only RevOps person in a growing company, you probably don't need elaborate sprint planning, story points or a quarterly planning workshop with fifteen stakeholders. But you do need a roadmap, even if it's just a handful of clear priorities agreed with your manager: the capabilities you want to build this quarter, the processes that need improvement, the maintenance that has to continue no matter what, and what can realistically be delivered with the capacity you have. The goal is to stop spending every week reacting to whatever seems most urgent, without creating more project management work.

In larger organizations, this becomes a leadership responsibility. The Head of RevOps, VP RevOps or CRO, depending on the structure, needs to make sure operational priorities are aligned with business strategy. But that roadmap shouldn't be created exclusively from the top. Operators working directly with systems and processes often spot weaknesses long before they show up in executive reporting. They know which integrations are fragile, which manual workarounds have quietly become permanent, which processes teams consistently struggle with, and which small improvements could remove a surprising amount of unnecessary work. Leadership, on the other hand, sees the commercial strategy, the financial priorities and the organizational changes coming down the line.

Bottom-up

• What's happening in day-to-day operations
• Fragile integrations and permanent workarounds
• Where teams struggle to follow the process

→

Top-down

• What the business needs to achieve
• Commercial strategy and financial priorities
• Organizational changes on the horizon

And one thing should always be visible in that roadmap: maintenance. If every available hour goes into new projects, the existing operational infrastructure will eventually pay the price.

6. Make room for teams to evolve

I want to put a bit more emphasis on this point, because it's crucial unless you want to become your GTM's bottleneck: you need to get comfortable with change and evolving business requirements, while drawing clear boundaries around what must stay consistent. Operational excellence shouldn't mean squeezing everyone into increasingly rigid processes. Businesses need room to experiment: Sales needs to test new approaches, Marketing needs to explore new channels, Customer Success needs to adapt to changing customer expectations, and RevOps itself needs the freedom to challenge existing ways of working.

In practice, you might standardize opportunity definitions, customer lifecycle milestones and financial reporting requirements, but that doesn't mean every salesperson has to approach every customer in exactly the same way. You might set strict controls around customer data and production integrations, but teams can still try new tools in an appropriate environment.

Standardize what the business needs to rely on. Leave room to experiment with how teams achieve their outcomes.

To keep up with how the business is changing, I'd suggest running a tech stack and process Q&A with your GTM teams every quarter. Three questions are enough to get a good conversation going:

• What should we address?
• What takes too much time out of your day?
• What do we NOT do the same way anymore?

The answers tell you where processes have drifted, which tools are getting in the way, and which experiments are already happening without anyone saying so. And when an experiment proves successful, make sure there's a way to decide whether it should become part of the standard operating model. Otherwise, experimentation just creates another collection of disconnected processes, and we're back where we started.

The real challenge is finding the balance

For me, operational excellence is about creating an environment where the business can execute reliably while continuously improving how it operates. It has little to do with having the most sophisticated processes, the most detailed documentation or the largest technology stack, and RevOps shouldn't become the department that tells everyone else how to work.

It means protecting the things that need to work every single day, documenting what you build and questioning whether existing processes still make sense. It means listening to the people doing the work without losing sight of the broader business priorities, and knowing when to experiment, when to standardize and when to leave something alone. Perhaps most importantly, it means recognizing that maintenance and development are two different responsibilities. Both need time, both need ownership, and both contribute to business performance.

To make the first habit easier, I've turned the operational non-negotiables into a free RevOps Maintenance Calendar: an Excel template with 19 starter routines from daily to annual, an owner and due date for each, and a quarterly review of the routines themselves.

Free resource · Excel templateRevOps Maintenance Calendar →