Maximizing ROI on eSignature implementations

John Fraser, president and CEO of Core, a consulting firm, discussed with a live ESRA audience how to set up an e-signature project the right way from the beginning, so that you don’t pay a long-term price for mistakes made in the early stages.

He began with a basic analogy to politics: “Imagine you’re leaving ESRA today. You’re going to bring home the bacon with an e-signature project. You talk to management. They’re excited. You put it in process and get an estimate. It’s $10 million, or $30 million, or $50 million. And you’re stuck with pork instead of bacon, because you have the pork of 35 different organizations trying to stuff things into your e-signature project.”

He added: “I’ve been part of hundreds of e-signature projects, so I understand what can go wrong.”

Fraser’s background

Before continuing, Fraser led the audience to his current position. He recalled: “I got first computer at 4, started programing at 7, began my first computer business at 12, and by 19 I had reverse-engineered Apple products and was selling clones to the market. Apple wasn’t very happy with me, so I decided to get out of that business and went into manufacturing, where I did computer-guided robotics.

“I missed working with people, so I went into financial services, where I learned two things: 1) financial services seemed to be about 10 years behind the rest of the world, including manufacturing, when it came to digitization, and 2) while I was good at technology, my passion was around solving business problems.

“So that brought me to where I am now. I had a chance to work on an e-signature project, but I failed miserably at the first two attempts. After two years, four different project, six months apiece, I successfully delivered my first e-signature product with a vendor to a major bank.”

He continued: “I really liked that. I realized that all these companies have business problems and e-signature helps solve them. I’ve worked with 6 out of the top 10 US banks, 3 of the top 5 Canadian banks, many smaller banks, financial services firms, credit unions, healthcare, manufacturing, and even a trucking company.

“That first project I would have done differently today. I was lucky. It was a $25 million behemoth.”

Beware scope creep

Software programmers often talk about “feature creep,” a process by which a seemingly simple application can become bloated and unwieldy by the time multiple stakeholders give their input. In the e-signature world, Fraser explained, “typical e-sign projects have scope creep.”

He continued: “Are the docs in the right format? Or do they need to be on version 6 when they’re on version 4? And then the forms team says they’d like to consolidate their forms. And they want to deal with hundreds of forms.

“And then they say they rely on people to figure out which documents are needed for each case, so they have to automate that, and automate the order in which documents are presented. And then they realize there are problems with a form. In the paper world, you can scratch something out and initial next to it – not so easy with e-signatures.

“And then they have to change the data entry system to accommodate that. Maybe it’s an internal team that won’t charge much, or you have a vendor partner with an origination system and you’re struggling getting them to make changes.

“Once you figure all that out, then you have to figure out the document workflow. With a bank, maybe they’re stored somewhere. So then the records retention people come in and say they should be saved for a certain amount of time after account closure. So then they have to implement digital records retention.”

After that whirlwind explanation, Fraser noted: “That’s what happened with my first project. My recommendation is to never start that way.

“The way I like to say it is, it’s your project. Use the KISS principle: keep it simple, stupid. It’s okay to start with a non-integrated solution. You might think you need to, but the second you talk about integration, you’re bringing in scope creep.

“Justify each bolt-on project. If you decide to go for integration, justify it. How long does it take for someone to go through all the documents and manually upload them? And what does it cost to integrate them? What’s the labor savings? Or is it still cheaper to have someone do the manual integration?”

Fraser added: “Steve Jobs said to think different, but I’m telling you not to think different about e-signatures.”

He continued: “Companies will say not to include vendors when creating requirements for an e-signature project. There are out-of-box solutions out there that are designing the UI, the architecture, the scalability that way for a reason. To think your organization will come up with a better solution for a requirement is a little narcissistic. Leverage the experts. Don’t think outside the box.”

However, Fraser said, “you still need to have a roadmap. I’m not saying to never have integration. I’m saying to build for today but consider tomorrow. You don’t have to integrate all the systems on day one.

“For example, it can be expensive to use people to transfer documents from one system to another, but the solutions out there make it really easy. If you’re in a pilot mode, why bother automating the human process unless you know it works and it will make customers happy?

“Paper exceptions are acceptable. I don’t know how many times I’ve seen an organization build in ways to deal with every single piece of paper they have. Sounds great, because they want to become a paperless company, but the truth is that probably 20% of your documents represent 80% of your volume. Automate them first. They’re the easy ones.

“That really rare case where you have 45 signers to open an account? Don’t build in a way to deal with that because you’ll quickly double or triple your costs.

“That applies even to something as simple as adding or removing documents during a signing process. I push people away from that for the initial implementation because it’s easier to toss it and start the process over from scratch. For example, if my name is wrong on a form, rather than removing and replacing it, maybe it’s spelled wrong elsewhere too, so just recreate the package and move forward.

“I’ve seen estimates double with something like that. The vendors support it, which is great, but then you have to deal with which document is in the package, which isn’t, and create an unnecessary work flow.”

Vendor criteria for ROI

Fraser also explained the various criteria that should be considered when evaluating the vendor criteria for an ROI analysis of a new e-signature project. “Start with something you can use out of the box. You can get many of them set up and trained for a couple documents in 10 minutes. Just make sure the product has integration capabilities.

“You also want cloud hosting, but there is an exception: hosted options give you a greater selection of vendors, but do not make your project the poster child for your organization to move from on-premises to cloud. I’ve seen projects delayed 18 months because someone decides the whole organization has to now move to the cloud.”

Fraser continued: “Look for products that have workflow notifications built in, rather than choosing a product that has a framework that lets you decide who signs what, where, and when.

“I can print to paper, print to PDF, or print to e-sign, which drops it into the document. That’s a cheap way to do integration. It’s not super sophisticated because services integration would be more robust, but it’s a great starting point.

“Use templates for common documents. With the off-the-shelf products, you have to define a lot of things, but with templates, you don’t have to do that. You can apply a template to multiple documents.”

He concluded: “And find products that have authentication and evidence collection, because those things are important if you have to go to court. Or even better, they prevent you from going to court because you can produce everything to prove that the person did you said what they did.”

Real ROI cases

Fraser then discussed some real world examples of successful e-signature ROI, starting with a healthcare company. He explained: “They had over 100 pages of documents that they had to review to hire someone. They were hiring 10 people a week, and they were remote, so getting them to the office was difficult. I came in, did a one-hour training with the general manager, and said, ‘Here you go, take it away.’

“In a few days, they had automated their onboarding process. Hundreds of fields on the documents and dozens of signatures. Used to take close to 14 days to complete the process, and we cut it to 3.”

The next one was a large bank. “They had e-signatures in another area,” Fraser said. “It was a small business line that was doing stock purchase agreements. They were spending tons of money with FedEx and UPS. They had to get documents out and back as fast as possible. Overnight delivery both ways, plus plenty of phone calls.

“I had a 1-hour meeting with them and showed them the process and the training the next day. Soon they were saving thousands on postage and labor.”

The last example was a mid-sized, multi-regional credit union. Fraser remembered: “I was going to do a 2-day session with hem. They had an in-house system that they were going to integrate with a vendor. By the end of day one, we had fully integrated this solution.

“They went off and solidified some details and on day two, we moved on to another use case. They had a blank forms repository of over 100 documents. And thankfully, they knew which documents were used most, and on day two, we automated less than 10 of then. However, they represented more than 90% of the volume of their blank form documents.”

Fraser summed up: “I’ve worked with people who are on year 2 or year 3 of projects, but it’s because scope creep has occurred.”

Final tips for project success and ROI

Fraser wrapped up his talk before the Q&A with some final tips. The first one: “Challenge the architecture and integration assumptions in your company. I don’t care which area you’re in. Don’t let people assume that the document generation platform has to be replaced. Don’t let people assume that you have to integrate with that origination system, or that document implementation has to happen today.”

The second one: “Stick to standalone tablets, especially if you’re doing a proof of concept. It takes time and energy to figure out the collaboration between hardware and software. That’s not where you want to start with e-signature.”

Third: “Engage legal and compliance early. They love being engaged early. They don’t like it when requirements are built up and the project is thrown on their desk three years later. Let them be part of the process and understand the value from the consultant’s perspective.”

Fourth: “Identify the executive chef early. You can have too many cooks in the kitchen. Just because you want to do an enterprise e-signature project doesn’t mean you need to bring in people from 20 different business lines and make a soup. That’s really complicated. Instead, find a project you can justify, buy a solution out of the box, keep the vendor engaged, get the integration going, and then expand to other business lines.

“If you use that approach, it will be cheap to get it going, it will be fast to implement, and the cost associated with making tweaks for other business units will be much less because it’s already in your business.”

Fifth, and finally: “Ask what we do today. It seems like many people want to collect a blood sample for DNA to authenticate someone but they’re okay with sending documents in the mail to a random address and getting a chicken scratch signature back. Why are they okay with that but they want DNA to authenticate someone for a digital signature?”

Q&A:

Q: One of the concerns is that if develop the solution at the time in an expeditious manner that you’re creating a bigger problem in the long run. How have you addressed that in the past?

A: It goes back to “Build for today, consider tomorrow.” You can spend years in requirements processes and whittle your vendor selection down to one or two by building in all this stuff in at once. That’s not the right approach. I think that having an architecture where you can get to that long-term solution of full integration and make sure that what you’re not doing is putting yourself in a box and forcing some poor decisions down the road.

If you make one decision and you have to switch gears, as long as you stick with mostly out-of-the-box capabilities, there are a lot of universal aspects between the different vendors. You can switch if you have to, so don’t get into analysis paralysis.

Q: What do you say to stakeholders when you have an architect who wants to do a lot of fancy things? How do you make sure it’s successful?

A: Well, it’s not always successful. I’m going on two- or three-year relationships with some people. Each requirement should justify its own ROI. That’s a tough concept, especially at large organizations where they look at it as a large capex project and want to bundle everything into that.

It’s not an easy sell, but it comes down to: What’s the cost of using people to do this in the short term? And let’s look at the process today. We’re still paying the employee today to do that process manually today, so when you look at using people as that integration point in the short term, you can see that it’s stepping stone to the long term.

It might take two years to get to the point where you can justify eliminating the labor needed to do that integration and the cost associated with it. It’s not a 100% guarantee but most of the time when you talk to senior leadership, that resonates well with them because they’re used to using people for their business processes today.