Let’s start with some definitions:
- A measurement to how cold it is.
- The colder it is outside, the more DDays there are.
- Essentially the same for all your customers (assuming you only have 1 Degree Day Area in Ignite)
- A customer’s ‘Consumption Rate’.
- Different for each customer based on a variety of factors such as the size of their home, how well it is insulated, etc.
- Technically it is the # of Degree Days it takes to burn 1 gallon of fuel.
- The lower the K Factor, the MORE fuel a customer will use:
- If they were 30 DDays yesterday and a customer’s K Factor is a 5, then that customer would have used 6 gallons of fuel that day.
- If another customer’s K Factor was a 7.5, then he would have used 4 gallons of fuel that day.
- A customer’s consumption rate (i.e. K Factor) is different at different times of the year. This is why there are K Factors for the different seasons (we’ll discuss this further later in this article).
What types of things influence a customer’s usage (i.e. K Factor)?
First let’s talk about simple/obvious variables:
- The size of the house / building.
- How old it is and how well it is insulated.
- If a little old lady lives there and puts her heat on 72° vs. a working husband and wife who turn the heat down when they are at work.
- Wind (which is normally not factored into the DDay total).
Now some things you may not think of:
- The # of appliances running in the home (i.e. computers). These will emit heat.
- The amount of solar radiation hitting the home. We all know what the greenhouse effect is.
- Relative humidity in the home (i.e. how comfortable the homeowner ‘feels’).
- College students returning for Christmas break or a new baby being born or a homeowner losing their job and now they heat the house during the day, etc.
The first thing you should be aware of if you didn’t know it already is that the Degree Day System is not perfect. There are some inherit problems / known issues with the system. First, we are predicting a customer’s usage based on past performance and just like they say with the stock market, past performance is no indication of what will happen in the future. Secondly and more importantly, heating requirements are not linear which means a K Factor that is accurate when the temperature is 25° is not accurate when the temperature is 0°. Or in other words, a customer whose K Factor is a 4.0 all winter long when your average temperature is say 20 degrees will actually have a lower K Factor when the average temperature is zero degrees. So, if you have a week of really cold weather, you can expect your customers will use more than the system estimates based on the Degree Days. And because the point at which the usage changes is different at each house (i.e. it could be at 15 degrees at my house and 10 degrees at your house depending on the amount of insulation, etc.), there really isn’t anything the Degree Day System can do about it.
O.K., now that we have some of the basics covered, let’s talk about what is happening inside Ignite. Here is a sample customer from Ignite:
You will see there are 5 different ‘K Factor’ fields: Winter, Summer, Spring, Fall and Current. Ignite always uses the ‘Current K Factor’ to calculate the customer’s next delivery. The Winter, Spring, Summer and Fall K Factors are holding cells to store what the K Factor is the next time we change to that season. So, if you look at the screen shot above, you will see the column on the right side nicely describes exactly how the system works:
The ‘Optimum Delivery’ times the ‘Current K Factor’ equals the ‘DDays Between Delivs’.
So, 165 x 5.87 = 969.
Then the ‘DDays Between Delivs’ plus the ‘Last DDay’ equals the ‘Next DDay’.
So 969 + 4758 = 5727.
The ‘DDays Away’ field tells us how many degree days away this customer is from needing a delivery.
The ‘Run Out DDay’ field tells us at what Degree Day this customer will run out of fuel.
The ‘Estimated Delivery’ field tells us what Ignite expects the customer to take if we made a delivery today.
The ‘Currently in Tank’ tells us what Ignite says is in the customer’s tank at this time.
And the ‘% Full’ field tells us what percentage full the customer’s tank is.
Knowing this information, the software can then calculate the ‘Estimated Next Delivery Date’ by looking at the average # of DDays for each day of the year and then figuring out how many days away the customer is from needing a delivery.
So if I am a Customer Service Representative and I have a customer on the phone and he says he does not have any heat, then based on the customer’s tank being 87% full, I can safely assume this customer needs a service technician to go to their house because it is highly unlikely the customer is out of fuel.
What Happens When a Delivery Is Posted?
Above we talked about the various fields on the customer screen. Now let’s talk about what happens when you post a delivery to a customer’s account. The first thing to consider is what your ‘K Factor Recalculation Settings’ setup table looks like. In this setup table, you can setup what the maximum percentage you want to allow the system to increase a customer’s K Factor. You also can setup whether you want the system to drop to the lowest K Factor or only go down ‘x’ percent when a customer’s K Factor should be lowered. This table is very powerful because you can also have different values for different times of the year. So if you don’t want a customer’s K Factor to be modified in the month of April, you could set it up that way.
Assuming the customer’s ‘Recalculate K Factor’ box is checked off on their account AND assuming the customer’s K Factor wasn’t locked because either the last delivery was a partial fill or because you chose to lock K Factors when you changed K Factor seasons, then Ignite will recalculate the customer’s K Factor. To do this, Ignite uses a formula to calculate a weighted average of 4 different K Factors. It uses the ‘Actual K Factor’ for that delivery and counts it 40% towards the new K Factor. It uses the customer’s ‘Current K Factor’ that was on the customer’s account at the time the delivery was posted and counts that 40% towards the new K Factor. Then it uses the ‘Previous K Factor’ for 15% and the ‘2ndPrevious K Factor’ for 5% of the calculation. Once it has that new K Factor, it will then look at the ‘K Factor Recalculation Table’ and make sure this new K Factor didn’t go up too high and/or whether it needs to drop to the lowest K Factor, etc. This new K Factor then gets put into the customer’s ‘Current K Factor’ field. And what was in the ‘Current K Factor’ field gets moved to the ‘Previous K Factor’ field and what was in the ‘Previous K Factor’ field gets moved into the ‘2ndPrevious K Factor’ field.
Delivery History Screen
There is sometimes confusion as to what the Delivery History screen is actually showing you. Here is a sample screen shot:
Now if we look at the higlighted record, we will see the customer had 104.7 gallons delivered on 3/18/11. The ‘DDays’ column of 786 tells us that between 2/19/11 and 3/18/11, 786 Degree Days elapsed. If we then divide 786 by 104.7, it will tell us that the customer’s Actual K Factor for that delivery was a 7.51.
Looking at the above screen gives us some more information as well. First, I can see his last 3 deliveries were all low so without even looking at his forecasting page, that tells me either that his K Factor is too low OR that possibly we are pulling him way too early for a delivery. Also by looking at those last 3 deliveries which are all in the winter time, I can see that this customer’s K Factor should be between a 7.5 and 8.53 (the Actual K Factors are 8.53, 7.50 and 7.51). So now I can go to this customer’s forecasting page and assuming it is still March 2011, if his ‘Current K Factor’ isn’t in that range (and I am assuming it is probably around a 5 or 6), then we can manually adjust this customer’s Current K Factor and make it between a 7.5 and 8.53. If you are asking what exactly you should make it, it depends on how conservative you want to be. If you want to be ultra conservative, then make it the lowest K Factor during that season. Otherwise, you can probably use the average of them.
And since we are talking about manually changing a customer’s K Factor, this seems like a good place to discuss the importance of printing the Delivery Exception Report because this report will show you automatic customers that took a lot more or a lot less than expected. A customer like the example above would be someone I would expect to show on that report for that day.