Optimal staffing levels depend on service demand, which is volatile. The problem is complicated by the cost of not meeting service, which can vary by call type. In this article, we'll look at and play with a live monte-carlo simulation of staffing levels in a payment collections department.

The Dashboard

In the dashboard below, try entering a different mix of customers, and different collection policies, and click on the "Animate" or "Run" buttons to see the resulting work loads, or "Optimize" to tell the dashboard to come up with the staffing level that optimizes profit. These settings are explained below the dashboard.

The Situation

This dashboard models the following scenario:

• You are running a collections department within a large company, such as a utility, with maybe 50,000 to 100,000 customers
• Customers are sent bills monthly
• Some customers pay by direct debit, many do not (i.e., they are sent a bill, and pay by cheque or bank transfer)
• Most customers pay on time (i.e., within 30 days), but some do not
• To collect late payments, you have a staff that can either send letters, or call people (of course, more actions would be possible in a real application)
• These interventions have a cost, and have varying success rates
• The whole system is subject to some randomness, so the simulation results will be different each time

Settings you can change

Customer segments:

• At the bottom left, below the three blue buttons, you can set the relative size, and the payment behaviour, for three segments of customers
• The segments are direct debit customers (15% of customers by default), fast payers (25%), those who typically need a reminder (30%), and those who need a call (also 30%)
• You can change these fractions, but they must add up to 1
• For each of these segments, you can define how many days they typically take to pay, by specifying both a mean and standard deviation

Interventions:

• There are two types of interventions in the model: reminders (by e-mail or post), and calls; see the centre section of the input panel, below the graphs
• For each type of intervention, you can define when the event is triggered (number of days after bill was sent out); by default, this is 30 days for a reminder, and 45 days for a call
• You can also define the typical response from these interventions, in terms of a mean and standard deviation number of days after the intervention to when the payment comes in; this is 20 days for a reminder, and 10 days for a call

Staffing levels and productivity:

• In the centre section, you can specify the number of staff (default 10) and their annual salary (default £10,000)
• You can also specify their productivity (default 16 calls per day, assumes that e-mail reminders are automated and thus require no staff)

Customers and other simulation parameters:

• At the right side of the input panel, you can enter a number of other parameters
• The number of customers is by default 5,000
• The average size of each monthly bill is £50.00 by default
• The annual discount rate (for calculating NPV) is a whopping 50% by default (to exaggerate the timing effect of collecting sooner)
• The profit margin is by default 100%, so that all revenue is counted in the NPV; set this to lower (e.g., .3 for 30%) to reflect profit as a slice of revenue instead
• Days to simulate controls the number of days the model simulates, and is 120 by default; this will affect NPV, and should be at least one billing cycle (30 days plus the maximum number of days to collect errant bills)

Running the Simulation and Viewing Results

Click on the blue "Run" button to run the simulation. The "Animate" button does the same, but updates the graphs during the simulation, which looks cool but takes a bit longer to run.

Click on the line graph to switch between three different views:

1. Number of bills: sent out per day, paid, reminded by post, chased after by calls, and "shortage" (not acted upon because of insufficient staff on that day)
2. Cash flow,: amount collected each month, collection costs (staff), and profit (difference between the two)
3. Staff utilization: the fraction of time that staff are busy; note they are idle until day 45, when the first collection interventions are triggered

The other graphs show gauges of daily utilization, and average bill age, and a bar graph of bills paid, reminders sent, and calls made each day of the simulation. The gauges and bar graph are really only meaningful during the animation, as they show daily values. Note again the idle staff until the calls kick in.

Optimizing

If you click the blue "Optimize" button, the dashboard will try to find the staffing level that results in the highest NPV, given the settings you have chosen for all the other parameters.

This may result in a different number of staff each time you optimize, because of the randomness inherent in each simulation.

The optimizer seems to come up with errant values for extreme values for some settings (to be explored).

Lessons Learned

In exploring this simulation, a few insights become apparent:

• The optimal staff level is not the one that elminates shortages, but results in some shortages, because the loss of revenue needs to be balanced against the cost of underutilized staff
• Moving a larger share of customers onto direct debit or into fast-payer has larger impact than changing the parameters around follow-up actions
• Increasing productivity (and then reducing staff) has a bigger effect on profitability than some other actions
• A monte-carlo simulation such as this is a good way to explore solutions for this kind of problem, and much easier to use than a purely mathematical approach such as queueing theory

Applications for this

This simulation approach could be used in many situations where demand is uncertain or variable, or where the impact of company actions is variable or uncertain.

Some other example applications might include:

• Marketing campaigns that rely on follow-up action
• Inventory stock policies
• Online hosting capacity management
• Special offers
• Staffing levels for service-based businesses

Technology Used

This dashboard was written in JavaScript, and uses the D3 library for the graphics.