Setting SLA's (CSM or only Support Teams)?

This is a follow up on @Bridget Lamb recent post (Responding to Support Tickets)

We have a defined SLA's and UpTime currently in our contracts, but how the team works to those SLA's is still in the air.
I have a few questions to see what others think.

1) Should SLA's vary based on contract size?
2) Has anyone spelled out that Feature Idea's (ie. requests/enhancements) are not included in SLA's?
3) If a customer reaches out to the CSM vs. creating the support ticket, does the SLA's timeframe start (if not, do you spell that out in your SLA's as well)?
4) Should CSM's have SLA's in addition to Support?

Thanks GGR Community in advance

------------------------------
Markus Siebeneick
Head of Customer Success
------------------------------

Find more posts tagged with

Data

Retention

Revenue

CS Team

Comments

Craig Jackson

Hi @Markus Siebeneick

1) Ive not set an SLA against contract size but I have against package bought. Personally I think this is the easiest and the best way to be transparent around customer prioritisation. It largely depends on the industry you serve but in many cases customers will know one another and often discuss experiences, My personal view is that is leaves you open to unnecessary bad press and a CSM having an awkward conversation around why they aren't as important.

@James LaRiviere also makes a very good comment around prioritising your larger contracts without breeching your service SLA for the winder customer base.

2) Ive not spelled it out, I always use marketing for that. However we have run a customer advisory board, all feature requests went into a quarterly agenda and minutes were produced following that meeting on feature prioritisation. It worked well for us as i meant our customers had a say in the road map.

3) & 4) I agree with @James LaRiviere - I do however client emails to CSM feeding through to a CRM system - we expect all CSMs to get back to their portfolio within 3 hours even if its an acknowledgment of the email.

Cheers

MarkusS

@James LaRiviere Thank you for the response.

1) I have seen different service tiers sold (but they didnt change the SLA, but added phone support). I do believe that better SLA's that dont impact smaller account makes sense to sell as well.

2) Do you have any specific language you have used? I am going to have to work with my team on setting expectations on Feature Idea's. The challenge that I face is that we include certain feature improvements as part of our offering, so how we handle those requests and how we explain them to customers is interesting.

3) I like the idea of clearly defining that SLA's are only related to official support tickets

4) While it may not be directly related to Support tickets, I have been getting some requests to have SLA's on CS response times to customers based on their communications. As general emails don't have the same routing and structure as a support ticket, I dont see how that would be possible to track and properly enforce.

James LaRiviere

Hey Markus, happy to jump in here.

1) I find this depends on the market you're serving. For large/enterprise clients a speedier SLA can be a regular up-sell. If you go this route, make sure you have a process for prioritizing these customers without breaching the SLA for the rest of your client base.

2) Language around this has helped in the past. Define that the SLA is for service interruptions, product questions, etc, not turnaround time for feature requests. The CSM should also cover this when introducing support.

3) Traditionally I haven't started the SLA countdown until the ticket hits support. There are a lot of situations where you may not be able to see their email until hours later. I recommend a section in your contract for Customer responsibilities and highlight what actions are needed from them to ensure their ticket is acted on. This includes reaching out to Support vs the CSM.

4) To confirm, do you mean the CSM's having an SLA for support related tickets? I lean towards no on this for a few reasons.

a)The customer will start to side step support and lean heavily on CS, which can railroad their day as they have to be reactionary.
b) The more time CS spends doing support the less time they're spending on revenue generating activities.
c) We want CS to stand in an advisory role to the customer, support can take away that "status".

Hope this helps, happy to discuss further!