Why RevOps Is Broken: A Howly x Radish Webinar Recap
Why RevOps Is Broken: A Howly x Radish Webinar Recap
Quick Answer: RevOps was created in 2020 to unify sales, marketing, and customer success into one predictable revenue engine. In most organizations today, it has become a help desk for broken processes instead. The root causes are consistent across portals: no documentation, forgotten workflows nobody will touch, uncoordinated admin access, and now AI tools that build on top of all of it without knowing what they will affect.
Howly founder Christian Baun joined Mike O'Mara, growth strategist at Radish, for the inaugural episode of Off the Record with Radish. The conversation covered how RevOps lost its original purpose, the specific portal conditions that cause it, and what AI is doing to make the problem worse before anyone fixes it.
This post covers the ground from that conversation, organized around the workflow visibility and governance angle.
RevOps Was Supposed to Be a Unifier
The term "RevOps" locked in around 2020 as an approach to align sales, marketing, and customer success into one engine built around predictable revenue. Mike O'Mara described the early days as cross-functional and strategic: RevOps professionals sitting in on leadership conversations, building programs, bridging departments.
Christian's read on the same period matched. Many RevOps professionals landed in the role by accident, coming from email marketing or general HubSpot and Salesforce familiarity, and the work was mostly opportunity: connecting event leads to follow-up, running campaigns, learning the systems.
That is not what the role looks like now.
How RevOps Became a Help Desk
Both speakers agreed on the shift: RevOps has become the place where broken processes get duct-taped back together. Instead of strategic alignment work, a large share of the job is now operational triage inside a messy portal.
Christian pointed to a specific driver: the tooling stack RevOps is now expected to own has expanded well past HubSpot and Salesforce. Go-to-market engineers are now expected to triage tools like Clay, Apollo, HubSpot, and Salesforce simultaneously, often without the visibility to know what any one system is actually doing.
Four conditions came up repeatedly as the root causes.
No Documentation
This was named as the core issue everything else stems from. Christian described walking into a new portal for the first time; several consultants, admins, and possibly agencies have touched it, and there is no record of what any of them built or why.
Without documentation, even a simple change carries risk. Christian's example: setting up a new lead nurture program that enrolls a contact after a form submission. Without a dependency map, there is no way to confirm the form submission isn't already triggering something else, or that becoming a marketing qualified lead doesn't fire a separate, undocumented process.
Forgotten Workflows
Active automations built years ago and never revisited are common enough that Christian described them as routine: an event-based workflow from 2021, still enrolling and qualifying leads today, with no one left at the company who remembers building it. Nobody removes it, because nobody can confirm what breaks if they do. That is what turns an orphaned or stale workflow from a minor cleanup task into something people are actively afraid to touch.
Uncoordinated Admin Access
When admin access spreads without a review process, individual users create fields, properties, and workflows to solve their own immediate problem, often without telling anyone. Multiplied across a team, this is what produces duplicate contact fields, conflicting lifecycle triggers, and workflows built without any check against what else is already running.
Christian pointed to race conditions as the direct downstream cost: two workflows firing in an order nobody planned, or a contact enrolled in three nurture programs at once because nothing coordinated the enrollment logic across them.
Silo Blindness
Marketing, sales, and customer success frequently have no visibility into how a change in one team's part of the portal affects another's. A workflow built for one team's benefit can quietly break something the next team depends on, with no mechanism in place to catch it before it happens.
AI Does Not Fix a Broken Portal. It Runs the Bad Process Faster.
This was the sharpest point in the conversation. Dropping AI into a portal that already has documentation gaps, forgotten workflows, and uncoordinated admin access does not clean any of that up. It executes the existing dysfunction at a much higher speed.
Christian was specific about why: an AI tool has no historical knowledge of the portal. HubSpot's Breeze AI Assistant can build a workflow from a prompt, and that capability is genuinely useful for basic tasks. But it cannot answer the question that actually matters before anything goes live: what does this affect upstream and downstream?
His example was a client using Breeze to build a workflow that reassigns deal ownership once a deal reaches a certain stage. The build itself is not the problem. The problem is that nothing in that process checks whether other workflows or properties are already tied to that same deal stage. Without a dependency map, there is no way to answer that question before the workflow goes live, only after something breaks.
That is also why Christian argued RevOps specialists are more necessary now, not less. AI increases the speed at which decisions get made. Someone still has to be able to say yes or no to a proposed change based on what it will actually touch.
What a Deep Audit Actually Surfaces
Mike framed the fix as a dedicated audit: not a quick look for obvious issues, but a full trace of the underlying business logic across a portal.
Christian described what a Howly audit specifically surfaces: the connections between workflows that HubSpot does not show natively. That includes direct enrollment between workflows, list-based enrollment, and property-based triggers, along with overlapping actions across separate workflows and enrollments that feed into workflows that are no longer active.
The scale problem is real. Christian noted that the portals Howly audits average between two and five hundred workflows for larger organizations, many with enrollment chains that have been running for years with no map ever produced. Even when documentation exists, it is stale the moment the next workflow is built. A tool that stays connected to the portal and reads live, rather than producing a one-time snapshot, is what makes a repeatable audit workflow possible for a consultant working across multiple client portals rather than rebuilding documentation from scratch every time.
Howly is a read-only tool: it connects to a HubSpot portal over OAuth and cannot write, edit, or change anything inside it. It loads a full portal workflow map in 10 to 25 seconds depending on portal size, and an agency account can connect unlimited client portals under one login.
Where RevOps Goes From Here
Both speakers pointed to the same shift: RevOps professionals are increasingly expected to own not just HubSpot or Salesforce, but the full stack of outbound and inbound tools around them, and to make sure everything routes back to the CRM as a single source of truth rather than living in disconnected tools and spreadsheets.
Getting there starts with the same foundational work covered above: documentation, a dependency map, and a governance process for who can create what. Without that foundation, adding more tools, AI or otherwise, only adds more surface area for the same underlying problem.
If you're taking over a portal without documentation, connect it to Howly and see the current dependency map before you make your first change. The trial is 7 days, no credit card required.
Key Takeaways
RevOps was built to unify sales, marketing, and customer success. In most portals today, it functions as a help desk for undocumented automation instead.
The root causes are consistent: no documentation, forgotten workflows nobody will remove, uncoordinated admin access, and silos between teams with no shared visibility.
AI tools do not fix a broken portal. They execute existing dysfunction faster, which makes dependency mapping more urgent, not less.
FAQ
Why do people say RevOps is broken? RevOps was created around 2020 to unify sales, marketing, and customer success into a single engine focused on predictable revenue. In many organizations, the role has shifted away from that strategic function and toward reactive troubleshooting: fixing broken workflows, cleaning up data issues, and managing tools that were never properly documented. The function still exists, but the day-to-day work looks more like triage than strategy.
What causes HubSpot portals to become unmanageable? Four conditions come up consistently: a lack of documentation for existing workflows and automations, active workflows built years ago that nobody currently understands or feels safe removing, admin access spread across too many people without a review process, and a lack of visibility between departments into how changes in one part of the portal affect another.
Does adding AI to HubSpot fix workflow and data problems? No. AI tools, including HubSpot's Breeze AI Assistant, can build workflows and automations quickly, but they have no historical knowledge of a portal's existing dependencies. If the underlying data hygiene and workflow structure are already poor, AI executes that dysfunction faster rather than correcting it. A workflow built by AI still needs the same dependency check as one built manually.
What should be documented before making changes to a HubSpot portal? At minimum, every active workflow's enrollment trigger, its connections to other workflows through direct enrollment, list membership, or property changes, and whether it is still actively enrolling contacts versus dormant. Without this, it is not possible to confirm what a proposed change will affect upstream or downstream before making it live.
How is a HubSpot workflow audit different from just reviewing workflows manually? A manual review typically checks whether a workflow is active and when it was last modified. A full audit maps the connections between workflows, including triggers that HubSpot does not surface natively, such as property-based enrollment into a separate workflow. This is what makes it possible to identify orphaned workflows, redundant automation, and enrollment chains that would otherwise stay invisible until something breaks.
Howly is a read-only HubSpot workflow mapping and audit tool. It maps workflow connections, flags structural issues, and shows the impact of property changes before you make them. Used by RevOps teams and HubSpot agencies managing complex portals at scale.
