Usage Costs

Instrument usage costs are calculated from the number of days' usage by a particular Project and the daily rate for that instrument for that Project.

The daily rate is normally determined from a costing matrix determined by the project class defined in the Projects form and the instrument class defined in the instruments form. (Note that the cost for the usage of a particular instrument may be overridden by defining a special cost.)

This matrix may be edited by selecting "Edit Costs" from the menu then selecting for which user class of user you want to edit the costs. The costs settings for each instrument class can then be edited.

For each instrument class/user class pair, the following data is required:

daily cost

The cost per full day's usage. A "full day" is defined on a per-instrument basis in the in instruments form. A single booking is not charged at more than this cost even if it is longer than the defined "full day" length. Specify this number in whatever monetary units you wish, but do not include the units just the number.
Example: 100

hourly rate multiplier

For each hour of usage, what fraction of the daily usage should be charged?
Example: with the rate of $100/day defined above, an hourly multiplier of 0.2 would make the cost $20/hour.

half-daily rate multiplier

The cost of a half-day's usage. A "half day" is defined on a per-instrument basis in the in instruments form.
Example: with the rate of $100/day defined above, a half-day multiplier of 0.6 would make the cost $60/half-day.

daily bulk-discount

The bulk-discount offered to shape usage costs for heavy users; within a billing period, each successive days' usage is cheaper (by this factor) than the previous day's rate (further details below). If you do not wish to make use of these bulk discounts, set this factor to 0.
Example: 5.5

Editing cost details

Calculating the cost

The usage cost is then calculated from the booking data and the daily rate.

The effective days is calculated from the booking data, the number of hours in a day or half-day (from the instruments form) and the half-day and hourly-multipliers set in the Edit Costs form described above.

The general principle is that the cost of each booking is minimised by, for example, by using a full day for an 8 hour boooking if 8×(hourly rate) would be more expensive than the full day.

Algorithmically, the number of billing days for each booking, d_bill is calculated as:

where min(a,b) is the minimum of a and b. Discounts for using particular booking slots or that were manually applied to a specific booking are trivially applied to this value of d_bill.

The total number of billable days' usage of an instrument by a project is then calculated as the sum of these d_bill.

The total number of billable days' usage of an instrument by a group is then calculated as the sum of the usage by each project multiplied by the group's liability for that project.

If the daily discount rate is set to 0 in the Edit Costs form (described above), the total number of effective day's usage, d_eff, is equal to the number of billable days calculated in the previous step. Hence, the total cost of using this instrument within this billing period is calculated directly from the formula above:

Bulk discounts

Some users are particularly heavy users of instruments, but you might not want to charge them the full rate all the time for instrument usage, either because of political niceties within the institution, the fiscal realities of their research budget or because you figure that frequent users are more likely to look after your instruments better so your maintenance costs should be lower.

To offer discounts to these users, you could define different user-classes for them so that the usage cost would be different from the matrix as described above, or you could define Special Costs for those users. However, both of these approaches require a lot of manual intervention on your part and can make the process a little less transparent. To help solve this problem, Bumblebee includes a simple algortihm to allow the daily rate to work on a sliding scale based on the instrument usage levels of this group.

The sliding scale used by Bumblebee may be described as a "daily discount model" as it uses the "daily discount" paramter described above to make each successive day's booking cheaper than the previous day's booking. This method means that the average price of the bookings always reduces but the total price always increases as more bookings are made; this ensures that you never have the strange situation where the total cost would have been lower if a user had used more instrument time.

By way of example, if the daily usage rate for an instrument was $100, with a 5% daily discount rate, the following rates for each successive days' usage would apply:

This "daily discount model" works quite well in many places; however, it has two main drawbacks: (1) quoting a daily rate for instrument usage to someone is difficult as the actual rate will depend on the amount of usage, and (2) the discount will depend on the amount of time over which the billing data is prepared (e.g. there will be more usage in a 6 month period than in a 3 month period).

The first of these problems is readily addressed either by estimating the number of days usage that will be involved and quoting an approximate daily rate based on that usage. Alternatively, you could create a fixed-price special cost for that user. The second problem is trivially addressed by always using the same length billing cycle (e.g. always preparing quarterly accounts).

For the daily discount model, the total number of billable days' usage of an instrument by a group is calculated as before.

Then, for each group, the total number of effective day's usage, d_eff, is calculated from the total number of billable days for that group, d_g,bill, using the daily discount rate:

where pow(a,b) = ab. (Hint: it's the sum of a geometric progression)

With the effective days usage now determined, the total cost of using this instrument within this billing period is calculated as before: