Before getting into the RPA details, I just want to say I hope all of you are healthy and doing as well as you can with the current pandemic. These are definitely challenging and unprecedented times but it has been uplifting to see how many of our customers and partners have risen to the challenge, adapted and chipped in to help. Gears has always been a virtual company so in some ways we are business as usual but in others, we had to make rapid adjustments. Overall we have been able to continue delivering our services without disruption and we feel very lucky to have that, especially watching the many small businesses that have been forced to close due to this. Hopefully, we can keep uniting as a society and do what needs to be done to get this behind us.
So why are we talking about RPA (Robotic Process Automation, a component of Hyper-Automation) when we are a Salesforce consulting firm? Well, similar to how we have built a dedicated integration practice that has experts in MuleSoft, Dell Boomi, Jitterbit and integration best practices in general, we feel strongly that RPA is another natural extension of Salesforce’s extensive platform and offerings – which is why we have created an RPA practice as well. RPA is another tool in our toolbox to bring ROI to our customers’ Salesforce implementation just like AI or integration services would be. To help us provide these services, we have partnered up with two of the best out there – Automation Anywhere and UIPath. In the latest Gartner Magic Quadrant, our partners were two of only three firms to be classified as leaders, and both of them already have established partnerships with Salesforce so they were a natural choice.
While RPA can help across a wide range of your business processes, for this post we’re going to focus specifically on how RPA can be leveraged for your Customer Service team that is working with Service Cloud. In conjunction with this post, we’re also going to do a Lunch & Learn webinar to show off what we’re talking about below. We’ll go more in-depth about what RPA is and more importantly, we’ll show live demonstrations of a lot of the use cases we discuss below – including how the bots work with Salesforce. You’ll get a chance to see both UIPath and Automation Anywhere at work as well. It’ll be fun and hope you can attend. Here are the details:
Robotic Process Automation for Service Cloud
Watch On Demand: https://www.gearscrm.com/webinar-recording-rpa-for-salesforce-service-cloud/
What is RPA?
Let’s start right from the beginning and explain a little about what RPA is. First off they aren’t real robots so let’s just get that out of the way. RPA is essentially a tool that can be programmed to mimic a human’s behavior by automating tasks that typically a human would need to perform manually (or with considerably more time). It’s like a macro on steroids. There are a few things that make it more powerful though.
First, the robots, or bots, can run in an unattended or attended mode. Unattended means that it runs autonomously and is triggered by an event. Bots could even be scheduled – “go check this directory every hour for a new file” or told by the event itself to run. The key here is you don’t need a person telling it to run. The unattended bots tend to be more cloud-based and they tend to handle the repetitive tasks that continually occur. Attended bots are just as powerful but a different use case. Attended bots are watching a human interacting with a system and then acting from there. We’ll go into the use cases below, but for example, an attended bot can watch an agent filling out a form and then when it sees the agent hit submit, take that information and go do something else with it. These bots could be on the user’s desktop or in the cloud – it really depends on what you’re asking them to do.
Second, RPA bots can leverage a lot of other technologies to extend their capabilities. OCR, Optical Character Recognition, is a terrific example. The RPA bot itself doesn’t have to have OCR capabilities – it can leverage an API call to an OCR solution to then allow the bot to act like it has OCR capabilities. The various AI and ML methods out there are great examples of how to extend the bot’s accuracy and value. This provides a lot of power to your bots.
Finally, not only can the bots extend their functionality with other tools, but they also can leverage APIs to do their work in other environments. They could connect to an AWS S3 environment to place all of the data they are collecting and then process it, or they can make calls to a system API to feed its data processing over to it. So without needing to build true integrations, the bot can pass data around and feed various systems – like Salesforce or your ERP or OMS. Now that said, a bot wouldn’t replace integrations themselves – as they would still be much more efficient, especially in bulk – but they can act as integration in situations where integrations won’t work or are just cost-prohibitive. Needless to say, RPA is very powerful – and only getting more so.
RPA Use Cases with Service Cloud
1. Structured Emails
Most Service Cloud customers are already leveraging email-to-case for their customers or partners to send in cases. However, a lot of service organizations are also receiving repetitive emails from partners, vendors or internal departments that require work to be done – and still treating these manually. Here are a few examples of this use case:
- Your finance team sending out a report of all of the credit card transactions that failed the day before and now need to be researched
- Emails coming from your customers from forms they have filled out – with or without attachments.
- An automated report from the fulfillment of all of the orders that are being delayed leading to agents needing to do outbound calls to reach out to those customers.
- Structured but frequent email alerts from partners or vendors that have information that you need to create or update in your systems – like customer data, warranty registration, or order information. A great example here is an order confirmation or a web form submission – you get a structured email with the information one at a time.
The key to these examples and others is that we can figure out the purpose of the email (what needs to be done) and there is a structured way to find what specifically needs to be done (flag all accounts in the spreadsheet attached) and who they should be done to. If you can get all of that from the email in a structured way, RPA can automate these.
The first step would be to route these to a mailbox the robot is monitoring. As the emails arrive, the bot can begin to process them. In most cases, you’d be using an unattended bot for these scenarios. Let’s take the first example to walk through. Each morning an email comes in from your Finance team that has a spreadsheet of all failed credit card transactions from the day before. Today, you probably have someone open that email every morning and manually walk through that spreadsheet spending a few hours re-processing these requests and / or reaching to customers. With RPA, you can automate a lot of these steps. Here’s what your new process could look like with RPA and Service Cloud:
- Email is received to the mailbox the bot is monitoring. Especially if you have a lot of work requests coming into this mailbox, you’ll want the subject line to be easily identifiable and unique so the bot knows this is the “failed credit card” process that needs to be run on that email.
- The bot takes the spreadsheet of the 50 transactions that failed. If the spreadsheet has enough detail the bot can automatically create Cases for the 50 failures and link them to the customer record in Salesforce. If the spreadsheet isn’t detailed enough – maybe it’s literally just an order number – the bot can actually do a lookup of those 50 orders to fetch the customer information it needs to create the cases.
- For each of the 50 cases, the bot can call Authorize.net’s API and attempt to re-process the payment. If it succeeds and goes through this time, the Case is closed and flagged as a success by the bot. If it fails a second time, the Case is updated as a fail and Salesforce workflow kicks in notifying the customer about the failed order and asking them to put in a different credit card.
The bot is now fully automating this every day and Finance will be able to run reports in Salesforce to see the status of each day’s or week’s progress. No human is involved in this process above so you’re freeing up that time each morning. You can do similar approaches with all of these other use cases. Even if you’re not receiving a file, the bot can parse the customer information it needs off of a structured email body itself.
What if you’re receiving a file each day of images/scans? A lot of companies still receive faxes of forms on a regular basis (especially in healthcare and government). Typically those are just forwarded as a scanned attachment for someone to process manually. For these scenarios, we can leverage OCR to aid the bot in automatically processing these requests. An awesome example of this is around processing payments received. While this isn’t specifically a Customer Service example – it’s more Finance – there’s no reason Finance couldn’t leverage Service Cloud and RPA to automate a massive portion of payment processing. Today, finance teams typically receive reports from their banks each day. One report for all of the checks that were received – usually with a scan of the check itself, another report for all of the wires received, and then another on payments received by ACH. Larger companies typically have multiple banks – so multiply this out by each bank you leverage. Someone (or many someones if you get a lot of payments) then spends a lot of manual time updating their finance system one payment at a time as they review these reports.
Instead of this extremely manual process, what if you leveraged Service Cloud? Have a record for each open invoice (fed in via integration from the ERP). You can set up RPA to monitor the reports coming in from your banks. These reports can be sent via email or in some cases you’re using a portal to login to and run reports. The bot can process emails as we described above, or it can be trained to log in to the portal and run each report it needs. Let’s start with the checks file and how we would process this:
- The bot would open the PDF or run the report in the portal to see all of the scanned images of the checks that have been paid today.
- Check images are typically in one of multiple formats as banks tend to use the same templates. So, for the popular templates, you can leverage OCR and train the bot to locate the check number, amount, date, and also the customer’s information on the check. In addition, most customers also reference your invoice number on the stub of the check (which is the ideal situation) so you can also train the bot to capture each of the invoice numbers referenced on the stub if that’s provided.
- With all of the information above, the bot can then search Salesforce’s open invoices and look for the match. If you have the invoice number on the stub, you’d obviously start there and then check to make sure the amount is correct (sadly, not all customers pay the full amount all the time). If you get an invoice number and amount match, the bot has a positive match and updates Salesforce – maybe by creating a payment record with all of the information from the check which then updates the invoice or whatever your process is. If the bot can’t find an exact match it can do multiple things but in general, it can create an orphan payment record with all of the info it has and then create a Case for a human to review. This can also be done in other scenarios – like a double payment.
- The bots can do similar processes with the wire and ACH reports. Leveraging integration, Salesforce then feeds this information back to the ERP.
Now in this scenario, you’ll never get to 100% automation because your customers always do weird things a human will need to act on, but you’re heavily reducing the human effort. All of the standard payments will be processed automatically by the bot and only the exceptions will require a human. Of course, you can do the same without Salesforce – and use RPA directly with the ERP system. The key advantage Salesforce has here is around these exceptions. By being able to create Cases for your finance team, you’re essentially building their workstreams automatically and from there they can leverage queues, omni-channel routing, reports and dashboards, and all of the standard Case functionality that comes with Service Cloud to go attack this work. Typically your ERP doesn’t have any of this functionality which leads to more manual and untracked effort.
As I mentioned above, faxes are another big use case here. If customers are faxing in order forms, registration forms, etc. a bot can process these with OCR and create the Order, Account or Case records that are needed to process these faxes.
3. Web Scraping
Sometimes your agents need to go fetch information from outside websites. Two big examples of this are credit checks and Duns number lookups. Maybe your agents are processing a lot of orders and as part of that processing, they need to run a credit check for your customers. In these situations, you typically aren’t allowed to integrate with these systems, or it’s simply cost-prohibitive to get API access to them, so you’re having your agents fill out the form and then copy and paste those results manually back into Salesforce. With a credit check, maybe your agents are copying and pasting 10 key pieces of information over each time. That’s 30 seconds of effort happening while they are on the phone with the customers. Doesn’t seem like a lot, but you multiply that by your number of agents and then by the number of requests you’re processing and that 30 seconds suddenly is a big amount of effort each month – and effort being done while your customer is sitting on the phone waiting no less.
So how do we use RPA to cut this down? Well, this is our first example of an attended bot. For a scenario like this, an agent can fill out and submit a credit check web form, then trigger the bot to act using a keyboard shortcut. The bot would have been trained where to go fetch the 10 pieces of information on the results page and then would copy it over into the Case record for the agent. The key here is, the agent doesn’t need to sit there and wait for the bot to finish, the agent can move onto the next part of their flow while the bot is performing this work. So, instead of your customer sitting there for 30 seconds on hold while the agent copies and pastes, the agent is already moving to the next step of your process and the bot is handling that manual task for them. Big time saver and a better customer experience.
4. Case Creation / Classification
A number of customer service teams are not just providing technical support but doing account or order management as well. In those scenarios, typically your agents are doing a lot of data updates – updating account information, processing a credit or return, managing a customer’s account with actions like provisioning new users, or issuing a new sub-account or terminating a sub-account, etc. Most of the time what we see here is the agent gets the phone call, starts to create their Case in Salesforce, typically they then swivel chair into the account/billing/order system to do this maintenance and then swivel back to Salesforce to finish the Case. Typically, they are updating the case describing the actions they just did in that other system – updating classification fields and providing a description of what was done. Where can a bot help here? In this use case, we’re back to the attended bot helping out. The attended bot can watch the agent working in that other system and be trained to see what the agent is doing. It can know what action the agent is taking by being trained on what the various screens are – the agent navigates to the Terminate Account screen and the bot will know the agent is doing a termination. It can also watch what is being updated from the actual screen – maybe looking for keys like a customer number, or a specific picklist being filled out that can provide more details about why the customer is being terminated, etc. In particular, it can be trained to know when the agent is finished. Maybe that’s when the agent returns to Salesforce, or maybe when they are brought back to the main menu, but whatever that action is, that sets the bot into motion. With all of this information, the bot can fill out all of the details of the case – the classification codes, the description of what was done, and maybe even the account & contact that was impacted.
The bot can do all of this quicker than the agent would normally type and the bot can do this while the agent is still wrapping the call with the customer. In a lot of situations, the agent can even move on to their next phone call – in the Service Console they’d be on a new primary tab, while the bot is wrapping up the Case for them in the other primary tab. This could drastically cut down your case wrap-up time and in some situations, save minutes per call. In addition, it improves your case classification quality as it’s based specifically on rules you’re creating and not depending on your agents filling it out. The effect of this is multiplied out in those situations where a customer is calling in for multiple updates. You could have the bot create child Cases off of the parent Case the agent created for each action the customer is requesting. In your manual world, this is probably all shoved into one Case description throwing off all of your reporting of why your customers are calling in. A ton of potential with this one if you have a team providing this type of service.
5. Self-Service for Systems without APIs
A lot of companies – especially companies that have been established for a long time – are working with older systems that are notoriously hard to integrate with. These could be AS/400’s, older on-prem proprietary systems, “green screens”, reservation systems, etc. These systems are still around for a reason – there’s a ton of information in them and they also tend to be the backbone of a process your company has been doing for a long time – like orders, billing or reservations. Typically these systems are not user friendly to navigate and the fact that they are hard to integrate with means they are usually stand-alone entities that require lots of manual interaction. RPA can help attack some of these challenges as it doesn’t require API access and it’s literally mimicking what a human would do with these systems – just automated and faster.
A terrific example is self-service. Say your AS/400 is your back-end order management (OMS) system and has all of the most up-to-date information about your orders – the current status, when it’s expected to ship, and if it already shipped, when it will arrive, etc. All of this is information your customers – and also most likely your internal team, like Sales – are calling your service team to get. Normally you’d create a customer portal to show this information so they don’t need to call in, but without API access to that AS/400 how are you going to display it? This is where RPA comes in. Set up tools for your customers or internal teams to put in the order number they are looking for information on. These could be in a community, on a website, or even within a chat-bot for example (you could also drop these into the Service Console as a component to keep your agents out of the AS/400 itself if needed). When that widget gets the order number, the bot springs into action and does exactly what the agent would do:
- Log into the AS/400
- The bot would then navigate to the order screen and enter the order number that was being queried. The order results screen would appear with all of the details about the order.
- The bot would be trained to know what pieces of information to fetch based on the query. From here it could grab the information it needs and also navigate to sub-screens (like an order line) to get further information about the order. One of the few benefits of these old systems is that they never really change, so you can program the bot with super high reliability that the order status will always be here and the shipping date will always be here for example.
- Once the bot has all the information it needs it would send it to the widget or chat-bot via an API and it would be displayed to your customer / internal user.
In these situations, the bot is mimicking what an API call would normally do with a system that you could integrate with. There’s no difference in the customer experience (possibly this approach would take a little longer than a normal API call) of what they’d get with a connected system – but it’s tons better than not providing any self-service due to the AS/400 and forcing customers to call in to get this information. Not only is this a better customer experience, but it’s freeing up your agents from a lot of interactions and letting them focus on more complex cases.
These are just a few use case examples in the service arena. There are a ton more where you can leverage an API. Basically, if your agents are doing something manually – especially if it’s repetitive – RPA can most likely help. For all use cases, once you have them built, there are a couple of things you want to consider. First, is error handling. RPA is not perfect and the bots can run into scenarios they aren’t sure how to handle, or maybe they are hitting true system errors – like validation rules – that prevent them from finishing a task. You’ll want a consistent process to handle these. Leveraging RPA with Service Cloud gives you a perfect way to do this. Essentially, just have the bot create a case any time there’s an issue and it can be put into a queue to review. The bot can add in all of the information on what it was trying to do and what error it received so that a human can review and address them. In some instances, they may be able to adjust the data within the Case and then the bot can re-process it (which will save time) or they may need to process it manually. Either way, these will be the edge cases and the bulk of the work will still be handled automatically.
Another key thing to consider is reporting. You need to report on RPA. You are putting this in – paying for licenses and also the work to build the reports – to save time and money from manual tasks, so you absolutely need to be able to report on what you are actually automating. Many RPA tools have robust reporting and UIPath and Automation Anywhere are ones that have strong reporting capabilities. You can track by task type how many transactions were automated and how much time was saved per transaction. However, especially when tied to Salesforce work, you might want this all in Salesforce instead of making people go to the RPA tool to get reports. Have the bot load these metrics into the Case / Work records they are creating is a terrific way to leverage Salesforce reports & dashboards to get at this data, but also is a good way to have your entire service centers work in one place – whether an agent processed it or a bot. This will let you track holistically how much of your caseload you have been able to automate and also be able to show a record on your customer activity that this work was done.
There is a ton of potential in combining the powers of Salesforce and RPA and these are just a few of the examples showing why we’re so excited to have our own RPA practice side-by-side with our Salesforce practice. Now we’re able to provide even more efficient implementations to our customers by leveraging both tools together. If you’re reading this and thinking of use cases where RPA might help you automate work, feel free to reach out, and one of our Solution Architects will get right back to you. If you want to see this in action, definitely attend our webinar around the Service Cloud use cases. In addition, we’ll be adding more content about different use cases of RPA with Salesforce, so keep an eye out for those. Thanks for reading, and please reach out if this is something that could make a difference for your customer service team.