Credit unions of all stripes and sizes have long labored to optimize back-office operations. At the same time, they strive to improve member experience. Nowhere do these two challenges overlap so strikingly and advantageously as when it comes to automating “the last mile” of credit union operations via robotic process automation (RPA).
In most cases, The Lab is initially engaged to deliver 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 member experience (MX) as a baked-in byproduct.
The benefits available from these “byproduct” MX gains are some of the most valuable and sought-after today: higher member retention, increased cross-selling opportunities, and improved margin management. Thus these two birds- for-one-stone opportunities (productivity + MX gains) are the ideal starting point for any RPA initiative.
What is the definition of credit union member experience?
Member experience, commonly referred to as MX, is defined as the end-to-end customer perceptions of credit union members as they engage with the services that are provided by the credit union. These experiences will vary by different product types within the credit union. As an example, the member experience of someone seeking a new loan will follow a different path when compared to a member who is simply depositing a check at a branch. The trend of member experience improvement hatched from roots of increased customer service of digitized processes on Amazon.com and similar customer-focused websites.
As a result of the increased demand for member experience improvement in credit unions, many new job positions such as Chief Member Experience Officer, Vice President of Member Experience Improvement, and even Member Experience Analysts are trending on job websites like LinkedIn. In addition to new jobs, member experience improvement conferences have become hot topics and must-attend events albeit mostly through web conferences and webinars in 2020 and 2021.
In this article—comprised of a mashup of The Lab’s experience with different 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!
In this article, “the credit union” (remember, an anonymized mashup) sought to standardize wall-to-wall 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 “credit union” 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. Credit union 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. credit-union office workers). After laboring for a year and finding only a dozen RPA-worthy opportunities that delivered minimal gains, the credit union turned to The Lab to help.
Credit union 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 almost 400 “off-the-shelf” commonly-recurring RPA opportunities for installing credit-union robots. But of course, there are countless more—every credit union 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 credit union 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.
The first step to standardizing and then automating credit union 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 credit union 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.
Unlike manufacturing plants, credit unions, like most other knowledge-work organizations, maintain somewhat hidden insightful records of operations. But there is one exception: service tickets. Common systems used in credit unions include Service Now, OnBase, Footprints, Zendesk, SysAid, HappyFox, and others. These create standardized records of operational transactions that bots love. For example, a member 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 credit union members, this tail ranges from long (moderately costly) to even longer (fiendishly costly). Its size thwarts most attempts to manage, or even analyze it.
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 credit union’s total operating margin. The related organizations comprise the core of member 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 member retention. No growth-driven competitor can afford to lose profitable members. 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 members 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 member-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.
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 member: 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. Members 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 credit union—look very good when they approach the member, hat-in-hand, asking for tons of required renewal documentation, to be jointly reviewed ASAP.
Nor does it improve member experience when the account manager is forced to hastily issue (an avoidable) short-term line-of-credit extension. It’s like telling the member, “We couldn’t do this right in the first place, so we’re allowing ourselves a do-over (just like last year).” Members might rightfully wonder, “Hmmm, would the credit union 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 member-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 member.
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 member. 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 member, 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 members 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:
Each item’s status must next be individually updated in the credit union’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 member 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 member 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 “member wrangling.”
First, The Lab mapped and documented the credit union’s existing end-to-end member journeys, 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 member-facing 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 credit union, 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-reportin-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 onscreen 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.
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:
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 member.
If you want to learn more about Robotic Process Automation for credit unions, check out this case study HERE.
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 credit union, its employees, and its members.
What we’ve described here is only the beginning. Once a bot is created, it’s easy to give it more functionality, or add a companion bot, improving member 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 members, detailing exactly what’s needed, and when. And beyond credit-line renewals, The Lab is working with credit-union members to add bots throughout the entire end-to-end sales, lending, and servicing processes.
