The Automation Strategist team at Rewst works with hundreds of MSPs every day on this exact problem. Here's what the discovery process actually looks like.
The 2026 State of MSP Automation report surveyed 300 MSP professionals across the industry. Forty-eight percent said identifying which processes to automate is a top barrier. Those of us on the Automation Strategist team here at Rewst talk to these MSPs every day, and what we find more often than not is that the problem isn't that they don't know what to automate. They struggle with prioritizing, or they're looking at only a narrow slice of their business.
The question usually isn't "what should we automate?" It's "out of everything we could automate, where do we start?" The opportunities are already in your business. You need a process for finding and sorting them.
If your team has written an SOP, a runbook, or a playbook for something, that process is already telling you something: you do it often enough to document it, or it goes wrong often enough that someone had to write it down. Start there.
From there, look at your PSA. If you’re already in Rewst, our PSA Analyzer is a good starting point: it scans your ticket data and surfaces patterns by volume, category, and frequency. It can confirm what you already suspected and occasionally flag something you missed. But PSA data only tells you what's happening in your queue. It won't show you what's costing time in billing, operations, HR, or any of the other places where manual work has been piling up. For that, you have to talk to people.
Greggory's framing on discovery: don't just ask someone for a process, ask them for a problem. "You don't need to ask somebody for a process. Just ask them for a problem." Walk up to anyone in your business (not just IT) and ask what about their day drives them crazy.
They will tell you.
The key is pushing past the abstract. Keoni's rule: get into the specifics, not the abstract. “I have this problem getting NinjaOne counts,” not “I struggle consolidating billing.” The first one is a specific problem. The second one is a category. You can only build on something that's specific.
Once you have something that specific, RoboRewsty, Rewst’s AI assistant and workflow builder, changes what you can do with it. You don't need to know the answer before you start. Feed the problem in a prompt, and it'll help you figure out what an automation could look like, which components it needs, and where to start building. Nalin calls it a problem translator: "You can have a list of problems and feed each one in to see what solution it comes up with. You don't have to be an expert automation engineer to get started."
Here's something we see consistently: an MSP's automation ideas reflect only what one or two people in IT are aware of. That's a fraction of what's available.
Thomas puts it plainly: "Pretty much everybody who comes in is just so focused on the service desk. There is so much more that can be done. There's a whole group of automations that aren't even being considered."
Automation works best as an organizational initiative. "It's enabled by a platform, but the whole business has to contribute to what gets built," according to Nalin. If the only person feeding ideas into your process is the person managing the platform, you're leaving most of the opportunity on the table.
The MSPs building real momentum make automation visible across their business. They have a champion who talks regularly to ops, finance, sales, and account management, and they create regular touchpoints for surfacing what's slow or broken. For larger shops, that might look like a quarterly meeting with department managers. For smaller teams, it can be as simple as making it clear that if something feels tedious, you want to hear about it.
The right champion isn't always your most technical person. It's the one who keeps asking why you keep doing things the same way. That combination of curiosity and permission to act is what moves programs forward. RoboRewsty has also lowered the technical floor. Someone who can clearly describe a problem can make real progress in Rewst, even without deep automation build experience. Your pool of potential champions is bigger than you might think.
Once you have a list of opportunities, you need a framework for deciding what to build first. Keoni even suggests starting a step earlier: "The conversation has to start before the list. It really comes down to what their business objectives are behind automating things." Quality of life for employees? Cost savings? ROI on specific workflows? Or getting five techs to handle the same ticket the same way? If you have those goals in place, prioritizing becomes straightforward because each candidate either serves the goal or it doesn't.
This is where the IMPACT Framework comes in. Developed by the Rewst team, it's a structured approach to scoring automation opportunities and building a business case around them, covering everything from the cost of doing nothing to how you calculate net savings and communicate ROI to stakeholders.
At its core, you're scoring opportunities on two dimensions: impact (how much does solving this matter?) and effort (how long does this take to build?). Low effort, high impact goes to the top. High effort, low impact goes to the backlog. Everything in the middle gets sorted by what your business needs right now: cost savings, technician capacity, client experience. Prioritize whatever the real goal is this quarter. For a full walkthrough, Rewst's IMPACT Framework blog covers the complete methodology: Proving the Value of Automation With the IMPACT Framework.
Greggory adds a third dimension: risk. Billing reconciliation is the example they keep coming back to. High impact, real-time savings. But if it runs misconfigured without oversight, overbilling clients or underbilling yourself can compound fast. Their approach for automations like that is a tiered rollout: run it in monitoring mode first to validate the output, build in a human approval step until you're confident in the results, then let it run autonomously.
And one more thing: you don't have to automate an entire process to get value from it. If a five-step process has three steps that consistently go wrong, automating those three matters. Fifty percent automated is better than zero.
Before RoboRewsty, your automation backlog was whatever the automation engineer could handle. One person, one set of problems they knew about. Everything else waited.
That's changed. A service manager can describe how they want tickets dispatched in plain language and get a working scaffold. An ops manager can explain what keeps going wrong in their process and get a starting point for a workflow. The automation engineer reviews, refines, and ships rather than building everything from zero.
Linda ran into this firsthand: "It took me about 80 hours to logically build out a dispatch workflow, coding in all the edge cases by hand. With RoboRewsty, we built the equivalent in five one-hour calls."
That kind of time difference makes automation real for teams without a dedicated automation engineer on staff. And when more people can contribute to what gets built, more of them have a reason to bring you their problems.
The frameworks we use with MSPs every day are available at Cluck University. Do them before you get stuck, not after.
The Process Engineering course teaches you to look at a process holistically: where does the friction start, and does the process need to be redesigned before it gets automated? A lot of teams automate a broken version of a process because they skipped this step.
The IMPACT Framework course teaches you how to calculate and communicate the ROI of automation: from identifying the cost of manual work, to accounting for risk, to telling the story in a way that lands with finance, operations, and leadership. If you ever need to justify what you've built or make the case for what to build next, this is the methodology.
The Automation Fundamentals certification covers the foundation. Thomas makes it a prerequisite before he runs a follow-up strategy session with any customer.
Teams that go through it make better decisions and move faster afterward. That's the whole reason.
"What should I automate first?" can turn into a reason to not start at all. Every option has a counterargument, and every team has more work than bandwidth.
Pick the process that's already documented, has clear inputs and outputs, and gives you something you can measure. Build it. Don't let perfectionism stall it. Thomas sees this often: "People have got an idea, they start doing it, and then they want to change it, and change it, and change it. I'm like, just finish it and then move on. Create versions."
Each decision gets easier because the last one taught you something.
Ninety-seven percent of MSPs plan to do more automation this year. Most are stalled in the middle. Read the 2026 State of MSP Automation Report to see where the gaps are and what's moving teams through them.