We recently completed a post-mortem review of a project that concluded this past spring to convert the mobile/online banking system of a multi-billion credit union. The conversion itself went fairly smoothly, and credit for that must be given to both the internal team participating in the project and to the support received from the new vendor.
Despite the success, the project team identified a number of issues that could have been handled better. They spent time reflecting on the aspects of the project that went well and helped contribute to its success. I’d like to share some of the ‘lessons learned’ from the project as an aid to other financial institutions preparing for a system conversion such as this.
The project itself took roughly one year to move from contract signing to the ‘go-live’ event that brought customers up on the new system. This post will focus on the execution of the conversion starting from the point that contracts were finalized. A description of the process that started with a decision to make a vendor change and then moved through to the contract negotiation phase will be covered in a separate post.
Resource Allocation
One of the first steps that must be addressed in a project such as this is the creation of an internal team of subject matter experts (SMEs) who will be responsible for all phases of the implementation. This will be a diverse group of people from throughout the company. Aside from the digital banking staff, the project will also rely on people from other areas including IT, operations, marketing, training, risk/compliance, retail, call center, accounting, and perhaps specialized business units such as mortgage lending or credit cards.
The key players (and backups) need to be identified early on, even though their services may only be needed in certain phases of the project. These people will all have their own ‘day jobs’ and may also be supporting other projects that may be running concurrently – something to consider when creating project timelines.
In defining the needed technical resources, keep in mind that the new platform will require integrations with multiple third-party systems (mobile capture, bill pay, P2P, card controls, etc. There will also be data gathering/analysis needs and perhaps custom programming too.
It’s a very common mistake to underestimate resource requirements for a project such as this. That is particularly true if the company hasn’t been through a conversion in the recent past. This is where it can be worthwhile to bring in a third-party consulting firm experienced with conversion projects to assist with the process. An outside party can bring in skilled personnel with recent conversion experience who can devote their full time to the project. This will help reduce the burden on internal staff members.
Project management
Changing digital banking system vendors is a major project. It involves the management of a great many tasks and extensive coordination between internal staff and external vendors. This makes project management a critical function that deserves a great deal of attention from the beginning.
Vendors will typically assign an individual or team from their company to function as a project liaison to help the client through the various phases of the project. It’s important to keep in mind that these people will represent the interests of the vendor. Their main job is to get the project finished as quickly as possible so that they can move on to the next one.
Their interests will also be focused on the technical aspects of the conversion itself. But a project of this nature is much broader in scope and affects many other areas on the client side. This makes the assignment of a dedicated internal project manager extremely important.
Having good, centralized project management software is another requirement for keeping a project of this nature on track. It should an online system that can be readily accessed and updated by all members of the project team.
Leaving individual departments to their own devices to track their parts of the project using tools like Excel worksheets, departmental whiteboards, or sticky notes is an invitation to disaster.
The project management software selected should also support timeline visualizations such as Gantt charts. Putting all project activities on a single, shared timeline is particularly useful when coordinating the activities of different departments.
It’s also important to establish documentation standards early on. Given the large number of decisions that will be made over the course of the installation, you’ll want to document those decisions as they are made. Store these artifacts in your project management software if possible so that they can easily be referenced later on. Trust me – that will ultimately save you a tremendous amount of time and confusion.
Initial Data Gathering
The new vendor will typically kick off the conversion project with a workbook containing a bunch of forms to be filled out. These will gather detailed information about the bank and its systems, vendors, and processes. They should be filled out accurately since they will help define the system installation going forward.
Any data requested for these forms should be pulled from centralized and verified sources. There should also be an internal review and sign-off process on all forms before they are returned to the vendor. If any assumptions are being made or additional follow-up is needed, be sure to document that so that it can be revisited later. Any inaccuracies may come back to haunt you later in terms of system glitches and time lost trying to trace down problems.
As an example, in our project, it wasn’t made clear to the vendor that credit cards were serviced in-house. The vendor assumed that servicing was outsourced, which caused massive problems later in the project when card controls were ready for testing. It took weeks to identify and resolve the issue.
If information is being gathered to support new system features, but sure to first schedule demonstrations of those features for the project team. This is particularly true if changes in existing back-end processes are going to be needed or if new ones will need to be created in order to support the features.
One thing that can prove extremely helpful in the conversion process is having good documentation available on the existing system. This would include a complete list of all features currently being offered and the third-party vendors and integrations that support them (such as bill pay, P2P, A2A, etc). It is also valuable to also have screenshots or wireframe diagrams of every website and mobile app page in the current system, along with process maps that show how information is retrieved and from what sources as those pages load, and what events are triggered as the customer enters and submits new information.
If documentation such as this does not exist for the current system it may seem like a waste of time to put it together for an old system that is going away. But it’s really not. That information will likely be referred to frequently throughout the project and the time spent creating it will be amply repaid later on.
You will also want to put together the exact same documentation on the new system as you move through the project. Yes, I know – no one likes to take the time to document things. But it’s one of those ‘pay me now’ or ‘pay me more later’ things.
The data-gathering phase is also a good time to look at any outstanding “deferred maintenance” items related to internal systems. Any core system cleanup tasks such as purging closed accounts or customer record maintenance should be completed early on so that it doesn’t become a problem later in the project or during the rollout of the new system to customers. We ran into an issue with large numbers of closed accounts still on the core system. The old digital banking system ignored them when returning current balance information, but the new one pulled everything. That caused problems with the size of the data payload that was being returned for some customers having many closed accounts and was causing the app to time out.
It’s also a good time to check to make sure that you have email addresses and cell phone numbers recorded for all customers since that will be needed for future communications and for multi-factor authentication.
Initial Release Planning
The project timeline is going to be constrained by resource availability on both the vendor’s and the bank’s sides, along with conversion windows that other vendors are going to be willing or able to support. Target dates for mock and final conversions will likely be established fairly early on.
Once tentative dates have been established, any blackout dates for employee vacations should be determined and communicated so that your staff can factor that into their personal plans.
Careful thought should be given to what features should be included in the initial product release. There’s always a desire to include as many cool new features and functionality as possible to help justify the conversion to customers. But adding new things creates additional points of failure. It may be better to focus on a core set of ‘must have’ features initially, Others may be added if time permits, or otherwise slated for maintenance releases following the initial rollout.
Decisions should also be made about whether or not to convert inactive users, along with how you intend to define ‘inactive’. Many systems charge on a per-user basis, so it doesn’t make economic sense to bring across customers who are not using your system.
But be careful in how you look at how you define “activity” and consider how different people might be using your current system.
This is where you need to look beyond your own perceptions of how you ‘think’ people are using the system and instead gather data on actual behavior.
You may decide to not convert anyone who hasn’t logged in to the app in the past 180 days, which sounds reasonable on the surface. But that ignores customers who may have active, recurring bill payments or transfers that they set up long ago. Like mortgage payments, for example. They may put those parts of their finances on autopilot so they may not feel a need to log in to the system very often. If you don’t catch these people and include them in your conversion files, you’re going to have some very unhappy customers. Not to mention the potential liability for scheduled payments that didn’t happen post-conversion. We learned that lesson the hard way.
One final point to keep in mind is that while you will need to continue to work with your current digital banking system provider, realize that they may not be particularly helpful going forward. You’re leaving them after all, so they will be focusing their attention on their other clients. Getting their assistance with addressing conversion-related questions or issues may be difficult.
Testing
There’s nothing more important than thoroughly testing the system prior to rollout. Establish a series of test scripts for people to use to systematically work through all features of both the online and mobile applications. All results should be documented, with errors promptly reported to the vendor for resolution. The system vendor should have a robust ticketing system to report and track outstanding issues.
You will need a bunch of fully-provisioned test accounts set up on your core system that will allow people to test all aspects of the application. Don’t expect your project team to test features using their own personal accounts. Most will not be using a broad enough range of bank products & services to fully test the new system.
You might consider creating a ‘testing lab’ that contains a diverse collection of test devices, such as iOS and Android phones and tablets, and computers with different operating systems and browsers. You may also want to include older versions of devices. If possible, pull a report from your existing system to see the device and browser configurations that customers are using today so that you’ll have an idea of what to expect. Your system vendor will have a list of supported devices, operating systems, and browser versions. But customers will use whatever they have, so for support purposes, you’ll need to be prepared to talk to people who are still using antiquated devices.
Rather than having people independently test the system whenever they have time (which is what we did), we concluded afterward that it would have been much more effective to schedule group testing at specific times – in the testing lab that we wished we’d had.
Be aware that some customers may be using third-party software that communicates with your current online banking platform. That may include PFM, business accounting software, or third-party account aggregators. These connections will break when you switch platforms, so you’ll want to proactively communicate with affected customers.
The initial testing will likely be done by project team members, but once you have a stable release it’s helpful to quickly open up testing to a broader “friends & family” group and ultimately begin to pilot it with a select group of customers. Having a broader group of users will help identify ‘edge cases’ that may cause the app to break in ways no one your initial testing group didn’t discover.
You need to plan on having at least one full-scale mock conversion, and perhaps more depending on how the first one goes. This step should be considered mandatory! There was a well-publicized case in the spring of 2022 of a $10+ billion institution that had a digital banking conversion fail on an epic scale. Their customers were without mobile and online banking for weeks. Some internal reports have surfaced that one of their problems was that they didn’t bother to do a mock conversion prior to going live with their new system.
Be sure to carefully review the log files from the mock conversion and follow up on any exceptions. You will also want to have a team of people review samples of individual customer accounts to make sure the information was transferred correctly between the two systems.
Tip: This validation process can largely be automated if you can extract the converted data back out of the new system and load it into a relational database along with the extract files from the old system. After running some transformations you’ll be able to compare the two datasets and easily identify any dropped or changed records as a result of the conversion. This will give you 100% test coverage of the converted data, which will make your auditors very happy. You can then use this same process to validate the files from the final conversion.
Communications
Both external and internal communication strategies need to be defined and timed to be delivered at specific points during the conversion project. Those communications may be sent through various channels, including website, email, text, regular mail, intranet, video, and face-to-face briefings. Many of those communications will need to be repeated over the course of the system rollout.
Internal communications
As the conversion project kicks off it’s a good practice to send out a company-wide announcement that talks about the new system and the benefits that you expect it to bring to customers and to the bank. You want to build excitement and support for the project early on, and provide frequent updates on the project status as key milestones are hit.
The communications should increase in frequency and detail the closer you get to the go-live date. They should include information shared with customers, along with internal details such as training completion dates, requests for volunteers to help test the app, and detailed implementation schedules.
In-person meetings should be held with all branch and call center personnel to talk about the new system and discuss how to handle customer inquiries. These should be very positive and upbeat – again, the goal is to build enthusiasm for the change with your customer support teams which will help promote positive conversations with the customers they interact with.
Customer communications
The first rule of customer communications is that no matter how effectively you communicate, many people either won’t read or won’t remember the message.
Repetition is important in dealing with customers, and you’ll want to reach out using multiple communication channels.
The notification process should begin about 60 days before the anticipated go-live date. If you start communicating too early, people simply won’t remember it.
Many companies start with both an email and physical mailing that announces that the company will be changing digital banking vendors, with an emphasis on how digital users will benefit from the new system in terms of an improved banking experience. Include the ’tentative’ conversion date, and provide information about what information will be converted (particularly things like bill pay payees, external account information, P2P contacts, etc.).
It’s best to keep it general initially, but highlight any actions that customers may need to take in advance of the conversion date. Be sure to include a way to contact your company if they have any information. And remember to share advance copies of what you send to customers with your branch and call center personnel.
This would also be the time to put a ‘coming soon’ landing page on your website that announces the conversion. Emphasize the benefits of the new system and be sure to include an “FAQ” section. This page will be updated frequently as the conversion date nears, and will serve as a convenient reference for customers to quickly get answers to common questions.
At 30 days before launch you should have the conversion date finalized, including the ‘black-out’ period between the time the old system will be turned off and the new one will be available. Here’s where you’ll want to send out details on how to access the new online banking site and when the new mobile app will be available for download from the stores. This should at least be emailed to all customers, and another physical mailing (or at least a postcard mailer) would hurt. You can refer people to the website landing page to learn more.
You may (as we did) have a need to communicate with specific subgroups of customers about issues related to their accounts. For example, we had customers that had characters in either their username or password that the new system wouldn’t support. Or the new system may require multi-factor authentication (MFA) using SMS, and you don’t have a cell number for them. Start communicating with those customers as soon as you can so that they can correct whatever needs to be done before the conversion. Track the results daily, and you may have to resort to calling customers if they don’t respond.
As the go-live date draws near your website landing page for conversion information should now contain a lot of detailed (and well-organized) information about the upcoming events, a robust list of FAQs to provide self-help support, and perhaps videos showing how to use some of the basic features of the new system.
About a week before conversion you’ll want to send out a final email/text reminder about the upcoming blackout dates, and any specific restrictions regarding activities such as cut-off dates for the scheduling of bill payments or external transfers. Instruct the branch and call center personnel to remind customers about the conversion as they speak with them, and put an announcement about it on the IVR for customer support lines.
It doesn’t hurt to over-communicate in situations like this. You might consider sending out a final reminder via both email and SMS the day before the blackout period starts with reminders about when the new system is expected to be available, along with repeat instructions on how to access the new online banking site and download the new mobile app.
Training
The new digital banking vendor should have an extensive library of training for staff in various roles within the organization. There will be initial training for the implementation project team to familiarize them with the features of the new system and the admin consoles. Additional training will be provided to system administrators.
There will also be product training for the customer support staff – particularly the call center, but also branch personnel. There may be both basic and advanced training for those employees. The more advanced training can be used to provide more in-depth knowledge for ‘digital champions’ within both the branches and call center who can provide support for more complex customer questions.
The vendor may also provide in-person training for key areas such as the call center in the days leading up to the actual conversion, and also be on hand to help with questions during the first week after the conversion.
Branch/call center preparedness
In addition to training, there are a variety of other issues to be addressed in readying the branches and call center for the conversion, including:
- Staffing. It should be ‘all hands on deck’ for the first two weeks following the conversion to help address customer issues. This is where setting ‘black-out’ dates for employee vacations early in the project can help ensure staff availability.
- Call center hours. Given the high volume of customer support calls you can expect immediately following the conversion, you may want to consider temporarily extending call center hours (which, of course, adds to the staffing challenge).
- Call center outsourcing. Engaging a 3rd party to assist with overflow and after-hours call center support can help meet customer needs while not overburdening internal staff. Just be sensitive to potential customer privacy concerns if they learn that support has been outsourced. And if the third-party company’s support staff are in a different country (ahh – Panama for instance), make sure they can communicate effectively in English.
- Phone lines and testing. Expect heavy call volume for the first few weeks following conversion, and thoroughly test phone lines and overflow options to make sure they can handle it. I emphasize the testing aspect of this because of issues we experienced with overflow capabilities. Update IVR messaging to include instructions on how to access self-help support options. You may also want to create a separate support queue for digital banking inquiries.
- Chat support. Chat volume will spike following conversion so review your staffing in that area. If you have chatbots deployed, be sure they have been enhanced to be able to respond appropriately to questions regarding the new system.
- Digital customer service platform. If you have a DCS system that supports on-screen collaboration, this is where you’ll see that investment really pay off!
Fraud risk
Depending upon what new features and third-party applications are being included in the new system, it may be necessary to map new applications into the bank’s internal risk monitoring. That will involve new interfaces and testing, and it may take a while for the systems to be fully operational due to the need to collect a baseline of historical transaction information. This can expose the company to additional short-term risk.
A systems conversion often paints a target on your back. Fraudsters will quickly get wind of the change and will be identifying ways to exploit your customers to try to gain access to their accounts. The first couple of weeks following conversion are peak times for potential risks to surface, so be prepared and be extra vigilant.
Contingency planning
With proper planning and attention to detail, the odds are that your conversion will go smoothly with just a little hitch here and there. But as they say:
“Expect the best, prepare for the worst”.
It’s worth spending some time brainstorming with your project team about all of the potential points of failure in the conversion process. List out all that could go wrong, what the impact of each would be, and how you should best respond. Impacts might range from a minor delay in bringing the new system up, to a total meltdown scenario in which you might need to roll back to the old system. Document these discussions so that you have a handy quick-reference guide to help inform your response should things not work out exactly as planned. Having that document could save you from scrambling to try to develop a response in the heat of the moment. And just knowing that you’ve consciously prepared for worst-case scenarios can bring some peace of mind as you head into the conversion.
Final acceptance & go/no go
You’ll ultimately get to the point where it’s decision time. Hopefully, everything will have proceeded in an orderly fashion and there are no unresolved items. What’s more likely is that there were unexpected delays in some areas, and things may have to be pulled from the first release and earmarked for a subsequent ‘phase 2’ maintenance release. Or other pieces were delivered late and consequently haven’t been tested as thoroughly as you would like.
True story: we were notified at the last minute by our vendor that Apple had required that all new apps released in their store be compiled using the latest version of Xcode. The vendor had recompiled the code, but it hadn’t been thoroughly tested. They ‘thought’ it should be fine. What to do? We were just a week before the conversion date at that point, so trying to stop that train would have been next to impossible given some contractual arrangements with the old vendor. We crammed as much last-minute testing in as we could and then had the vendor’s programming team standing by to quickly respond to any bugs that might be discovered during the rollout.
There will be a final decision point where gather your team together for one last pre-conversion meeting to review the status of all the elements of the project. If there are outstanding issues, you discuss the importance of them and the risks of moving forward without having them fully resolved. Also have one final review of the minute-by-minute conversion plan and the responsibilities of each party, from the point where you start the process of bringing down the old system to the point where you bring the new system live.
Then you vote. Go or no-go.
The conversion event
The conversion itself will almost always happen over a weekend. The old system is usually taken offline on a Friday evening. Some features such as bill pay or the ability to schedule external transfers may have been disabled a couple of days early so that newly-initiated transactions had a chance to settle under the old system before it is taken down.
The technical aspects of the conversion should largely be a non-event. For many on the team, it will mainly be a lot of waiting around. The vendor’s technical team will be busy though, and some may be on-site. You’ll need to have a validation team of your own people standing by to validate the results after the data files have been loaded into the new system.
Once everything checks out, the new apps will be released to the Apple/Google stores, the online banking link will go live, and you’ll be open for business using the new system. While champagne may be appropriate at this point, it’s probably better to wait a week or two before having a big celebration.
Post-conversion customer support
The first week after conversion is going to be very stressful for the customer support teams. Even under the best of circumstances, you can still expect a high call volume for the first few days after you go live. Be prepared to reward your people with food and snacks. Try to squeeze in some fun, stress-relieving activities. Have senior managers stop by to express their support and appreciation.
The initial calls will be about simple access questions:
- “I can’t log into online banking” – because you’re using the old link that you bookmarked instead of the new one
- “My mobile app doesn’t work” – because you haven’t downloaded the new app
- “No one told me anything was changing” – we did, but you didn’t read any of our communications
- “The website doesn’t display properly after I log in” – because you’re using a computer/web browser/operating system from the 1990s that isn’t supported by our product
Then the focus of the questions will move to issues related to the use of various features. You may find some actual bugs in the software that the vendor technical support team will need to quickly address. And no matter how much you tested the software before the launch, when you open the system up to a large group you’ll find people using it in ways that no one ever thought of.
If you’re fortunate enough to have chosen a platform that supports near real-time event-level reporting and analytics, use it. Monitor usage statistics continuously for the first few days to quickly identify issues even before the support calls come in, such as login failures for specific platforms or device types. This will help you quickly identify issues, address them with the vendor, and communicate solutions to the support teams.
One thing you absolutely want to do before go-live is to create an internal ticketing system for advanced support issues. This will be used by branch and call center staff to report problems to the digital banking team for resolution. It will allow you to quickly categorize problems, identify solutions, and communicate them back to the front-line customer support teams.
Be sure to monitor social media channels closely, as customers may report support issues there. You’ll want to reply to those quickly since the public can view them and there are reputational risks associated with not being responsive.
One note of caution: we left the old system available in a ‘view-only’ mode over the conversion weekend so that customers could continue checking their balances until the new system came up. Since the old platform was still reading the live core system, all balance and transaction information was correct and current. Customers just could initiate any new actions.
That part was fine. But there were 30 days remaining under the old vendor contract so we just left the old system in that ‘view-only’ state until the contract expired. That was mainly done as a service for business customers so that they could refer back to view old ACH and wire templates if they wanted. We expected that customers would switch to the new platform as soon as it was available – particularly since they wouldn’t be able to transact any new business under the old one.
But it turns out that there are a surprising number of people who just use their mobile app to check balances. So rather than downloading the new app, customers just kept using the old one since it still worked fine for viewing balances and transaction activity.
We did figure out what was happening a few days before the old contract ended. We made a valiant attempt to contact those customers to remind them to switch to the new app, but we couldn’t reach everyone. So there was another flood of angry calls to the call center when access to the old system was shut down. In retrospect, it probably would have been better to just take the old system offline for good as soon as the new one went live.
Post Mortem
Every new project is a learning opportunity. Once the dust has settled from your conversion and people’s lives are more or less back to normal, take some time to pull the project team together and have a debriefing on the project. Discuss what went well and what didn’t. What obstacles were encountered and how were they overcome? How could the conversation team have been better prepared? What things happened that weren’t anticipated?
Take good notes on the discussion and prepare a summary document that summarizes lessons learned and can be used to help guide future projects. And perhaps share that document with your professional peers so that others can benefit from your experience.
If you have a conversion project coming up soon, best of luck with it!
Please feel free to connect with me on LinkedIn or email me at inquiries@digitalvision21.com if you have any questions you’d like to ask.
