What to look out for with ASP agreements

ASPs (application service providers) are an increasingly attractive option for SMEs, providing a way to access services and applications over the internet. Effectively, you're outsourcing your needs to an external specialist, or renting software as you need it, and thereby saving on the cost of having those specialised resources in-house.

ASP services can range from staff payroll and company accounts to customer fulfilment services. The immediate cost benefits are clear - you don't need to buy and maintain software packages, and train staff to do specialist activities. Above all, costs can be controlled on a measurable monthly basis, and you're not investing upfront in a costly application (and someone to use it).

But "buyer beware"! Signing an ASP agreement is fraught with potential pitfalls. Before you take the ASP plunge, think about some of the key aspects of the agreement, and how it will impact your business and operations.

1. Do you have the bandwidth?
It's no use signing up for an application service provider if your bandwidth is a 28K modem and you're on a metered ISP package. The cost will increase as you wait for services over the slow connection, and the meter ticks away. Make sure you have either an ADSL or unmetered connection at least.

2. The SLA is your guarantee of performance
Service Level Agreements (SLAs) are the fine print of your contract and you need to know what to look out for, and what might be missing. SLAs should specify what you'll get from the provider in the way of security, service quality and cost. They should anticipate where things may go wrong, and specify how your concerns will be dealt with if they arise. They are an essential way for you to build trust with the client, so think hard about what you're getting and when.

3. What security will they offer?
This is your important company data we're talking about. Do they regularly back it up on other secure servers? Do they have procedures in place to ensure no one can access the data but you or your employees? Do they have secure connections between them and you, so that hackers can't intercept communications?

4. What service availability can you expect?
An effective SLA will give you few headaches if it precisely specifies service levels and spells out the way they can be measured upon delivery. Service availability is a key metric, and many SLAs will specify something like 99.5 per cent. This gives a 0.5 per cent room for non-availability, and that translates as 18 seconds out of every hour - which is a pretty high standard to meet on their part, and about as much as you could tolerate if you want service on demand. (Could you tolerate picking up your phone and not getting a dial tone?)

5. What service performance can you expect?
It is important that you define "acceptable performance" levels. These will depend on how "mission critical" the services are. A staff payroll service needs to be completed on time, or you'll have some very unhappy staff: the roll-on consequences of a failure there could be catastrophic for morale.

Ebusiness applications must perform efficiently to keep prospective buyers engaged, or to keep business-to-business (B2B) services flowing smoothly - so you need high performance levels for those. Make sure the small print acknowledges the importance of the services, and define what compensation you'd expect if they failed (see point 10).

6. How do you measure service levels?
How do you know that the ASP is delivering the service promised? Do you need extra tools to verify what is being delivered? How do you know the level of service given, and that you will get value for your monthly rental? More importantly, how can you measure whether the service has failed you? If you can't see that it's not performing, then you may only find out after your business has gone belly-up.

7. What are the cost savings?
What are you getting in return for your monthly rental? What extra costs might be incurred if you go over a specified level of service or usage? How does this compare with what you're already paying? The core thing to remember is that you want to maintain the same level of performance while reducing internal staffing costs.

8. Identify responsibilities and points of demarcation
Make sure you know what you and your staff are responsible for in operating an effective ASP service. If your team is entering the wrong data, you can't blame the ASP provider for not "spotting" problems, if this is clearly agreed from the start.

Similarly, what third parties are involved in the relationship (ISPs for connection, delivery firms in an ecommerce operation) which may become a point of failure in providing your product/services to your customers? Know where the buck stops at every point.

9. Is the service scalable and alterable?
You want flexibility in all that you do, so you must have some built-in guarantees that the ASP can cope with your changing future requirements. Will you have management control to be able to alter what you do, easily and effectively? And how will scaling up your requirements benefit or work against you?

10. What happens if it all goes wrong?
Murphy's Law states that if it can go wrong, it will go wrong - so make sure you're prepared for disaster if it strikes. Write down the terms of separation from the start. You will want to get back all your data intact, and in such a way that it does not affect the functioning of your business. Make sure the ASP knows what compensation you'd expect if it did seriously impact your cashflow or viability.

Finally, define what methods of dispute resolution would suit both sides if you came to an impasse in the course of using the services or in the course of splitting up. Best to decide how you would operate in those circumstances while you're still friends, rather than trying to sort things out when emotions are high and either of your businesses are on the line.