The Importance of Alignment between Business and Systems Architecture in Internal Debt Collection

Modern day debt collections is a complex blend of processes, systems, and people. In almost every environment this blend has evolved over the last decades as needs have changed and a wide variety of solutions to operational and business problems have been implemented. A typical result of this evolution is misalignment between the business objectives and strategies of a collections area and the actual execution of those objectives. This misalignment is commonly termed “operational negation” and can dramatically reduce overall collections effectiveness. This article discusses some common areas of operational negation and some ways to avoid pitfalls in these areas.

Business Objectives in Debt Collections
Debt collections environments have three key objectives which drive all activity:

1. Reduction of bad debt
2. Maintain and enhance customer service levels
3. Minimize operational costs (efficiency)

These three objectives are achieved by application of:

1. Collections strategy:

• Who to contact
• When to contact (immediate, delayed) customers in default
• How to contact (letter, SMS, telephone call)  customers in default
• What tone (soft, harsh) to use when contacting customers in default
• How to deal with special situations like policy exceptions (deceased, fraud) and payment arrangements made

• Control of data and information flows between the host systems and the collections systems
• Allocation of accounts to manual or automated actions based on the collections strategy
• Monitoring and control of special situations – like checking whether a customer kept a promise made to pay by a certain date
• Measurement of collectors

• Use of the correct approach as dictated by the strategy when communicating with customers
• Follow the collections procedures and scripted guidelines
• Acceptable levels of competence in customer contact, negotiation and use of systems

Operational negation is most commonly caused by issues relating to collections systems and collectors.

<!–PAGEBREAK–> 

Systems Involved in a Modern Debt Collections Operation

In advanced collections environments there are a number of distinct systems involved.

1. One or more account processing systems – those systems that manage the day to day processing of transactions of accounts. These are often called host systems

2. A strategy control or account management system. This system controls the various credit strategies – including the collections strategy.

3. A collections system. A wide variety of collections system types exist and their functions include the following: 

• Controlling the collections strategy
• Allocating accounts to the actions defined in the strategy
• Control which accounts the collectors are to work
• Control what order or priority the collectors are meant to work those accounts
• Control the actions collectors may take based on their seniority

4. A predictive dialler. This system automates and controls the phone-calling function of collectors thus enhancing productivity and providing statistics which enable management to better measure collector performance.

5. Other systems used for a number of collections related functions. These could include specialist systems designed to deal with policy groups such as suspected fraudulent accounts, collateral seizure or deceased estates as well as general purpose software tools like Microsoft Word or Excel.

This multitude of systems can lead to operational negation through gaps in the data transfer between systems, negation of the actions of one system by another, non-optimal setup of a system or an inappropriate actions on accounts by a collector.

Data Transfer Between Systems

A key area of misalignment occurs when data is transferred between systems. The process to move data from one system to another involves an export program from the source system which creates a file, and an import program which imports that file into the target system. The following items could cause problems in this process:

Data misalignment – Sometimes, the export program specifies different data fields or data fields in a different format to the import program. This leads to the data between the systems being transferred incorrectly. So for example, the export program could export an account number field, which it then passes to the target system – but the target system thinks that the field is a telephone number and interprets it as such – thus calling invalid or incorrect numbers.

<!–PAGEBREAK–>  

To avoid this problem, it is critical that all interface programs – import and export – are properly documented and their alignment compared. It is also critical that these interfaces are adequately tested at time of implementation.

Timing – The timing of the file can be misaligned, so a source system could create the file every day – overwriting it nightly – while the target system might import the file weekly, therefore data is overridden and only one day’s data a week is transferred. Another example of a common timing problem is where the host system creates a file for a collections system but the collections system only imports that file a couple of days later. In the interim, the account may have regularised but a collector who is working off the collection system will contact that customer with information that is a couple of days old – in other words they will tell the customer that they are in arrears and needs to regularise their account where the customer has already done so. This is damaging to customer service and is an unnecessary cost. It can also lead to increased bad debt levels as it detracts from the effectiveness of collectors and therefore those accounts that really need attention may not get the attention they deserve as the collector is spending their time on accounts that do not need attention.

This is a problem that can usually be dealt with through careful analysis and review of overnight batch processing function.

Filters – Many of the import and export programs will limit the number of records that are placed in the transfer file based on a set of filters. For example, an export program from a collections system creating a list of telephone numbers that are meant to be sent to a predictive dialler may have a filter which only allows accounts with valid telephone numbers (defined as fields that have any numeric characters) to be placed in that file. The import program that imports those telephone numbers to the dialler may also apply it’s own filter to the file and only import those accounts on the file that have valid telephone numbers (defined as being more than 6 digits). Since the filter definitions are different (the export program included fields that have any numeric characters while the import program only included fields which have more than 6 digits), there will be accounts that are exported from one system but not imported by the other system.

This is a problem that can be dealt with by ensuring that there are balancing reports which provide some information every time these interfaces pass data between each other, this information should indicate whether accounts have got ‘lost’ in the data transfer process.

Transfer of responsibility – Usually, when an account is passed to a system, the responsibility of taking an action on that account is transferred with it. For example, when a collections system passes an account to a predictive dialler, the responsibility for calling that account then lies with the dialler and the collections system will not pass that account to a manual collections queue somewhere else at the same time. This means that if the dialler fails to call that customer that no one else will have been given the opportunity at the same time to do so. This means that it is possible for accounts to remain uncontacted for a period of time until their delinquency status becomes severe enough that the account is assigned to a collector. Most dialler systems have features such as ‘bad number lists’ and so on which the department manager will then use to re-assign accounts to manual collectors or trace agents as the dialler cannot contact that customer. However, it is also possible that no such report is created, or that the report is not used by the collections area.

This problem can be partially resolved through exception reports that list accounts that have not been worked for 30, 45 or 60 days. Careful focus on the design of the interfaces to try and avoid this problem can also lead to resolution.

<!–PAGEBREAK–>  

Systems Processing – Negation of One System by Another

System processing refers to the actions that a system applies to the accounts under its control. So for example, a host system would send a list of irregular accounts to the collections strategy system, that system would then apply rules to those accounts and create another list of accounts combined with actions and priorities that it passes to the collections system to execute. The collections system will then pass those accounts to collectors to work either directly or through a predictive dialler. The collections system could also create separate lists of accounts that are sent to the print room or SMS generation program to generate contacts to those customers.

The processing of each of these systems could be misaligned with the other systems. For example, a collections strategy system creates a list of accounts with associated priorities and passes that to the collections system, the collections system then re-orders or re-prioritises these accounts before passing them on to the collectors. This leads to operational negation of the collections strategy as the strategy dictated that a certain account be contacted before (or at a higher priority) than another account, but operationally, the other account is contacted first.  

This is a problem that requires careful analysis of the functions of each system specifically and identification of areas of negation.

System Processing – Non-optimal System Setup

Apart from one system undoing the work of another upstream system, it is also common for systems to be set up non-optimally. This could be due to a lack of business understanding by the technical resources who implemented or are controlling the system or it could be due to an entrenched business process that is not appropriate for the system being forced onto the system due to a lack of understanding of how systems and automation should be handled. An example of this is an area purchasing a predictive dialler and then running it in preview mode – allowing collectors to take their time in analysing a case and when ready, starting the call to the customer rather than allowing the dialler to keep putting calls through to collectors with a minimum delay between calls. This example is often seen where there is a lack of understanding of how specialization and automation need to be combined to maximise efficiency.

Another common problem is operational management introducing too much ability for staff to override a system. This is usually done when a system is implemented as the operational staff are uncomfortable with the new system approach and want to leave ‘back doors’ open for themselves in case they come across situations that the system cannot handle.

This problem is best resolved by involving experts in both the business and technical sides of the system and isolating features or functions which should not be part of the system functionality. These should then be removed – either through coding or system parameter changes or through procedural changes with the staff.

Collectors

Collectors are a key part of the execution step of the collections strategy. However, it is possible for there to be misalignment between the instructions by the collections strategy and the actions performed by the collectors. An example of this is the strategy instructing that a customer needs to receive a harsh or very assertive collections call, and the collector contacts the customer but uses a very soft or customer service approach. This could be due to the collector not having the appropriate training and therefore not knowing how to perform a harsh or assertive call, or it could be due to the collections system not providing the collector with the information that the collector needs to use a harsh tone for that collections call.

This problem can be resolved through targeted training of collectors and getting collector’s suggestions on how to improve the systems to maximise their productivity.

Conclusions

The manner in which modern collections departments have changed in the last few decades has led to great potential for business and system misalignment. This can lead to operational negation which can damage the overall collections effectiveness of the department. Some typical reasons for this operational negation are gaps in the data transfer between systems, negation of the actions of one system by another, non-optimal setup of a system or inappropriate actions on accounts by a collector. This article discussed these items and made suggestions as to how these problems could be resolved.