How process standardization and robots accelerated commercial-lending operations, saving labor while enhancing banking customer experience—a case study.

Banks of all stripes and sizes have long labored to optimize back-office operations. At the same time, they strive to improve banking customer experience. Nowhere do these two challenges overlap so strikingly and advantageously as when it comes to automating “the last mile” of banking operations via robotic process automation (RPA).

In most cases, The Lab is initially engaged to deliver enterprise-wide operations standardization, business intelligence and analytics, and RPA-enabled improvements: productivity gains, labor savings, revenue lift, and cycle-time reduction. Yet half of these operational improvements also directly enhance customer experience (CX) as a baked-in byproduct.

What is banking customer experience?

Banking customer experience is defined as the process of financial services institutions proactively communicating and serving clients throughout the life cycle of a banking transaction or while a customer. Banking customer expectations are rapidly being influenced by the likes of companies such as Amazon, Uber, and other high-tech businesses. The proactive outbound communication and routine “pushing” of status to customers these tech companies created is now the expected norm across all industries.

The benefits available from these “byproduct” CX gains are some of the most valuable and sought-after today: higher customer retention, increased cross-selling opportunities, and improved margin management. Thus these two-birds-for-one-stone opportunities (productivity + CX gains) are the ideal starting point for any RPA initiative.

In this article—comprised of a mashup of The Lab’s experience with different banks and credit unions, to protect their identities while revealing a wealth of automation opportunities—we address stumbling blocks which often cause these “two-bird” opportunities to go overlooked. Then we show how The Lab automated one—in less than six weeks!

• Identification: First, we paint the big-picture challenge of identifying all opportunities to automate back-office operations with RPA. (Our list of RPA candidates, typically 50-80 possible use-cases, seems overwhelming at first. Fear not.)
• Prioritization: Next, we show you a simple shortcut to prioritize the value of those “two-bird” opportunities.
• Standardization + Automation (RPA): Finally, we select a common two-bird opportunity—commercial loan-renewal notifications—and standardize all the way down to the work-activity level to show how to use RPA to automate this sub-process.
• Real results: How RPA made life easier for the front office (sales operations), the back office (loan operations), and most importantly, the customer (the commercial borrower).

This loan-renewal notification process is merely one representative example of hundreds of operations activities (and customer experiences) that can be standardized and jointly improved via RPA bots. So bear in mind, as you read this article, that our drill-down case study is just the tip of a very big iceberg.

1. Identification:

Where are RPA candidates (use cases) hiding?

 In this article, “the bank” (remember, an anonymized mashup) sought to standardize wall-to-wall bank operations and automate with RPA “bots.”

The goal was to handle substantially more volume without adding a substantial number of new employees. This is the holy grail of automation for growth; it’s called improving “operating leverage.” Fortunately, investing in improved operating leverage also delivers benefits during an economic downturn: fewer, if any, employees have to be terminated.

The “bank” in this story purchased a “starter package” of RPA technology, established an internal team, and promptly hit headwinds in their efforts to identify valuable RPA candidates, or “use cases.” That’s because virtually every process that initially seemed like an ideal candidate, turned out, upon scrutiny, to contain an average of 30 percent corrective activity, or rework.

For example, information came into the back office—on loan applications, renewal notices, or account-onboarding packages—with up to 60 percent of the documents having fields with either missing or incorrect information. Bank employees then had to spend their time and creativity performing detective work to solve these not-in-good-order (NIGO) “crimes.”

Importantly, these one-off corrections are not work that bots were designed to do—nor, for that matter, highly-educated, costly, knowledge workers (a.k.a. banking office workers). After laboring for a year and finding only a dozen RPA-worthy opportunities that delivered minimal gains, the bank turned to The Lab to help.

Banking operations can benefit from enterprise-wide robotic process automation: across retail branches, lines of business, support groups, and of course the back office. The Lab maintains an entire org-chart-based RPA Inventory of typically-available bots (i.e., use-cases):

As you can see, The Lab has identified over 300 “off-the-shelf” commonly-recurring RPA opportunities for installing banking robots. But of course, there are countless more—every bank is a bottomless lake of bot automation opportunities. Over the next few years, these use-cases will all be ultimately automated with RPA. But right now, the competitive task at hand is to find the “two-bird” RPA opportunities in this haystack. The bank in this story now faced the prospect of not dozens, but rather hundreds of possibilities. Where to start? There were two places—but process must precede any debate of solution.

End-to-end process analysis at the minute-level task detail

The first step to standardizing and then automating banking operations—or any knowledge-work process—with RPA is a deep-dive process-mapping exercise whose scope spans the entire organization. At The Lab, we take a grassroots/front-line approach (vs. a traditional top-down methodology). We document the employees’ daily, minute-by-minute, and even keystroke-by-keystroke (if we have zeroed in on an RPA use-case) work activities for all end-to-end processes.

While this might sound like a daily-work-stopping year-long task, if performed over a series of one-hour “low-touch-time” increments with a cross-section of individual staff, the time commitment from the organization is actually minimal. The primary result of this methodology of banking operations analysis is end-to-end mapping at the two-minute task-level of detail—confirmed by front-line buy-in. The secondary result comes during implementation: a groundswell of future candidates for improvement, once the organization understands the impact of bots and standardization. Thus it teaches the front line to crowdsource their improvements in the long-run.

With this detailed view of the business complete, we then engage in a process we call a Map Fair. This is where the actual branch and back-office employees mark up, further contribute to, and comment on huge workflow printouts. And we do mean “huge”: they are as long as an office hallway wall. We conduct Map Fairs at centralized back offices and also send out maps for markup to dispersed branches, for eventual return to the headquarters.

Upon completion of the Map Fair, all standardization improvements (200+), RPA use-case candidates (60+), and analytics dashboard candidates (40+) are summarized, databased, and meta-tagged by the business unit and process they nest under.

The long tail of service tickets

Unlike manufacturing plants, banks, like most other knowledge-work organizations, maintain somewhat hidden insightful records of operations. But there is one exception: service tickets. Common systems used in banking include Service Now, OnBase, Footprints, Zendesk, SysAid, HappyFox, and others. These create standardized records of operational transactions that bots love. For example, a customer call to the contact center will result in a “ticket” to generate a resolution action: change an address, refund a fee, or waive an overcharge.

This is typically the best place to start sorting through the haystack of opportunities. The tickets can be grouped by organizational area. Then they can then be listed in descending order of work effort.

That’s what The Lab did… initially. But then as we closely inventoried the ticket-types themselves, we discovered a common problem: too many types. There were more than 420 “different” types of service tickets in loan operations alone. We found a similar situation in the contact centers: More than 500 “different” types of inbound calls. This speaks to a broader problem of “ticket types gone wild”—a distinct lack of process discipline when it comes to creating and naming them. Too many ticket types creates an atmosphere of “false complexity” that makes it difficult to standardize operations and deploy RPA.

As always, our analysis revealed that of the 420-plus types of tickets, a small proportion, in this case, the top 25 (six percent) accounted for a disproportionate amount of the total employee work effort: 45 percent in account management. The remaining employee effort is spread across the “long tail” of nearly 400 service tickets—a well-intentioned hodgepodge of costly, false complexity. Across our banking clients, this tail ranges from long (moderately costly) to even longer (fiendishly costly). Its size thwarts most attempts to manage, or even analyze it.

2: Banking Customer Experience Improvement Opportunity Prioritization

Drilling deep to find the most value from RPA for CX gains

 Armed with this “long-tail” knowledge, The Lab began its drill-down for value through commercial lending, continued on to the contact centers, and examined the top tickets in each. Why begin with these specific areas?

Big opportunity: Commercial credit-line renewals were the one of the biggest contributors to this bank’s total operating margin. The related organizations comprise the core of customer service experience. And since our client had targeted commercial-loan revenue for growth, operating leverage gains were essential to maintain profitability.

Bigger challenge: Competitors pursue similar strategies. If our client managed to succeed in growing their commercial-loan business, the tight employment market wouldn’t provide many qualified, experienced—and cost-effective—people available to deliver these loan-renewal activities. That means that successful growth-driven competitors will have to perform more (and better) support with existing staff. Operating leverage is critical to successful growth strategies. So is customer retention. No growth-driven competitor can afford to lose profitable customers. These characteristics are hallmarks of ideal “two-bird” RPA hunting grounds.

The Lab performed a quick, sift-and-sort of the top service tickets; this revealed a high number of short-term extensions for existing commercial lines of credit. A further, casual investigation indicated that these were stopgap documents issued to compensate for delays that resulted when account managers failed to notify their credit-line customers of pending renewal deadlines in a timely manner—opportunities for avoiding short-term renewals!

That’s the insight that led to identification of the loan renewal-notification robot in this case study. (Similar analyses and conversations identified other bot opportunities for customer-experience improvement.) Operationally, this renewal-notification candidate is nothing complicated, just like most RPA bots. It simply capitalizes on a routine process that frequently runs off the rails, exasperating customers due to the timeless human frailties of employees: oversight, procrastination, and forgetfulness.

Banking Customer Experience: Commercial Loan Renewals 101

Commercial lines of credit are those essential, tap-when-necessary funding sources that every business has, and depends upon, typically on short notice. Traditionally, these need to be renewed every year or two. But first, documentation must be assembled and reviewed with the customer: tax returns, financial statements, and so on. That renewal interaction is, theoretically, an opportunity for alert loan officers to give their clients a friendly heads-up, make in-person visits, and prospect for “cross-selling” opportunities—such as treasury-management services or purchase cards.

In practice, however, precisely the opposite frequently occurs. Those same loan officers discover—too late—that the line of credit is due for renewal right away, or worse, has already lapsed. Customers might call their contact center, only to learn that their support has “run out”—the credit line has expired. That doesn’t make the account managers—or the bank—look very good when they approach the customer, hat-in-hand, asking for tons of required renewal documentation, to be jointly reviewed ASAP.

Nor does it improve customer experience when the account manager is forced to hastily issue (an avoidable) short-term line-of-credit extension. It’s like telling the customer, “We couldn’t do this right in the first place, so we’re allowing ourselves a do-over (just like last year).” Customers might rightfully wonder, “Hmmm, would the bank allow me a do-over?” Or, “What else are they overlooking?”

Add to that the back-office burden of creating and processing paperwork for short-term extensions—essentially a Band-Aid (avoidable rework)—and you’ve compounded your customer-experience snafu with costly, wasted labor and squandered capacity in both the commercial-credit and contact-center organizations. There goes any hope for freeing up spare capacity to service that targeted growth. This rework is reducing capacity, typically by 20 to 30 percent. And forget about cross-selling added business at this point—more lost growth. Just hope that the competition doesn’t poach your grumbly customer.

3. Banking Customer Experience Standardization + Automation (RPA)

Developing RPA bots in six weeks: step-by-step

This story features a few principal players: In the “front office” there’s the loan officer, who is the person who originally sold the line of credit to the customer. The loan officer is supported by a loan assistant (“LA”) for help with administrative tasks related to the loan. In the “back office” are portfolio managers or PMs.

Here’s how the loan renewals process works—or “worked,” before The Lab standardized the process and put RPA bots on the job.

Every month, the PM, as the manager of the book of in-force loans, would get an updated “Renewal Pipeline Report”—basically an Excel spreadsheet, which the PM would (hopefully) sort by expiration date, to see which lines of credit were coming due soonest. The loan officers and their assistants would see this report, too. Ideally, this all happened in a timely manner—before expirations—but humans were involved.

For these humans, several mind-numbingly-repetitive (i.e., robot-friendly) work activities often thwarted the renewal process timeline: For each contract in the report, the PM needed to manually look up what documentation was available, which items were current, and which would need updating, in order to review with the customer, agree and renew the line of credit. Next, the PM would alert the loan officer—with sufficient lead time for the loan officer to personally contact the borrower (customer), advising them exactly what was needed, item-by-item. Ideally, the loan officer was to arrange a personal meeting. All of this should happen in a way that allows customers sufficient time to compile their items for the joint review.

So for each loan—and remember, it must clear Underwriting to get renewed—the PM is looking up lots of information in different systems. Examples include:

• Annual financial statements
• Interim financial statements
• Tax returns—from city to state to federal
• Accounts Receivable aging
• Accounts Payable aging
• Guarantor information: Including individual tax returns, financial statements, and more

Each item’s status must next be individually updated in the bank’s various technology systems (most don’t communicate with each other), in order to create an accurate, updated Renewal Pipeline Report.

And each PM is looking through hundreds of loans that may be up for renewal in the next 60 days. Bear in mind, that if all the paperwork is requested in advance, and received on time, and all in good order (rare indeed!), then it still takes seven to eleven work days to underwrite the credit-line renewal. Then comes the document preparation, the scheduling of the closing… if all goes well, this cycle requires about 30 days’ worth of turnaround.

So far, we’ve just talked about what the PM does. All of that work then gets dumped on the loan officer—and much of that gets dumped, in turn, on the loan officer’s assistants or LAs (“Get me their tax returns from this year; I only have last year—and I need them yesterday!”).

And then there’s all the follow-up work requiring customer contact. For every document the PM needs, there’s a need to stay on top of its status. Did the loan officer request it? How about the LA—maybe they did? Did the LA get it? Maybe the customer sent it to the wrong destination (such as Accounts Payable)? Was the info up to date? Who checked it? Has it been entered into the system—or, rather, systems—and entered correctly? It’s a numbing, never-ending game of “customer wrangling.”

Standardizing the Process and Designing the Bot’s Tasks

First, The Lab mapped and documented the bank’s existing end-to-end business processes and work activities. (That’s right, all of them, wall-to-wall, in about seven weeks. Sounds impossible, but our templates make it feasible.)

Second, we simplified and standardized these processes. That’s because, despite RPA vendor claims, bots can’t be productive “straight out of the box.” The sub-process “RPA candidates” can’t be automated unless they’re first made “bot-friendly:” simple, standardized, and repeatable. At this bank, for example, we discovered needless variations in the way the different PMs researched and populated their Renewal Pipeline (RP) reports.

So The Lab rationalized and standardized that reporting-process map into a single, best-practice version. This alone yielded a 20-percent savings—without any technology at all.

The end-to-end loan renewal-reporting process map included over 150 employee work activities, each averaging one to five minutes in “touch time” labor duration. After we identified the “sub-process” of notification activities (on the end-to-end map) that would be automated by the bot, we made an on-screen recording to document the sub-activities—the keystrokes and mouse-clicks that comprise each work activity. These are the “keystroke-level” employee actions that the bot will perform. On average, each employee work activity documented on a business-process map is comprised of 10 to 15 of these undocumented “keystroke-level” actions that the bots will have to perform.

Third, The Lab developed an inventory of the core IT systems and peripheral applications (spreadsheets, email, websites, etc.) that the bot would access—essential for information security, creating a development environment, and documenting the as-built bot.

Developing the Bot

Finally, we were ready to develop the bot. RPA bots, just like employees, have to be directed. But bots can be directed (or “configured,” or “programmed”—choose your term) without conventional computer code. Instead, they are “programmed” using drag-and-drop graphical icons—symbols that describe bot functions. Imagine creating flowcharts of those sub-activities (keystrokes and mouse clicks) with icons that execute various basic tasks: open, copy, drag, drop, send, and close.

As described above, The Lab’s RPA developers typically begin bot configuration by making video recordings of the relevant activities as currently performed by human employees: reconciling accounts, or transferring data from inbound invoices to an accounts-payable system. Next, the developers use a panel on the bot and convert the underlying, mouse-click-level tasks into flowcharts with icons. Then the bot follows its flowchart to perform the identical sequence of activities. (Caution: This development description sounds much simpler and easier than it is in practice.)

The bot does part of what the PM used to do (or forget)—only faster, without procrastinating, getting tired, taking breaks, or making mistakes:

• It opens the Renewal Pipeline (RP) Report.
• For each loan, it captures the loan number.
• It then goes to the relevant files in the imaging system (the clearinghouse where customers’ supporting documents are uploaded, captured, scanned, and given appropriate filenames) and looks for what’s needed.
• It returns to the RP Report and populates the appropriate cells (“Annual Financial Statements,” “Interim Financial Statements,” etc.).
• It calls out what’s missing/needed.
• It updates the RP Report and saves it to a shared server.

The next morning, the PM (and the loan officers, and even the LAs) can simply click the shared server to see the flawlessly-updated report. Simple as that. Then it’s just a matter of using it as a “to-do list” to preemptively contact the customer.

4. Real World Results: One “Two-Bird” RPA Bot

Customer Experience & Operations Benefits

After Knowledge Work Standardization® (KWS), it took The Lab three weeks to design and build the renewal-notification bot. Yes, just one “two-bird” renewals bot—that’s all that was needed this time. It took another three weeks to test the bot and make sure it was running flawlessly. After that, the results seemed like a miracle to the bank, its employees, and its customers.

Customer-experience or “CX” Benefits: Better, Faster Renewals

•  Fewer Extensions: While it’s hard to influence customers who, say, fail to submit paperwork when requested and thus create delays, you can reduce the percentage of renewal extensions which are effectively the bank’s fault. Prior to robots, The Lab’s client was at fault for issuing avoidable extensions for roughly 20 percent of its yearly renewals pipeline. With RPA, that number has dropped to the two-percent range—a reduction of 90 percent.
• Lower Lapse Rate: Loan-renewal lapses for customers—due to the bank’s negligence—are similarly proportionately down. And loan officers hardly hear a word of righteous indignation from customers about these anymore.
• Shorter Cycle Time: Thanks to the increased speed and capacity, renewal cycle times were cut from 30 days to an industry-average of 14. Customer perception: “My bank got faster.”
• Fewer Errors: More PMs and loan officers manage to review and submit completed renewal packages right the first time—three times more often than ever before. This means fewer callbacks to customers.
• Proactive Response: These critical reductions deliver a vast improvement in the customer’s “optics”: No longer must the loan officer humbly ask for documentation when it’s already too late. Now, the bank is almost always on the right side of timing. The PMs and loan officers are preemptively responsive—helpful—to their customers.
• Customer Satisfaction Gains: Net Promoter Score (NPS) and Customer Satisfaction rates, routinely measured in the contact centers prior to the bots, have both increased measurably from this single improvement—more than 10 points each.

Operations Benefits: More Productivity, Higher Employee Morale

• “Freed Up” Capacity: The sheer number of hours saved is staggering: In the credit group, each PM was previously spending about 80 hours a month doing this work (i.e., the bot’s) manually. The resulting savings in employees’ hours alone has “freed up” capacity sufficient to absorb two years’ worth of targeted growth—without new hires.
• More Sales Uptime: Since there are fewer avoidable extensions, the loan officers spend less time working on them—and more time selling added business during renewals.
• Employee Satisfaction: The bots also delivered morale-boosting benefits at the employee level: Those PMs in particular are delighted to get that tedious work off their plates. Now they get to oversee sales and service performance, which is what they’d been hired to do in the first place.
• Less Wrangling Time: Sure, there’s still wrangling required to coerce documentation from customers. There always will be. But PMs and loan officers had been spending anywhere from 35 to 70 hours a month chasing customer documentation. That’s now slashed by two-thirds.

IT GETS EVEN BETTER

What we’ve described in this booklet is only the beginning. Once a bot is created, it’s easy to give it more functionality, or add a companion bot, improving customer experience further (while saving even more knowledge-worker labor).

For example, the exact same loan-renewal-notification robot now takes the updated documentation-needed list and creates automated emails or text messages with links that can be sent to the loan officer’s customers, detailing exactly what’s needed, and when.

And beyond credit-line renewals, The Lab is working with banking clients to add bots throughout the entire end-to-end sales, lending, and servicing processes.

Book a free screen-sharing demo

Seeing a bot in action is easy!

• Call (201) 526-1200 or email info@thelabconsulting.com to book your free, no-obligation 45-minute screen sharing demo today.
• Be amazed when you see RPA bots in action.