What are “business hours”?

Many vendors offer a choice between “business hours” support and “24×7” support. It seems simple enough: if the customer has an issue during daytime hours, Monday through Friday, it falls under business hours support. Otherwise, it would qualify for 24×7 support. But in a global world this simple definition quickly fails to provide a standard that can be used to categorize cases. What to do?

1. Define the frame of reference for business hours. You can define business hours as the business hours for either the country where the contract is signed or the country where the technical contacts are located. Say you sell a contract to a US customer who has technical contacts in the US and in Europe. Under a contract definition business hours would be US business hours (so the customer’s European contacts would get only limited service during their business hours.) Under a contactdefinition business hours would be US business hours for the US-based contacts and European hours for the European contacts. Note how much more generous the contact-based definition is. Further note that if you use very different pricing mechanisms in different regions a customer could get very cheap support under a contact-based definition by making a purchase in one of your low-price regions.

2. Define whether business hours are determined by region or by customer. Imagine you have a customer based in Hawaii and your support center is in California. Depending on the season Hawaii is 2 or 3 hours behind Pacific Time. Do you provide business hours service until 5pm Hawaii Time or 5pm Pacific TIme (2 or 3pm Hawaii Time)? Most vendors use a region-based definition, so for instance in the US customers get business hours from (say) 5am to 5pm Pacific Time, which means that East Coast customers are within business hours until late in the day but West Coast customers get early-morning service (and those poor Hawaiian customers get cut off mid-afternoon.)  Some vendors choose to calculate business hours from the customer’s time zone instead. The customer-based definition requires slightly more work for entitlement checking but it’s not insurmountable.

3. Consider limiting the number of technical contacts. It’s a good idea to limit the number of authorized support contacts, not so much because it limits the number of inquiries (although it might) but because the authorized contacts, over time, become more knowledgeable about the product so the caliber of the questions they pose is higher. But limiting the number of contacts is especially important if you make the choice of defining business hours from the contacts’ perspective. If a customer happens to have operations (and contacts) around the world it could get full support around the clock (on weekdays) for the price of business-day support. Perhaps not what you intended?

4. Expand the definition exercise to weekends and holidays. Business-hours support typically excludes weekends and holidays. But what’s a weekend? If you think Saturday and Sunday, you haven’t worked with Israel or Indonesia, say. July 4th is not a holiday in 99% of countries in the world. As in step #1 you can either go by your calendar or the customer’s, but be clear about it.

Limiting the Number of Support Contacts

Many vendors limit the number of support contacts, requesting that all support requests be funnelled through a small set of individuals. Limiting the number of contracts increases the chances that the requests are well thought-out: even if the contacts are unskilled at first they will learn on the job. There’s also a perception that restricting the number of contacts will decrease the volume. That may be the case but don’t depend on it: if a customer needs help the cases will come to you regardless of the number of contacts.

Here are some best practices for limiting the number of support contacts.

1. Check that it makes sense. For some products limiting the number of contacts is clearly the right thing to do. For instance for a heavily-customized application providing support to the help desk — rather than each and every end-user — is a good idea. On the other hand, limiting support to a handful of contacts for a piece of equipment that is shared by many users around the clock is silly. Along the same line, limiting the number of contacts to one for business customers is probably not a good idea since individuals get sick and go on vacation: allow a backup.

2. Allow more contacts for premium support offerings. A logical feature of the richer support offerings is a larger number of contacts. So if you offer 2 contacts for basic support (a popular choice) you may offer 4 for 24×7 support and 6 for premium support.

3. Put the number in the contract. Whether your magic number of contacts is 1, 2, or 12, spell it out in the contract. It should be clear to all involved.

4. Allow purchasing additional contacts. If you establish reasonable limits for the number of contacts few customers will need more. For those customers who want more simply offer the option to purchase more rather than having to negotiate exceptions. Fees for extra contacts range from $2k to $20k per year.

5. Enforce the rules. If you let anyone create cases regardless of whether they are an official contact you might as well throw away your policy of limiting the number of contacts. At the minimum each non-contact should be told that an exception is being made. If a customer routinely oversteps the bound the support manager should have a conversation to reset expectations.

6. But don’t be crazy. If both contacts are off today and the system is down, now is not the time to enforce the policy. Help first, ask questions later.

7. Make it easy to update the contact list. I often find that my clients tolerate bloated contact lists because it’s too darn difficult to update contacts. Contact management is a prime candidate for self-service so see what you can do to place the responsibility of maintaining the roster where it belongs: with the customers.