Design of digital sales process

Ivica Marija

The challenge I had was designing a new, “digitalized” sales process for lending products for  large corporate clients. In my Bank, “Large Corporates” refer to companies that have more  than €500 million yearly turnaround and require multi-million financing deals for their needs.  Negotiations and contracts are commonly very complex and can last for weeks or months.  Despite having many systems available, the whole process was still mostly manual: data  required for a credit application was manually copy-pasted from source systems to  predefined forms in Word; calculations of exposures and limits were calculated in variety of  Excel sheets and also copy pasted to these forms, and these forms were sent by e-mail to  different approvers who would review them, print them, sign them and send it back in pdf  format. Finally, data from contracts was manually entered to booking systems. Only this task,  due to complexity of contracts (>100 pages) was usually taking 4-8 hours(!).    The initial set of requirements we got could be summarized with famous quote from Henry  Ford: “give me faster horses”. Despite having very modern digital workflow systems and  Customer Relationship Management (CRM) system, everyone expected “easier way of  handling documents”. “Problems” that were identified were mostly around >20 systems being  used, primarily to extract data needed for the application, but nobody thought about big  picture. We could do that, of course, but that wouldn’t be digitalized and automated process.    In order to give participants the sense of complexity, I decided to use visualization – a tool  well described in video of Angela Myer in Week 1. I often use Visualization, primarily for my  own better understanding of a problem, but also to ensure that there is a shared  understanding of the problem and possible solutions among groups of stakeholders. The  approach is very useful when stakeholders are diverse, in my case businesspeople from a  bank, and IT people from IT division.    In this particular case, I painted the entire process on the wall in a way that I:

1) highlighted the number of different tools they actually use to extract data they need

for an application – indicating that the problem is not in these tools, but in the fact that  they need to manually copy-paste data from different tools into application forms.

2) Listed different forms that are used for different approval bodies in several steps of

the process – indicating number of data items that are in common to these forms (i.e.  client data) – that are repeatedly copy-pasted into these forms.

3) Listed documents client needs to provide for the approval, which we now store for

compliance reasons, whereas we don’t need documents, but information from these  documents (i.e. confirmation from Commercial Register that company is registered) in  order to proceed with the application.

4) Visualized document flow and number of e-mails, printing, physical signing of a

document and again scanning and forwarding – in order to “collect all signatures” for  the approval – whereas “approval” in form of confirmation in a tool would be sufficient.

Needless to say – no PowerPoint slides could describe the volume of waste we created in  every single step of credit approval process. Picture hardly fit on 10x2m wall (I had to repaint  it several times to fit it properly). But, I managed to made my point: problem is not in  systems, but in the way we approach the process. By integrating data sources to the  workflow and using built-in capabilities of CRM tool, administrative overhead could be  decreased by more than 90%! Moreover, the most of information we require from a client in  the form of a document – we can get by ourselves from public registries – automatically. This  would dramatically reduce the amount of work for our clients too and reduce waiting time  from days or weeks to minutes or even seconds.

The second phase was, however, more complex and more important. Now we knew the  problem – but what is the solution? This took several weeks of discussions in smaller groups  and common meetings among groups to figure out:

1) Which data we really need? In some cases, account managers collected a lot of

information about the deal, hoping this will help the case and get the approval from  the investment committee – whereas committee members admitted they don’t need  these data to make their decision at all.

2) Which controls we need? The whole process is rather collaborative, especially for

more complex deals, and there is no classical “flow” (handover). Squeezing this into a  workflow would actually make it worse. So, we needed to be careful with defining  process steps and decided to minimize them to data collection and approval only –  despite the fact there are several formal approvals needed.

3) How to organize the data in a screen – especially on different screen sizes

(smartphones/laptops/monitors) to make the overview possible. Since we talk about  250 different data fields, among which there are “free text” fields containing several  sentences, images and graphs – this was the most challenging one.

Although I used visualization before, only now I got the true power of it. It was also very  interesting to observe how it also helped clients to involve themselves more. Previously,  “specifications” were written in words. And, it takes thousands of words to describe – and  later, read a requirement. And nobody has time for that. Requirements were written  superficially and understood accordingly – wrong. Once when clients actually saw the vast  number of systems they use and the number of interactions they made – with picture – only  then they realized the problem they had.    On the other hand, something that would previously be written as “simple” requirement (i.e. “I  want all the data on one screen”), brought them to the understanding that it is them who  need to make priority which datasets they want where, based on the importance. Because:  all the data couldn’t fit into a screen (especially smartphone screen); scrolling was needed,  so the data that is more important – you should put to the top.    Despite the fact that we did a lot of painting, the whole process proved to be very light in the  documentation – and yet, more descriptive. Additionally, it brought people together and made  the approach collaborative. Businesspeople understood limitations a system has, but also  benefits it can bring if we use it properly. IT people got better understanding of client needs –  and come with very valuable ideas that helped clients make better choices. And on the top: it  wasn’t boring at all – it was actually fun!     Finally: there was no (bad) surprises about the final outcome. Clients knew exactly how the  new system will look like and how will they use it. There was no need for user manuals nor  training either – they know how to use the system, because they designed it together.    The only thing I would do differently in the future is: jumping immediately to visualization,  without spending time on interviews and data gathering. A high-level overview is important at  the beginning, but that’s all. Once when painting starts – there is no need for further “data  gathering” because clients can do quite a lot by themselves too.     Of course, some data gathering is still needed (i.e. in this case we needed to list all data  source systems, and data we need to collect), but visualization helped us determine what we  really need – and what we thought we need. This made data gathering rather slim.  Nevertheless, the common opinion once we finished with design was: none of us could  imagined the new process the way it turned out – if we didn’t use the visualization. What we  understood as a problem, and what we envisioned as a solution before we turned to  visualization was completely different from the final outcome. Visualisation helped us

understand the big picture, understand the impact different teams have on each other and  design much better solution.

