It's not generally a topic people like in society, but then I suppose it depends on what society you hail from. No matter what business you are in, your customers will naturally push the boundaries of service away from what was intended.
So, what do you do? You know what you think is reasonable, but they think they are being reasonable, too. Think about it - you do the same with people you frequent as a customer: you expect more the more often you use them. When it gets out of hand, which it sometimes can, you have to step up.
Of course, depending on your location in the supply of the service (are you internal or external and how far away from the requester is your business unit). The further the distance is, the more likely the customer is going to use you without considering what it does to you. And especially in those circumstances, you have to have hard conversations with the customers about the service.
What tips can I give? Well, for me, be polite. You might have to be forceful, but that's no excuse for yelling and being angry in return. Bad behavior never justifies other bad behavior, and it never pays to be unreasonable to your customer, because the customer is the one who ads for your service and they can choose to un-pay if you are out-of-line enough.
Next, make sure you know your position and can back it up with data, and have at least one proposal for how to make it work. Make sure you have thought it out clearly, and it is not just an idea. You are coming with a complaint about how the customer is behaving so you must make sure you explain how you expect them to behave very clearly.
Finally, you need to make sure you frame the issue in a way such that you demonstrate the benefit to the customer of working with you - it has to be for mutual benefit. You might have it in your mind clearly, but you need to make sure they *understand* what you understand in order for it to have a chance to succeed.
And sometimes that benefit might be that you continue serving their needs. When you state what recourse you will take if they refuse to work with you, you have to be ready to actually take that recourse. If you don't, then they will no longer trust you. Don't bluff, be honest - I have always found that to be the best policy of any. While it is not always easy, it always pays off in the long run.
And of course, when you come out of the negotiations, if you do succeed, make sure you keep your end of the deal. It makes sure that the customers will be more willing to work with you when they see that you keep your end of the deal rigorously, too.
A place to discuss the practicalities of service delivery and service delivery management, and a useful place for new beginners.
Tuesday, January 8, 2013
Wednesday, December 26, 2012
Metrics - Are we delivering the service?
Service delivery's success or lack thereof on delivering a service is based on metrics. Since I'm most familiar with IT, most people would know about Service Level Agreements, SLA's, or Operational Level Agreement, OLA's - basically, they are just fancy names for Key Performance Indicators (KPI's) which have some lever attached (a financial Penalty for not delivering, for instance). These stand for commitments to the customer, whether external or internal, that you will complete a service in a certain manner and timeliness. Service levels are meant to help the customer to see how we'll you are doing and your team of doers to see how well they are servicing their customers. And SLAs and OLAs can be based around anything definable, measurable, and tangible. You can't measure the number of happy couples leaving a counseling service, but you can measure other items like after-session surveys of customer satisfaction or how many ask for follow-up meetings within the next week.
How effective are SLAs and OLAs? Well, there is an old, management sophistical, "you get what you measure". So the effectiveness of SLAs and OLAs will be only as good as what is being measured and what measure is put in place.
For instance, if you are managing outsourced baked goods, an SLA might be "number of cakes baked every day" by your bakery. If the Service Level is set at 30 per day, you know that you need to make sure that every day you need to produce at least 30 cakes, and you know that your customer is expecting 30 per day to meet your agreement. This allows you to make sure you have resources and people enough to make those 30 cakes. Generally there might be a percentage of days where that level must be met every month, say 90%, so you know that at least 90% of he time, you need 30 cakes out every day.
The above cakes SLA does have some issues. Outsourced baking usually requires delivery to be made, or for the customer to pick up those cakes. If the SLA only measures number baked but not delivered, then you have missed the business goal of measuring, which would be for your customer to have the cakes on-hand when they are needed.
Of course, having a set number might be a bad idea, too, because demand fluctuates and as a customer, you might now be required to pay for 30 cakes a day even when there are holiday periods when you cannot use them. Maybe meeting a forecasted number of cakes where the customer send the number needed at least a week beforehand, up to 30 per day.
There are other holes in this sort of an SLA, but you can find them if you think about it, but it does make for a god example.
Now, remember, the SLA or OLA is just a tool. It's supposed to allow you to measure performance. So make sure that when you make SLAs or OLAs with your customers that you sit down with them and get some of the doers in the room with you and discuss what the customer actually wants, and then translate that into an appropriate SLA or OLA.
And also remember that pricing of your service might change based on the levels or service and types of measurements for which your customer asks, but that is not the issue with your SLAs or OLAs, that's an issue for the owner of the business nit that you work for and their negotiating team.
Just make sure you have input to those discussions or you and your customer might wind up with SLAs or OLAs that cause all of you consternation and pain for the duration of the services agreement.
How effective are SLAs and OLAs? Well, there is an old, management sophistical, "you get what you measure". So the effectiveness of SLAs and OLAs will be only as good as what is being measured and what measure is put in place.
For instance, if you are managing outsourced baked goods, an SLA might be "number of cakes baked every day" by your bakery. If the Service Level is set at 30 per day, you know that you need to make sure that every day you need to produce at least 30 cakes, and you know that your customer is expecting 30 per day to meet your agreement. This allows you to make sure you have resources and people enough to make those 30 cakes. Generally there might be a percentage of days where that level must be met every month, say 90%, so you know that at least 90% of he time, you need 30 cakes out every day.
The above cakes SLA does have some issues. Outsourced baking usually requires delivery to be made, or for the customer to pick up those cakes. If the SLA only measures number baked but not delivered, then you have missed the business goal of measuring, which would be for your customer to have the cakes on-hand when they are needed.
Of course, having a set number might be a bad idea, too, because demand fluctuates and as a customer, you might now be required to pay for 30 cakes a day even when there are holiday periods when you cannot use them. Maybe meeting a forecasted number of cakes where the customer send the number needed at least a week beforehand, up to 30 per day.
There are other holes in this sort of an SLA, but you can find them if you think about it, but it does make for a god example.
Now, remember, the SLA or OLA is just a tool. It's supposed to allow you to measure performance. So make sure that when you make SLAs or OLAs with your customers that you sit down with them and get some of the doers in the room with you and discuss what the customer actually wants, and then translate that into an appropriate SLA or OLA.
And also remember that pricing of your service might change based on the levels or service and types of measurements for which your customer asks, but that is not the issue with your SLAs or OLAs, that's an issue for the owner of the business nit that you work for and their negotiating team.
Just make sure you have input to those discussions or you and your customer might wind up with SLAs or OLAs that cause all of you consternation and pain for the duration of the services agreement.
Tuesday, December 25, 2012
Disclaimer
What I post to this site is a representation of my own personal views, thoughts, opinions, concepts, ideas, and rants. It does not represent the opinions or views of any other person, organization, corporation, government, or other entity with whom I have any connection, including those of my family or those of my past, present, or future employers
I take no responsibility for the comments or any other content that other people may post to this site. Copyrights are retained by the original authors of the content, and claims of copyright are also owned by the poster, if no attribution is mentioned. I am not responsible of other's posted content.
Any items or content to which I may link or refer are not my own and I make no representation of their quality or being fit-for-purpose for any use, nor do I claim copyright of said items. If you have any questions, feel free to ask or contact me about it. If you feel something is being improperly used or have inquiries about copyrights of this blog, please also contact me.
Basically, my stuff is my stuff, your stuff is your stuff, and others' stuff is their stuff. Please keep it within proper bounds.
I take no responsibility for the comments or any other content that other people may post to this site. Copyrights are retained by the original authors of the content, and claims of copyright are also owned by the poster, if no attribution is mentioned. I am not responsible of other's posted content.
Any items or content to which I may link or refer are not my own and I make no representation of their quality or being fit-for-purpose for any use, nor do I claim copyright of said items. If you have any questions, feel free to ask or contact me about it. If you feel something is being improperly used or have inquiries about copyrights of this blog, please also contact me.
Basically, my stuff is my stuff, your stuff is your stuff, and others' stuff is their stuff. Please keep it within proper bounds.
What is Service Delivery Management?
"Service Delivery Management". Sounds a bit...esoteric, doesn't it? The name should be definable from the component words but its not that easy after you try. After working in a role titled for this over a few years, I can honestly say that what I do now has very little to do with managing delivery of services. Mostly, I'm a go-fer for those above me and the definition of service delivery isn't in what I do for the majority of my time.
However, there are times that I do actually fill parts of this role in Service Delivery.
So what is it? Service Delivery Management is managing delivery of services, and those services are defined either by a contract for external organizations or Documents of Understanding for internal organizations. Service Level Agreements are generally the measuring stick of how well you perform those services. The services could be anything, but they have to be "SMART" - specific, measurable, achievable, reasonable, and tangible. You can't deliver a service of couples falling in love, but you could deliver a service of finding good dating locations. Your services could be for hospitals, for manufacturing, shipping, information technology, government, anything hat can be defined and set for measuring an agreed service will need service delivery management.
Now, to be reasonable, everyone does it to some extent at their job. You make 15 phone calls an hour, cook 20 burgers a minute, write 7 insurance contract a day - or whatever your measurement is in your role. But the line managers are the ones who fill the role of managing the service delivery, not the doers. In reality, the actual role or services delivery manager cannot be a doer, it's mostly administrative. Why?
Service delivery managers have to track metrics for all services they own. They are responsible for interacting with the recipients of the service, for customer satisfaction, for working to find ways to improve the services. They are also responsible for tracking costs, helping with modifications to the service. In a way, service delivery management is very similar to project management with be key difference, the service delivery manager's "project" of day-to-day operations and service delivery never ends until the services are no longer required.
If the service delivery manager is also doing the work for the services, then they have to be a robot like Commander Data on Star Trek so they don't have to sleep or eat, because the only time they aren't doing the administrative function is where everyone else is asleep.
In reality, it should be a business role, but it easily tends to draw toward the technical, because the service delivery manager must also be able to answer requests and work on improvements, none of which you can do unless you have a good knowledge of what exactly you are providing as a service.
However, there are times that I do actually fill parts of this role in Service Delivery.
So what is it? Service Delivery Management is managing delivery of services, and those services are defined either by a contract for external organizations or Documents of Understanding for internal organizations. Service Level Agreements are generally the measuring stick of how well you perform those services. The services could be anything, but they have to be "SMART" - specific, measurable, achievable, reasonable, and tangible. You can't deliver a service of couples falling in love, but you could deliver a service of finding good dating locations. Your services could be for hospitals, for manufacturing, shipping, information technology, government, anything hat can be defined and set for measuring an agreed service will need service delivery management.
Now, to be reasonable, everyone does it to some extent at their job. You make 15 phone calls an hour, cook 20 burgers a minute, write 7 insurance contract a day - or whatever your measurement is in your role. But the line managers are the ones who fill the role of managing the service delivery, not the doers. In reality, the actual role or services delivery manager cannot be a doer, it's mostly administrative. Why?
Service delivery managers have to track metrics for all services they own. They are responsible for interacting with the recipients of the service, for customer satisfaction, for working to find ways to improve the services. They are also responsible for tracking costs, helping with modifications to the service. In a way, service delivery management is very similar to project management with be key difference, the service delivery manager's "project" of day-to-day operations and service delivery never ends until the services are no longer required.
If the service delivery manager is also doing the work for the services, then they have to be a robot like Commander Data on Star Trek so they don't have to sleep or eat, because the only time they aren't doing the administrative function is where everyone else is asleep.
In reality, it should be a business role, but it easily tends to draw toward the technical, because the service delivery manager must also be able to answer requests and work on improvements, none of which you can do unless you have a good knowledge of what exactly you are providing as a service.
Subscribe to:
Posts (Atom)