Digital Transformation: The Technology Problem

This is the fifth post in a series looking at what keeps financial services organizations from creating more TurboTax-like experiences for their customers. (If you want to start at the beginning, click here for my inaugural post, which provides an overview.)

Just to recap, what’s blocking them is as many as seven key problem areas:

  1. The Demographic Problem
  2. The Process Problem
  3. The Business Case Problem
  4. The Technology Problem
  5. The Content Modularization Problem
  6. The Compliance Problem
  7. The Digital Transformation "Tunnel Vision" Problem

We’re now down to the fourth item on this list: the technology problem.

In the typical legacy environment, a complex array of tools is being used to capture and transfer customer data. Even in the most disciplined environments, it’s difficult to align under standards and build a consistent infrastructure that doesn’t cost an arm and a leg to implement and support. To make matters more complex, it’s currently untenable for a single tool to provide the entire platform for data capture and processing.


High-level Architecture for Customer Experience Technology Tools


In the technology environments of most organizations, several categories of technology are currently being forced to work together—whether they want to or not. The picture below shows a high-level architecture, designed to help bucket the different capabilities that have a seat at the table in this customer experience conversation:

On the far left, you have runtime inputs. These are the actual environments where an initial transaction request is being generated and data is being captured. In some situations, this might be a business system that a financial services representative uses to enter customer data, or a client-facing portal on the web or in a mobile application. In the best-case scenario, these systems are capturing all the necessary data for a request, and then passing that data downstream for approval and processing. Worst case, these systems are maintained completely separately from the actual forms environment and are acting as an independent forms silo.

The center of the figure shows a variety of capabilities that are needed for creating, maintaining, and storing forms elements, and for requesting changes to those elements. It’s likely that forms owners in the business have tools they use to track and maintain forms in Word documents and Excel spreadsheets. They’re likely using email as the so-called “poor man’s workflow” tool to obtain review and approval of changes to forms elements. In larger organizations, however, it’s likely that a variety of workflow capabilities have been developed around the forms creation and maintenance process. It’s also likely that your web content management and document composition systems are housing forms for online access or for distribution as a part of a print onboarding kit.

On the far right are listed a variety of output channels for forms, including the multi-channel output that you would ordinarily think of as delivery channels. It also includes items such as long-term archival for the form template or for executed forms, e-sign for applicable forms, and e-transmittal tools in the organization.

Finally, at the base of the figure is the resource library. This is a bucket for holding all things related to the care and feeding of the actual forms. These can be forms templates, or pieces of those templates if you are doing modular design of the forms and form processes.

Large, complex organizations likely have a host of siloed, ad-hoc tools that have been developed to support duplicative processes across multiple lines of business. For example, how specialized does a transfer of assets form need to be for each product line? The complexity of the technology environment compounds with the process problem (discussed here) to resist consolidation and change. It’s difficult to change the process without touching the technology, and vice versa.

To impact the technology problem at your organization, you’ll first need to inventory the tools currently being used to support your forms. You can use a simple, high-level architecture (like the one above) to bucket those tools. Then, even if you can’t standardize everything, try to standardize the system that provides the care and feeding for the forms. If the forms are all being created and updated in a central environment, it’s easier to hook the other systems to that point so that the forms being delivered to clients are up to date and consistent. As you mature in the process re-design, you can then begin to standardize on workflow tools and delivery options. A central design environment also allows you move toward a digital-first design strategy capable of supporting the long tail of paper and PDF delivery. And, finally, it allows you to implement greater consistency in the look and feel of data capture environments, regardless of the channel they’re exposed through—and when you get down to it, that’s what your Turbo Tax-conditioned customers first see, and interact with in their online experience with your company.




Rich Medina
Lane Severson
I’m a Practice Leader, managing relationships with Doculabs’ West Coast clients to improve information management and security.