|
Moderator
Registered: May 2001
Posts: 29,415
|
I've written some SLA's for specific customers while working at a full service 'net shop. It's a difficult task, you gotta make sure everything is covered, and you gotta make sure it's scrubbed by legal means available
First of all you should have incorporated a draft version of the current SLA you're working on.
Makes it easier for ppl and doesn't make us do all the work.
If you haven't got a draft ready it would be nice to work it out here, but then we need some basic answers.
The essential questions IMO are:
What are your companies requirements for this SLA regarding coverage of responsabilities and liabilities?
What is outside your companies power, and is that stated clearly?
What are the essential services you need to deliver, what will it take/who is needed/how will it be done/when will it be done to maintain status?
What will be the *legal status* of this SLA and can any part of the SLA be construed as a positive argument for the client when taken to court?
When I'm writing SLA's in the strict sense it is a legally binding document that makes clear what the responsabilities are for both parties. It is made so the client knows what to expect of you (and espeially what not), and you know what the client pays for because you want to keep servicing them, but not at all costs, so make sure they understand not all liabilities and expenses will be covered by you at price level X or when they fail to deliver on some conditions.
IMO it should define:
- the start and end date of effective SLA, usually defined in contract (for upgrades, re-pricings),
- emergency procedures for the company (notification procedures and response time, agreement on extra expenses, backup),
- emergency procedures for the company for causes that are not within your power to control (upstream, nukes :-], flooding, your COLO on fire because some disgruntled employee disabled Halon usage :-]),
- emergency procedures for the client (notification procedures and response time, access to redundancy features, failovers, backups),
- procedure for arbitrage (make sure you can afford it if you wilfully let out some clauses),
- procedure for breaking with the SLA for the company (essentially, you're investing in this, right, you don't want to loose them),
- procedure for downgrading/breaking with the SLA for the client (make sure it hurts),
- procedure for upgrading the SLA for the client when (make sure it's feasable),
- expenses and procedure for *anything* not covered above (this is a bitbucket to make sure you don't cut yourself, but don't allow for loopholes either).
State for this client:
- per facility/service, the facilities/services the client uses, what the conditions are for usage and what constitutes abuse,
- the "normal" status of facilities/services the client uses (define status),
- the min/max response time for acting upon/starting/testing/finishing/QA/sign offs,
- the min/max amount of work/expenses to maintain current status of the facility/service,
- a buffer amount in either work hrs/expenses/whatever else to be used for security and testing if appicable,
- specify min/max for sec, upgr, reloc, emerg, backup, 24/7 supp, debug, troubleshooting, logging, temp services, etc etc separately, and separately for company and clientside req's,
- a max limit up to amount X in extra charges if the client does not comply with/delivers/abuses stuff X under conditions Y and if applicable,
- a max limit up to amount X in damages to be returned (per service, per facility and only under specific circumstances) for service X under conditions Y and if applicable,
- if the client has a "history" (good *and* bad) with your company that will either have the effect of either extra charges or discounts in case of breaking stuff/stuff being broken/maint/whatever else covers expenses on your side.
- expenses and procedure for *anything* not covered above.
HTH.
|
