Estimated reading time: 5 minutes
In collections, procedures regulate how you deal with customers and ensure a consistent approach to collecting outstanding invoices.
With procedures you can better automate the processes in collections and at the same time strengthen the customer relationship. By working with templates, reminders and dunning letters can be sent much more quickly and with attention to the specific customer.
You can schedule certain actions before the invoice due date is reached. Think of sending out an invoice overview a few days before the invoice due date. But of course, actions after this due date, such as sending reminders or scheduling phone calls, also belong to the collection process and outsourcing.
An example of a procedure will go a long way to clarify this. Suppose we draw up this standard procedure with the following procedural steps:
- Procedure Step 1 (7 days overdue) – First e-mail reminder 7 days after due date
- Procedure Step 2 (15 days overdue) – First telephone call 15 days after due date
- Procedure Step 3 (21 days overdue) – Second telephone call 21 days after due date
- Procedure Step 4 (40 days overdue) – Outsourcing to a collection agency
The above example consists of four simple procedural steps. Step 1 states that a first reminder is sent to the customer by e-mail, kindly asking them to pay the invoice. This procedure step starts seven days after the due date. After 15 days past the due date, Step 2 starts automatically, whereby a first phone call is made to the customer. After 21 days, Step 3 starts, and the customer is called a second time. If the invoice remains unpaid 40 days after the due date, with Step 4 the file is outsourced to a collection agency, which will take care of the further follow-up.
The standard procedure flow in iController
Procedures are central to iController. From the functional set-up, we work together with the customer to ‘think up’ procedures. These procedures have certain customer and document-specific conditions and consist of different procedural steps, to which concrete actions are attached.
Good to know: in iController you don’t have to check the procedure steps manually for each customer; instead, you get suggested actions on a worksheet. Then you can choose to process these procedural steps and corresponding actions automatically or not.
But how does iController determine which procedure, and which procedure step, a customer is in? This is actually quite simple: we look at the oldest open invoice and the document status (as we determine it when drawing up the procedures).
As soon as your customer has at least one open invoice that is past its due date – in other words, the due date of the invoice has been reached – iController will mark that due date as the starting point and link the customer to a certain procedure and step. In iController we use the metric ‘Days In Procedure’ or the D.I.P. In most cases, the D.I.P. is equal to the number of days an invoice is overdue. If an invoice is 30 days overdue and unpaid, the D.I.P. is 30.
If a customer has at least one outstanding invoice that is past due, the ‘Days In Procedure’ counter or the D.I.P. will start running. In the example above, when the D.I.P. is 15, the system will automatically switch to the second procedure step.
If there are other outstanding invoices with the same customer, they follow the same procedure, but they do not influence the determination of the procedure step. They do come into play, for example, when the oldest invoice has been archived (which in most cases means paid). The iController software then automatically starts looking again for the oldest outstanding invoice and recalculates the procedure workflow.
A characteristic of this standard procedure workflow is that it does not take into account whether procedure steps have been processed or not. The software does not ‘wait’ to move on to the next procedure step. It only looks at the number of days overdue and thus the D.I.P. to determine the current procedure step.
But in some cases, this standard procedure flow offers too little flexibility.
Step-by-step procedures
We wanted to respond to this and make the procedure flows even better with a new procedure behaviour. We are therefore launching step-by-step procedures. In this form, we only move to the next procedure step when the current procedure step has been executed. In other words, the procedure will wait until you take action.
An example clarifies what this means:
One of your customers has five invoices, four of which are overdue. iController has assigned the (standard) procedure ‘New Customers’ to the customer, which generates a statement of account.
The customer receives this statement of account but disputes one of the invoices. This invoice is moved in iController to the document status ‘Dispute’. Based on the dispute status of this document, a secondary procedure is triggered. In a first step within this secondary procedure, an e-mail is immediately sent to the customer’s representative, informing him/her of the dispute. A few days later, the second step of the dispute procedure is activated, sending an e-mail to the sales manager, which escalates. Both the primary ‘New Customer’ procedure and any secondary procedure run concurrently.
Several active procedures are possible per customer
From now on therefore, iController allows several procedures to be active per client. Besides the standard, primary procedure, there is no limit to the number of secondary procedures that can be executed at the same time for one client.
iController automatically starts a primary procedure based on the predefined logic during the functional set-up. The secondary or step-by-step procedures start or stop when certain conditions are met, for example when an invoice is in dispute.
As a result, we have changed the timeline on the client page, which from now on will not only show a client’s primary procedure, but also any secondary procedure that is in progress.
Start of procedures: you have to choose
When you create a new procedure in iController, you will have to make certain choices in the settings. You have to choose how the procedure starts – via the procedure assignment (maximum one per customer) or when certain start and stop conditions are fulfilled (several possible per customer) – and how the procedure will run – days in procedure or days after the previous step.
If you would like further explanation and/or wish to adjust existing procedures or to create new procedures, please contact us. We are happy to help you organise your collections process as efficiently as possible.
