What Problem Were They Trying to Solve?
Shane: Hey guys, and welcome back to another edition of AI and Automation in Action, where we go through real world use cases of AI and automation and hopefully spark some ideas for you to put to use in your own operations. And again, we're joined by Hunter. Hunter, thanks for taking the time to hop on with me today. I'm excited to hear what you've been working on. So, if you don't mind, let's talk about what was the problem that we ran into for the client that we were hoping to solve for.
Hunter: So, we had a client that came to us. They have been using the automation platform that we're partners with. They came to us because they hadn't been seeing value, efficiency gain, or an ROI. That's where they leaned on us. They had identified four processes but wanted to start with their new user onboarding. That's where they were seeing a lot of the noise.
Why Did the Form Strategy Change?
Hunter: Initially, they wanted their form to live in an external application. We walked through that and showed them it is possible, but it's not the best way to do it. We showed them that the automation platform they are already using supports dynamic forms. When they go to set up a new user, the form asks who the manager is, and clicking that box pulls the managers set up in Office 365. They won't have to type that information in manually. If those forms had stayed in the external system, any changes in Office 365 would have required manually updating that separate system as well. We showed them there was a better way, inside an application they already use, and that really helped bridge that gap.
Hunter: There was one portion of the process that wasn't supported by a native integration. We offered to build that for them, but they wanted to hold off for the time being. Since it was a simple task, we are instead calling it out in the ticket at the end as a manual action that still needs to be taken by the technician.
Why Do So Many MSPs Struggle to Get Value from Automation Platforms?
Shane: I want to step back a little. This client is another MSP, a company that takes care of their end users from a technical perspective. They're using a common automation platform that we also build in. I've heard this from multiple other partner MSPs. They see the value these platforms can enable, but finding the time and the right person to really pour into them has been the limiting factor. We started building on this particular platform about two and a half years ago, and we made the decision to dedicate a person like Hunter as our primary builder. A lot of MSPs don't have that luxury. So that was really the first pain point. They saw the automation potential, invested in the platform, then ran into the common question: who is going to do this, and where does the time come from? Am I getting that fairly accurate?
Hunter: Exactly. They had engineers and technicians in house, but those people were swamped with day-to-day tickets and projects. That's where they needed someone like us to lean on. Someone who could pitch automation ideas, bring automations we've already built for other customers, help bring those to life, and also train their technicians and engineers if they wanted to sit in and learn how to do this in house as well.
Shane: We've heard this story so many times. MSPs understand the technology and the potential, but we've still got a business to run and clients that need support. Automation platforms, especially ones that handle more advanced automations, require additional time and training. A lot of MSPs end up buying access, having the ideas, but never getting to it. I've heard of MSPs a year, sometimes a year and a half or more into paying for the platform before they start questioning whether it's worth it. And it's not a matter of whether the platform can do what they want. It's their ability to focus on it.
What Does the Automation Actually Do?
Shane: So they were looking at three to four automations. I'm assuming this is their internal workflow at this point?
Hunter: Yes. Right now they're manually handling all of those actions. They do have a customer-facing form they're using today just to collect the details and create the ticket. What we're actually doing is replacing that customer-facing form. It will handle everything in the automation, and then for the single task that requires it, there will be a manual technician follow-up flagged in the ticket.
Shane: And I assume it's like many of our automations where we start with a base level of functionality and then continue to stack and build on it.
Hunter: Correct. The integration they held off on was their phone integration. If a new user needs a phone extension set up, that's where the limitation sits. They do have API support in that application. They just didn't want to use the project hours we had scoped until they see the full benefit from the other items. So that's going to be layered on eventually. It will just take some additional time to build that integration and bring it to fruition for them.
How Much Time Is the Automation Saving?
Shane: In terms of where things stand today, they have the automation platform, and new user onboarding is the first use case. The client has a new employee starting and needs to provision access to email, their domain, their toolsets, and whatever their normal process covers. You were able to take the scoped version and bring it to execution. Have you heard back from them on how it's working?
Hunter: Not yet, only because we are still actively working through the final pieces of automation development. We're waiting on one item from one of the integrations before we can test it at the customer level. We've been testing at their parent level and it works, but we want to confirm it works at the customer level as well. In terms of ROI and efficiency, the process recording they shared with us shows their current manual process takes about 15 to 20 minutes on average per new user, and that includes the manual item. On average, this automation is saving them roughly 10 to 15 minutes, leaving them about 3 to 5 minutes of actual manual time if a phone extension needs to be set up.
What Should MSPs Know Before Starting an Automation Build?
Shane: That is great to hear. You pointed out a key concept. Building the automation is something you can work with a partner like Innovative Automations to deliver, but there are still going to be tool connections and process documentation that the MSP or partner needs to bring to the table during the build. It's important to scope that in. Yes, we can build what's needed, but we're going to rely on the client for provisioning access and the API keys and everything we need. That coordination is really the only limiting factor we consistently run into.
Shane: The important takeaway here is that if you're an MSP, or even if you're not an MSP but you're paying for an automation platform today and running into the same scenario of needing to bring it to life, working with Innovative Automations offers a few key benefits. We can help jumpstart that for you, train your team on what we've built, how we built it, and why, and train your end users on how to use it. We can work alongside you if your team wants to take it over after the fact. Or we've got clients that say they just want us to be their go-to partner because the investment versus the return is exponentially in their favor regardless. Fantastic use case. I appreciate you stepping us through what you've been building, Hunter. Excited to see the real world results from this ongoing engagement.
Hunter: Thanks again for having me, Shane. Looking forward to the next one.
Shane: Likewise. Thanks, Hunter. Thanks for tuning in to AI and Automation in Action. If today's conversation sparked ideas about how AI or automation could improve your operations, we'd love to continue that discussion with you. Join us next time as we showcase another real world implementation. And if you want to brainstorm with our team, email us anytime at ideas@innovativeautomations.ai. Until next time.