In this Run and Reinvent podcast, I chat with Tony Ashby, senior Manager of front office solutions delivery, and Nicole Johnson, senior manager of business solutions analysis, at Aspect Software about how they’re reinventing the company’s IT service management practice. Aspect Software offers a suite of contact center and workforce optimization solutions that help companies keep agents engaged and help them provide exceptional customer service. Below is a condensed transcript of our conversation.
John Fulton: Can you describe a little bit about your current Remedyforce environment?
Tony Ashby: We’ve been Remedyforce users now for I guess it’s a little over four years. We started out initially implementing incidents primarily for help desk tickets for the IS organization. And when we went live, we also included a small measure of self-service so that people could utilize that to do their ticket submissions. We also have email services enabled to make it easier and so some automated routing. We’ve got some special mailboxes to do those routings, the cues, and things like that. We had such great adoption usage that really fit our environment very well that we continued to expand our footprint a little bit to where we began including change management initially for IS.
We extended that for our customer care organization then. They use that for change management for our actual customers as we’re doing upgrades and implementations. And we supplemented that with a small implementation of a knowledge base within Remedyforce. And we also have, again, a very small implementation today of CMBB that we use for physical asset tracking. Things like mice, keyboard, laptops, things like that. Most recently though, last year, we, again, substantially expanded our Remedyforce implementation in conjunction with our cloud service management project where we opened it up for our cloud operations team.
John: Interesting the cloud service management area that you guys have recently delivered in supporting your cloud ops team, can you elaborate a little bit more?
Nicole Johnson: The cloud operations team within Aspect really had several challenges that they were facing. We had lots of environments that they were monitoring. We had a ton of tools that they were using to do that monitoring. So, to keep our customers’ cloud environment up and running on a daily basis, they were monitoring 20-plus applications that they were using to just get their job done on any given day. Our goal really for them with this project was to reduce the number of interaction points that they had, to reduce the number of screens that they had to monitor, specifically when we were talking about alerting functionality.
When a system would call home and say, “I have a problem,” or call home and say, “I’m fine,” we needed to reduce the number of places they needed to go and look and find that information. We also needed to have a place to track all of this stuff. So, we had alerts that were coming in. We had dashboards that they could look at. In some instances, somebody could claim it and say, “I’m working on it,” but we really weren’t tracking what was happening, who was working on it, how long they had been working on it, what was wrong with it. We had to get that holistic what’s happening, who is doing it, what’s going on. And we needed a place to store all of that.
That’s kind of how we came about taking on this project, again, to just reduce all of the touch points that they had. Their job was way harder than it needed to be because of all of the interaction points that they had.
John: I’m trying to picture in the case here where I think you said there are over 20 different monitoring applications. I would assume the team would really have to be an expert to understand which application to go to in certain situations. What were the challenges there?
Nicole: Yes, there were a lot. And as you can imagine, all of that comes with a delay. I may see this thing. It came in via email, but I don’t really know where to go and look and get further information about it. Or I see this thing and it came on my dashboard. Or I forgot to look in one location or another and I didn’t see it in time. So, there was a lot of delay in just reacting to stuff that came in. And for the stuff that came in that somebody knew about, there was a delay in them being able to do anything about it. They didn’t know if it was real. They didn’t know what machine it was coming from and what have you, any number of things.
John: Can you characterize a little bit, it may be just an estimate, how many alerts a day are we talking about?
Tony: With the initial implementation of the project, that’s really when we got our first good barometer of what that looked like. And we were seeing in the ballpark on average about 12,000 individual alerts each day.
John: Can you talk a little bit about how you guys have implemented Remedyforce and your future plans?
Tony: I’d be happy to. Actually, it’s very exciting. It was a project that my team, including Nicole, everyone really enjoyed working on because we saw the significant value add that we could bring to our business team. The obvious thing that we implemented was incident tracking where we could actually take some of those alerts and turn them into incidents. And we could then build upon that and actually group those into problems. And then, we’ve also started implementing a knowledge base. And they had kind of a pseudo knowledge base so that’s a slow conversion process for us.
But it actually enables the team then without having to go to multiple applications to try to figure out what’s having a problem, what’s having an issue, how big is the issue, is it truly a problem. Are we seeing a big manifestation of it getting to the right procedures to help us go address that issue? And as Nicole mentioned, we had 20 different individual learning applications when we started the project. We were actually able to consolidate those down into one application. And that’s front end into Remedyforce. But that application actually kind of acts as a collector.
Then it will feed alerts into Salesforce. We created a custom object for that, which we then applied a rule extension so we can configure which things that we wanted to turn into incidents and/or take additional actions. We would post messages within Chatter groups, within Slack channels. Some of those integration points that you kind of culled out. Those were things that we added with the project. The ability to actually create incidents, actually post them to Chatter groups to be able to integrate with Slack channel, our R&D teams. That’s their primary means of engagement is through Slack as well as being able to use integration to another tool called Ops Genie.
And Ops Genie is a paging system so we could actually when a critical alert comes in, we could actually then identify that we needed to page somebody, wake them up, place a phone call all without leaving Remedyforce. Those were all within integrations that we provided with the tool. We also had a very light integration, if you will, for Jira, which is one of our defect tracking systems, where we can launch that from within Remedyforce as well. That wasn’t possible before.
Now we have the ability, in addition to being able to do all of these things without the “swivel chair” between many diverse applications, we can do that all within the Remedy Force console and we’ve collected a whole bunch of data points along the way. I can see when I actually posted a message in Chatter. I can see when I did a call out to Ops Genie to wake somebody up. I can see the activity that occurs back and forth between Slack and Remedy Force with all of that integration that we implemented.
John: Can you maybe elaborate a little bit on using the Sales Force cases and how that sort of fits in? What I see from other customers is sort of providing that 360-degree view for our customers for their customers.
Tony: It does. And it’s 360 degrees with a little bit of fuzz around the edges. What I mean by that is that, internally, yes, we absolutely have that 360-degree view now of our customers with the issues that we have when they come in, timed resolution, things like that. But we also have this cloud operations team as a separate group that, again, supports the infrastructure for our products where our customer care organization, their native application is Salesforce cases. We actually interact with our customers via Salesforce community. We have the ability now to see the information from incidents that’s appropriate for consumption by customer care. It’s at the right level. It’s not too detailed for them. But we also have automation already that we build upon within the case structure that we can take that information as we post that to these cases.
John: Providing all of that information at everyone’s fingertips definitely provides benefit.
Nicole: The key to all of the integrations that were built allows those users that work outside of native Remedyforce, even within the Salesforce ecosystem, they can still live in the applications that they’re most comfortable with and they do their day job in and still have all of the information that they need that’s applicable to anything that’s going on with the Remedy Force implementation and the cloud service management team and what they’re doing on any particular incident or problem or what have you. It shares that information out.
John: Can you talk a little bit about the subsequent phases that you guys are considering down the road with Remedyforce?
Tony: What we are planning to do is actually a full-on implementation of CMDB with auto discovery so that we have a better insight into all of the environments that constitute our various tenets that our products live on. As it is today, those are somewhat siloed. There are multiple teams that support those various pieces of infrastructure.
And it’s not really easy for us to see where within the respective environments that an issue or trouble may lay and/or see when it clears. So, we want to, again, build out our CMDB. We want to implement the device discovery.
And then, with Phase 3 that’s to extend the change management and add visualization, if you will, to the CMDB. So, when we see these incidents, just picture, if you will, the big war room with a big screen on the wall where you can see your environments. And then, you can see the connections at various layers. You can actually see the network connectivity layer. You can see socket layers between processes on multiple servers.
