How do you define a "Billable Request?"

[akeppel]

Just a question I'd like to throw out to the larger ITSM community here. If you're a third-party call-center, or if you use a third party call-center, and pay on a per-request basis, how do you define a "billable request?"

There are a lot of ways it can be handled and the "industry average" is $25 per request (according to HDI), but how do you have this implemented in your organization, and have you been able to configure Service-Now to provide consistent reporting that you feel comfortable using for billing?

A couple of thoughts that may influence it are:
- Do you charge/pay a different price for different types of requests? (e.g. are passwords billed at a lower rate?)
- Do you charge/pay for requests that are escalated immediately because the help desk doesn't have the tools or permissions to resolve them?
- Do you charge/pay only for requests that have time logged against them?

I'd be interested to know what other companies are doing, and look forward to your input!

[bgramlow]

We are struggling with the same issue. We are using SN to provide support in a retail environment, where so far each client store has a contract with our company which includes a "callpack" where they are allowed x number of calls per month, and if they go over this, they must pay per call after that. The challenge is that there are some exception scenarios where the call is considered "non billable". Examples of this would be duplicate cases, automated attendant cases etc. There is a reluctance to have any decision on the technician regarding whether billable or not, so we have attached this billable flag to our knowledge article. i.e. if they attached a given knowledge article, the incident becomes non billable and this billable flag to incident relationship is logged in a separate table. In this way if there is a dispute after ticket closure, we don't have to re-open the ticket to update it (our environment we have locked this down as we prefer not to re-open)

In the past, this has worked well in handling yes/no billable scenarios. Now we have a new twist coming our way where there may be several separate SOW in addition to the base contract. They want to have to option to track these separately, but also still say non billable for various exceptions. We are reluctant to add a billable "type" field now, as we are growing quickly and this is not scalable (i.e. what if knowledge is not mandatory?).

All that said, the business needs to track buckets of tickets, mark them as non-billable based on various criteria (sometimes product, sometimes combinations of factors) and report on them as well. 🙂 any ideas out there? I was looking at the contracts piece, as well as business services.

In theory tracking the new SOW as a business service might be an option, but i'm not sure of additional complications around doing that. This also does not solve the non-billable scenarios.