Not accessibility as a checkbox or compliance obligation, but accessibility as a principle of human-centered design. Think multimodal enablement, localized documentation, and workflows that support the way real people work. From time zone constraints to neurodivergent learning styles, they walk through how to stop the rollout madness and start building GTM systems that serve the whole team - not just the top 10%.
“We are not short on tools. We’re short on usable, accessible systems.” – Mahak Vedi, Founder at Revology
Let’s start with a definition. When Vedi and Brunet talk about accessibility, they aren’t just referring to screen readers or physical impairments (though those matter too). They’re talking about:
It’s not about building separate tools for every user persona. It’s about building flexible systems and enablement approaches that scale across variability - without making assumptions that “one size fits all.”
For example, our article How to Create Sales Enablement They’ll Use highlights exactly how enablement should be built into daily workflows, not retrofitted later.
Revology’s team shared stat after stat to back up their experience:
And behind every failed implementation? Friction. Confusion. Shadow spreadsheets. Manual workarounds. Slack threads asking “what’s the link again?” and teams inventing GPTs just to survive.
As Brunet noted, “You see avoidance behaviors, people ticking boxes just to get it done, and none of the reports make sense. That’s not bad behavior - it’s a signal the system isn’t working.”
The webinar is peppered with eye-opening examples that most RevOps teams will recognize:
So what’s the fix? It starts with humility and ends with co-design.
“You can’t build for a whiteboard,” said Brunet. “You have to sit with the reps and say: Show me your day. What makes you want to bang your head against the wall? Where do you get stuck?”
From there, you map friction points, interview users at different performance levels and geographies, and build for how people actually behave - not how you wish they would. A few principles that emerged:
Brunet’s team even built a “one build, many uses” framework: Record a Zoom, slice into short clips, drop into a knowledge base, extract transcripts, and create visual how-tos. One input, multiple outputs, maximum accessibility.
This co-design ethos connects to articles like Measuring the Impact of Enablement, which insists that effective enablement is about building trust and measurable retention - not just rolling out features.
Every RevOps pro has stared down a clunky, broken, barely-used tool and asked: Should we fix this, or rip it out?
Here’s their quick decision framework:
Sometimes, ripping and replacing is the right answer - especially if you can pair it with fresh documentation, internal champions, and training that actually sticks.
Our resource on How to Structure Your RevOps Organization dives into how your internal structure should support these decisions - protecting against falling back into silos
Accessibility is also a cultural muscle. You build it by listening, solving tiny but meaningful problems, and building trust over time.
“Sometimes it’s a small picklist that’s in the wrong order,” said Vedi. “You fix that, and users start coming to you with bigger requests because they see you care.”
They also shared Revology’s template for identifying accessibility gaps:
And don’t forget: low performers often have the most revealing feedback - if you can get them to trust you.
As our RevOps Do’s and Don’ts by Company Stage article explains: overly complex CRM setups without adaptive interfaces often lead to tool abandonment - and that complexity grows faster than usage.
Accessibility doesn’t mean slower rollouts or more overhead. In fact, done right, it accelerates adoption and impact. The key is to bake accessibility into your process, not bolt it on after go-live.
Some practical suggestions:
And above all: assume good intent. Most users aren’t lazy or resistant. They’re overwhelmed, undertrained and trying their best with the tools they’ve got.
As alluded in When RevOps Doesn’t Own Systems, building influence and clarity over “the why” is as valuable as owning workflows.
RevOps loves its systems, but as Brunet reminded us:
“The people are what the tech is there to support.”
Before Salesforce, we sold. Before Slack, we communicated. The point of technology isn’t more complexity - it’s enabling better performance across all types of users. Inclusive design isn’t just about empathy - it’s about outcomes.
If you're tired of failed rollouts, shadow processes and tool chaos, take this as your cue to shift your mindset from implementation to inclusion.
Hungry for more RevOps wisdom? Check out our blog for more tactical insights, or join the RevOps Co-op community to connect with over 17,000 operators building better systems - together.
.jpg)
.jpg)
.jpg)
.jpg)
