Home Career

Problems arise in any business relationship, from time to time.

Problems can arise with even the best-managed service levels. The skill in managing problems that occur with service levels is in establishing an agreed set of procedures. These procedures must be developed before the services are implemented.

Often, service level agreements are written with "escalation" clauses in them. Too often, these escalation clauses are simply a formal description of buck-passing.

For example, I may be providing a service to you that requires certain systems to be available continuously. Our escalation clauses may state that, after two hours of down-time, the problem is escalated to my country manager; after four hours, to the Asia-Pacific manager; and after eight hours to the international manager, who may be based in the USA.

Two things will be achieved when the two-hour deadline is reached. First, the country manager, who may know little about you and your requirements, will take charge. Second, I will become unhappy: not only have I not provided the required service level to you, but my country manager now knows it.

After the four-hour deadline, further outsiders get involved, and they may know even less about you and your needs. At the Asia-Pacific level, you may look less important than you do to me or my country manager. I will now be even more unhappy; my international reputation is starting to look bad.

After eight hours, we have even more remote management. The person now in charge can't actually get here to do anything for a further twelve hours, even if they are close to Los Angeles. They haven't the faintest idea of who you are. To them, your business may be insignificant.

There is, to my knowledge, at least one major service provider that has a presence in New Zealand solely so that it will have a global presence. It does not make any money in New Zealand. Imagine the reaction of its global management to the escalation of problems from here.

By now, in our example, I, and my country manager, and the Asia-Pacific manager are all unhappy, although probably on a decreasing scale of misery. The whole world knows that I haven't performed.

Let's look at this escalation procedure from the top down. My head office management in the USA do not want to be involved, and certainly will not want to be involved only when there is a crisis. They must ensure that the problem never gets that far. They must provide me with sufficient resources and the appropriate authority to manage the problem.

The same view should be taken by the Asia-Pacific management, except that they may see opportunities for providing problem-solving capabilities within the region. They may establish a "warm site" in Sydney that you will be able to use if a New Zealand solution is not possible.

My country management should also not want the problem to land on their desks, especially with a two hour deadline before it gets escalated again. They should ensure that I have the resources and tools to be able to use facilities in New Zealand or at the Sydney warm site to keep your systems working.

Not only that. All of these levels of management should be continually checking to ensure that all the customers covered by each level of management will continue to receive adequate service.

As a customer, you cannot expect that the transition to a "back up" or "stand-by" facility will be transparent; you will probably have to do something. You may have to get your operations staff to the airport so that I can take them to my warm site. You may have to alert your users that there will be a four hour delay in service delivery. If the problem occurs on Monday morning, you may have to accept that your systems will not be operational until Tuesday morning. If you really need your systems to be available continuously, then part of our agreement will be that the Sydney site runs as a "hot site", mirroring your transactions, so that it can take over in the event of a service disruption here. A transfer to alternative communications systems should be instantaneous and transparent.

You should also be aware of what the potential disasters will be and how they can be managed.

• A fully-laden petrol tanker driving through the front windows of your data centre and exploding may not affect my ability to continue to deliver services to you. It is likely that it will affect your ability to access and use those services.
• A volcanic eruption in Auckland or an earthquake in Wellington may cut telephone connections, including mobile connections, so that, even with a hot site operating in Sydney, information cannot be sent to and from it.

Your provider is not an insurance company, underwriting force majeure.

The key is, again, for the customer and provider to work together to plan, implement and maintain the procedures for continuous service levels. The customer, in particular, needs to look at what it really needs. In some businesses, I have seen complex business recovery plans for systems and applications that were not critical to those businesses. The priority of the general ledger was the same as the customer information and cash receipts systems. In the event of a problem covering all of these applications, the provider would have to give the same attention to getting the general ledger online again as it would to restoring the more vital systems.