Search Our Site

  

Existence As A Platform

People Are Talking

Tomorrows IT News, Today.



« Are you Digitally Literate in 2012? | Main | I'm in a K-Hole and all I hear is a powerful USERVOICE - ITSM weekly the podcast EPISODE 89 »
Saturday
May192012

Distributed Service Desk Strategies - Practitioner Radio Episode 26

 

Troy’s Thunder Bolt Tip of The Day:

A distributed service desk strategy is practically a given for most organizations. The goal is untangle the current fragmented model and to establish clear and simple support channels from a customer perspective.

Show Notes:

The Service Desk To Call When You Don’t Know What Service Desk To Call!

The Customer Response Center

The Genius Bar

Lucy’s Advice Booth

Shadow Desks

The Spaghetti Bowl Support Model

Service Desk Chaos: (Single Point of Contact? You Got to be Kidding!)

 

  • ·      Outsourced Desks
  • ·      Shadow Desks
  • ·      Application Support Desks
  • ·      Rogue Forward Deployed Desktop Agents
  • ·      Fragmented and duplicate tools and IVR systems

 

Consolidation Options (Process, Roles and Technologies)

Service Desk Inventory

Tiered Service Desk Model

Open Tick Initiative

Service Desk and Service Offerings

Support is a base element for any service provider

Outsource Call Dispatch Decks disconnected from the back office Incident Process

Project Culture vs Run Culture in IT

PinkFORUM12 https://www.pinkelephant.com/PinkForum12/

Service Desk Facades

Local Service Desks vs Honking Death Star Desk

The Service Desk Foyer

Additional Information on Service Desks

ITIL Implementation Roadmap (Incident Management / Service Desk)

http://blogs.pinkelephant.com/index.php?/troy/comments/itil_implementation_roadmap_part_3/

Dealing With Rogue Support Agents

http://blogs.pinkelephant.com/index.php?/troy/dealing_with_rogue_support_agents/

Service Request vs. Request for Information

http://blogs.pinkelephant.com/index.php?/troy/comments/service_request_vs_request_for_information/

Listen below or download the MP3 HERE!  / iTunes / PinkAPP for BlackBerry, iPhone and Android

 

 

 

     

 

TRANSCRIPTION:

Welcome to another edition of Practitioner Radio. Pink Elephant's podcast for the IT management community. Welcome to Practitioner Radio: Think Elephant's podcast for the ITSM community, the fastest 30 minutes in ITSM audio. Hey, it's Chris Dancy. This is episode 26, and I'm here with Troy DuMoulin.

 

Hey, Chris, how you doing today?

 

Doing good. Crazy weather, I think it's because it's May. Thunderstorms last night, and I'm sitting there and I'm on the front porch because I'm getting older so I watch storms now, and make them.

 

That can be debated.

 

And there's this gigantic bolt, and what's the first thing that went through my head? Troy's Thunderbolt Tip of the Day!! I'm like oh, no, that's tomorrow, it's not tonight.

 

Oh we have the same weather.I imagine we're in Seattle right now but actually in Toronto. I thought is was supposed to be April showers bring May flowers. What happened to the fact that we're supposed to be you're on the shower thing now. I think it has something to do with, the heavens have distributed service desk models.

 

And they're not all in sync with each other. We ought to bring her back to talk to Chris. Yeah, but they don't pay me to be pretty. So Charlie - Yes? - I've seen, and I'm seeing this crazy the movements here, with people who have more than one service desk, some places two, some three, four, five.

 

In some cases not even what they would consider a service desk, just a project team taking ticket something random. Just the other day, I thought to myself, I was trying to log a ticket at my company, and I thought, why can't I just ask for an HR thing through the system? and then I end up sending an email to each.

 

So all this decentralized, all these different, what is going on? I feel like I'm in a mad mad world. Well yes, in fact I've seen so crazy that there is the service desk, they call him. You don't what service desk to call. You know, call this desk, if you don't know who to call and they figure it out for you.

 

Yeah just recently actually that was creating a customer response center, and it was beyond IT. Because not only were we having the classic service desk, but if you needed the facilities or you needed a fleet management activity or you wanted a support item with your expenses, it was just anything that could be user or consumer base could come to this center, and a kind of Mac Genius Bar kind of setup, as well as the virtual entry points, right.

 

It was a single, central point of access to anything user-based. It was kind of cool.

 

I like that idea because I'm in a, you know, our company's growing very fast and I never sometimes know who to send it to. And I really do wish I had a what did you call it, the customer response center?

 

Customer response center.

 

I wish I had a CRC, I'll just use that because I won't remember the words, a CRC in front, because it would make my life as a customer a lot easier because I almost need an oracle. I was at, speaking of this, you said genius bar, didn't you?

 

Yeah, I did.

 

I was at Rackspace. You ever heard of Rackspace?

 

I have indeed. In fact I have a cousin who works there.

 

There you go. Down in Texas?

 

It's one of the locations, I am not sure where.

 

Yeah Okay. Yeah, we don't want to [xx] too much of Troy's personal life. So, yeah, I was down at I will put a picture in the show notes. I'll make sure I do this, remind me. So I've got pictures of this. They actually had a Genius Bar So they actually built a bar in front of the help desk and they put a Smoky Joe's Help Center, like an old neon sign flickering, and and members of the service desk, when they weren't on the phones, would actually man the bar.

 

Anyone could walk up and ask any type of IT-related question. But then, kind of to today's talk downstairs in front of HR they had a similar type bar, but it looked more like, you know how Charlie Brown and Lucy had that little 10 psychiatric help sign. Thought you were going to say kissing booth, and that might be a bit inappropriate.

 

Did she have a kissing booth? Lucy had a kissing booth. Somebody had a booth in Charlie Brown where they offered advice, it was like Advice 10cents. And I thought, I like the idea of this bar, but again I'd have to walk two different places This is the reality for most organizations, right? In fact, even having a front door is kind of an improvement for some.

 

Reality, I think it seems the same thing Chris. We go to most organizations and over a period of time things have grown, whether that's been through mergers and acquisitions, whether that's simply been project by project creating its own support mechanisms. You've got this spaghetti bowl of support channels.

 

And there really isn't any clear way to get access for one thing. You have to know the whole complexity to actually understand how to get support. And that's a big challenge. I would think it would be a huge challenge, not only for, You know, first person I'd think of would be a new employee. But just for, like you said, mergers and acquisitions.

 

They are rapidly growing companies. You don't know who's in charge of what anymore. It's not like, I know Beth in HR and I just walk up to her and say, hey, I need help with this, how do our benefits work on this. At our company we actually outsourced the handling of our benefits. So I have a help desk I call that's not part of my company that just does that.

 

So it is really confusing. And again, that's very common to what we see So you'll often find organizations with a component of their service desk outsourced. Let's say it's tier one kind of office productivity support. But then each of the application groups might have their own kind of special support desk, especially the big ERP systems.

 

Then you're going to have the shadow desks that have been created in the business units, basically smart employees that became service desk because they were techies and they couldn't get anyone in the actual service desk to answer their phone calls then you've got these forward deploy or remote support agents out in the branch or on the plant floor, which are quasi-IT salaried people, but they've kind of gone native on you and now they're roaming around doing their own thing our there.

 

Or as Sarah Palin would say, "Gone rogue".

 

Gone rogue, yeah, absolutely. So this is reality for most organizations, so we think of best practices, they talk about single point of contact and we look at this spaghetti bowl aspect and We pull our hair out because this is so complex. How do you fix this, how do you improve the situation? Okay, it's almost like Troy's cooking hour, so I like a good spaghetti.

 

You've got the spaghetti kind of strands, or the shells and noodle, all types of spaghetti. I guess my first question to you does it have to be fixed? We talked one time about pain versus is there enough pain to fix it? Are there times when it would work? Well, you play with the cards you're dealt, right?

 

and so reality is, sometimes when you've got an outsource situation the contract's not about to be terminated any time soon, so you've got to deal with the partner you've brought into your family now, and treat like they're part of a family member. Very important. So that front door you've outsourced, so you've got to deal with that.

 

But the reality is you've got to acknowledge you have all these different avenues. So rather than just throw the entire thing out, how do we take this bowl of spaghetti and start looking for the beginning and end of each gonna build this more complex, but single channel, or not single channel, or not single channel, but a, let's say, a simplified channel for support.

 

pull all these things together would be my first goal. This is the concepts of good, better, best. Yes, you might identify opportunities for consolidation. Let's say in four or five of these desks that you found, shadow or legitimate, there is front level support. Well, maybe you can move some of those people to different parts of the organization.

 

The reality is, you've got your front door, and that's both some technology, whether you're using an IVR phone technology, or you've actually got a single point of contact in a service desk. But then I've got to take the front door, whether that's push five. Then you go to the support desk for Application X. Push three and you go to customer support center.

 

I take that front door and I've got to now clean it up so that front door will then have to deal with how do I pass calls through? Is it going to be warm transfer, where I take the call, try to solve the issue at the front end here? I can't do that, so I will then warm transfer you to a second tier desk, a specialized desk or is that gonna be a cold transfer where I just drop you into a queue?or is that going to be recognizing that the second tier desk actually is a frontline desk, because I literally allow you to hit number three on my IVR technology and you go directly for SAP support.

 

Speaking of IVR technology, I've noticed a lot of times when I call different support desks, every single support desk I've called probably in the last ten years who has any type of IVR, I always get the same message: choices have recently changed. Have you ever noticed that? How often are they really changing or they just know that they do not want me to wait and hit the numbers I know.

 

I'll hit zero and go to a live voice.

 

Exactly. You talked about consolidation, and I think that's an interesting concept. I want to pick your brain a little bit about that. Does consolidation have to be a physical move of people, does it have to be using the same tool? Can it be a consolidation of ideology?

 

OK, so consolidation can come at different levels so let's think about it.

 

Yeah, I knew you'd know this, I knew you'd know this one.

 

So you have process consolidation, we still want to have one common process for gaining support, right? So, there's a way to understand what a first, second, third level support process is, and how things move trough that queue based on who is supposed to do what. Then there are roles and so, you can have first, second, second, third level roles distributed.

 

You can consolidate people relative to the role. Then there are technologies. And literally you have the telephony IVR technology consolidation and you have the ticketing tool consolidation, right? So, you can look at consolidation on of three levels, but most organisations do that the beginning is taken an inventory, where all the possible elements of support, who's doing what, what are their areas that they're supporting, what kind of roles do they have, what technologies are they using.

 

So it's almost like they map out their support graph and all the different touch points, They start pulling the spaghetti strands apart and looking at each one. Because until I figure out what I've got I can't make a determination about what I do as a next step. But once I've got this inventory of practice, I'm not even going to call it a process maturity assessment, that's how do I compare against some framework like ITIL or COBIT, just who's doing what, and with what and by whom.

 

Write it down down, cause until it's written down it's not true. Yeah. My favorite Troyism. Now the ghost desk, the shadow desk have now been identified as, you know, there's legitimate people here and they have a and they have an impact to the bottom line. Now I've got to figure out the strategy.

 

So let's put aside the inventory for a minute, right? Let's say in the strategy where I do have a single point of contact relative to the IVR telephony. There's a single number. Okay. And there are neat technologies depending on if you're a global organization, if you're calling from a certain area code, you literally get kind of funneled to one desk versus the other based on based on that's not Alright, so it comes to somebody.

 

And then on that front level, there's this determination, whether it's again automated or it's manual, where this call should be routed to. Do I handle it at the front level, and what kind of things do I handle at the front level? You've got desktop support. No. Shrink-wrapped applications, password resets, request fulfillment activities, facilities requests, whatever that is, that's tier one.

 

And then you identify what kind of person with a relative salary level will I need at tier one? What skill levels are those generics skill levels? So that's my tier one. Then I've got this tier two concept. And now I could have specialized desks, so each business unit might have instead of application desk, or each application might have it's own desk, whatever that might be, but in your inventory, again you've kind of figured out they might have multiple roles there.

 

I've got this tier two desk, how do I pass tickets or calls through from tier one to tier two? Because, I either have to, kind of, go through that automated IVR direct, and literally that becomes now a tier one desk, right? Or it's an indirect where it's a pass-through, and now that's either going to be a warm pass-through or drop into a queue.

 

And then, I've got to come up with policies about how long I want to wait for that to occur, the response time policies. And then what kind of role do I need on that tier two desk? Because, let's say I have identified as more of a specialized desk, they're a specialized skill set on a specific technology your application, that means they're going to have this kind of salary expectation, and if I've got that to find and I find mismatches of people that it might be more of a tier one type of roll within that tier two desk, well that person might be identified to move to the tier one organization whether that's outsourced or not And then, finally, what's my tier three?

 

And, this is where I get into my supplier integration as well as my engineer type, back office, third level role. so now I've got to have underpinning contracts in place, with cloud suppliers too, like Service Now, right, because if I have an issue My service now instance. I have to have service desk strategy incident management process connected with my external suppliers.

 

So that whole model now is kind of taking this bowl of spaghetti and stretching each of these lines out and saying, here is the channel of support for each of these avenues and here's how it passes from tier one, tier two, tier three. Now, we consolidate on technologies because we're going to have one common process across this strategy.

 

I'm going to hopefully have one technology, and if not, then all the technologies I use have to be kind of configured in the same way, which is complex and costly. Well that's bit of a rant there, but that's kind of how you think through this process.

 

The two things about that stream of knowledge that you called a rant. One, I read someplace last year, and I'll have to dig up the article. There's actually a consortium of service desk vendors, all sorts. Little service test honors, big, all of them actually last year created this I think its called open ticket initiative so you can do what you said.

 

Transfer stuff back and forth, even though you have different tools. It was almost like someone created a framework for this is a basic incident transfer and It was kind of interesting, because when you talked about your level three, that's the first thing that popped in my mind. But, as you were talking about all these different, you know, before you consolidate, you've got your different processes, maybe different teams, some different tools, different skill sets.

 

My mind started going back to some of the podcasts when we would talk about creating service offerings and how you would look at all the resources around a service, whether it's software people, process, hardware, all the different things that you bundle up and make a nice little service offering for someone to put into a catalog and/or portfolio.

 

And I wondered, could you use the skills that you or maybe someone in your organization who has done service bundling to help you in your consolidation efforts. It seems like they have similar skills.

 

Well in reality what we're talking about is a support service.

 

We've never talked about that; is there such a thing?

 

Absolutely, outside of management there's always, a macro operation model will have you know planned processes, build processes, run and support. Support is an understood concept, whether you're coming from a business manufacturing financial industry type concept or an IT concept, support is just a set of capabilities and a service you need to It's a base element.

 

it's a base element, any operating model. You have to build a support model That's good to know that we won't be out of business then. Not at all. And that's why you can actually use technologies that were traditionally used even for, I don't know, maintenance within a manufacturing plant, like IBM has, and use it in service management, because the reality support, support, support.

 

You've got to come up with this model regardless of what you're supporting, and understand the complexities of the different tiers of support you want to put behind your offers. And that catalog, as you described it, would actually present your service offering, called support, in its different flavors you know, you have that service desk element, you have the forward deploy concept, or desktop support aspects of this you know you go to my Telco right now and I can go online and actually have instant chat relative as a channel for giving us support.

 

So all of these are [xx] of a base capability or offer called support. Speaking of combining support and consolidation models, have you ever heard of GoDaddy? Oh yeah, absolutely. know Canada's far away. Well I don't know. I use GoDaddy. I always get in trouble because people always go, Chris, do you think America only knows that sort of stuff.

 

Well I don't know. Do you have water in the US, Chris? no, we're not clean. We have Dean Cayman, though, and he creates machines to clean water. But Go Daddy, for those of you who don't know, is an Internet hosting stuff. But when I've called then for support I've noticed that their support people also review - I don't know how they do it, they must be really down to.

 

But they are reviewing my contract and always commenting, oh, did you know you're about to expire on this, okay change the DNS address to this, oh and did you know we can offer you this, this and this. It's almost like their support people are also marketing slash sales people at the same time. It's cross sales.

 

Absolutely. I mean that's really, that's synergy, the big word there, right. You're using multiple talents.

 

So is there such a thing as a traditional IT service test that would invoke some of that synergy and why you're helping someone?

 

Let's play a scenario through. We've had this conversation in the demand and service catalog in the request right? But let's say for the moment, that I had access to the services that we offer, which is our general catalog, then I can also look at your subscribed use of that set of offers and I could actually now see the actual use of the different service elements that you're currently subscribed to.

 

Of course there's even a forecasted target you might have set and I can say/ Listen, I see that you're about to move from hosting level one to hosting level two and, we can do that proactively, otherwise you're going to be in overage charges. Right. Do you want to do that right now? Or, let's talk about ways you can, kind of, keep yourself in the bounds of hosting level one.

 

But that means we'd have an accurate understanding of our consumers. What their currently subscribed to in the catalog, and their current demand, and what the current consumption is against that demand. it's really hot, and that's what's happening in that Go Daddy scenario. Again, this wasn't invented just for IT service management right?

 

These are simply elements of building this continuity of the base element of support. And upselling now, not just upselling for additional profit, but literally being on the side of the consumer, helping them to engage in do things better for themselves. Yeah, and up selling isn't always a profit thing.

 

There are a lot of hospitals and non-profits, people that aren't out to make money that when you're meeting with their support personnel, they give you choices. Like you've said many times, there are lots of decisions you can make around that sort of thing. Now let's play this scenario where you've outsourced the service desk because - I still, I like the scenario you just did.

 

I would love, I would go back to a help desk, I'd be on a help desk again if I had that ability. I would love to know what people were using. But reality is a lot different, in IT anyway, because we've outsourced the service desk some manage service provider based on low cost. And we've said this is what you shall do and no further.

 

After that everything is now kind of pitched into the wall, over the wall into the partition our organization, because there's no continuity of belief that is just part of the same support system. So, there's no information for that poor call dispatch center that 's been outsourced. And, we love to hate them because they're doing such a poor job, but yet, we've pushed them at the end of our hands, saying, 'You're not part of this family.

 

We've just given you this Joe job here to do,' and you are not going to get any information other than just take the call and dispatch it. So how is that organization empowering, A, their front door, but B, increasing the satisfaction of their consumer coming in through that front door, through this disjointed, that's your spaghetti string over there and this is mine.

 

I mean that's just mind boggling, to think about how fundamental, because we're always, you and I, we talk about different processes and we've talked about frameworks and our printing models and governance, but, you know, support is a base element and how it really plays a big role in this idea of, you know, distributed or service desks, you know, and support models.

 

I guess distributive support models.

 

Yeah, distributive support model's a good way to say it. Now, but think about it this way. We've had this conversation before. The project culture versus the run culture. Now is this the one where everybody wants to be an artist? Everyone wants to be an artist and everyone wants to be in research and development right.

 

Everyone want's to be focused on the plan-build side of the model, and not the run. So, in that model we don't have good ongoing support, because everything is focused on projects and new capital initiatives and net new value creation. Run, that's not sexy, I don't want to bother with that, we'll just kind of keep things as they are.

 

Unless you're Flo Jo Who's Flo Jo? I don't know. She's some girl from the Olympics like a decade ago. She was a super fast runner. Sorry. Oh, I see. Okay. Dude, you know my cultural references are [xx]. There you go, Flo Jo, I've got cultural turrets Flo Jo right, but let's say I'm in project mode, which is where most IT cultures are right , all the project mode, so in the absence of good run, all they do is create new support models for every project.

 

So project A, B and C all create their own support models and end up creating support processes and support functions by application, by project. So inthis model[sp?] of forever focusing on the project versus run which is where support lives. I'm not improving the situation. I'm on going, adding complexity and distraction to the environment, adding more spaghetti to my spaghetti bowl.

 

Now that's amore. That's amore. Is the problem that we need to make RUN sexier? We need to get more interested in it, I mean...We've got to bring people up from the fact that, you know, yes, plan build is important, but it only produces the potential for value. You don't deliver value until you actually deliver it in a stable-run environment.

 

Right? So we have to get at least equal footing for RUN. Because that's where value is delivered. And the current satisfaction for the RUN processes and the support processes is at a low level because We have not paid attention to it, we haven't pulled apart the spaghetti bowl and created these distributed support channels.

 

Talking about the RUN versus the project and into the idea of consolidating this support model. It kind of brings me back to some stuff I've seen at the Pink conference. By the way, congratulations on your Arizona event.

 

Thank you.

 

You guys are having a big, when is that.

 

That's in August, that's going to be in Scottsdale.

 

We'll put a link in the show notes. Check out the pink form in August. But it reminds me of a couple of things I saw in pink the past few years, one was Paul Wilkinson talking about ABC.

 

Yes.

 

And then I think you guys might even had Ian Clayton this year talking about outside and thinking.

 

That's right.

 

I mean I would think those two, you know culture in them and customer centricity, these things, that would think they would be really important and if you're going to do this base element, to do it right.

 

Culture is what's challenging right now because we prefer to live in this, this is my spaghetti-verse and that's yours and this is my tool and that's yours, this is my process and that's yours, even though we're in this cohesive, integrated support organization.

 

Maybe we leave everybody's spaghetti alone and just give the table one spoon.

 

Yeah, we've got to figure out something relative to changing status quo.

 

Yeah.

 

But the US buck and Ian Claytons concept is exactly what we're talking about here. And I'll give him total due. We have to look at it from the customer perspective, the outside-in perspective, because when I create these support channels, they have to be simple, clear, and understandable. Because I have to know how to get support and how it occurs.

 

And that's the outside-in thinking. I had to design this distributed model from the customer experience, not from the inside, what's expedient for technology type organizations to do. Or how do I maintain my my influence, my power, and my tool without letting go of my toys. Which would be fun for the designer type people you were talking about, to envision these magical customer experiences.

 

When it comes down to the runners, the people making those experience happen, where are those people in the organization? Well, to your point, there's actually two parts to this discussion. Because we will often paint the front door and fix up the porch but not deal with the back end of this thing.

 

We actually are guilty many, many times of basically building a new front door and a new front porch, bringing in a new outside supplier to do front level, first level support, never fixing the back office IT black hole, so all we we keep getting is someone else to yell at.

 

In architecture, that's called a facade.

 

A facade, we change the facade, but then, you know, so people are on the front level, front door, answering phones and taking responses and being very courteous and polite.

 

Yes.

 

Maybe in a different and foreign accent, but the reality is they're being responsive.

 

The Greeks had brilliant facades on the fronts of their buildings. You were thought you're walking into a temple and, you know, it was nothing once you got through the door.

 

Well, it's kinda like the Vegas casinos, right? It's all a facade. Go inside.

 

We 've covered spaghetti, Greek history, facade. I mean, what doesn't this show have?

 

That's right.

 

Oh, my goodness.

 

So I can change the facade but not fix the back office black hole, the hot potato syndrome, the I lose the ticket as it leaves the service desk and never see it again until someone screams loud enough. Unless I fix the end to end process, which is this distributed model, second and third level, and have one process coherently holding that together I fix nothing except getting someone else to yell at.

 

What about the cultural aspects? So when you're collapsing - for lack of a better term - multiple support elements, whether they be rogue desks, shadow desks, rogue people. Do you ever have to consider that maybe the mini desk sits in front of ERP, those people might treat their customers completely differently than the HR mini desk sitting in front of HR and how do you align that mindset?

 

Well, there's definitely a view, and some reality to the fact that the closer the desk is to their consumer, the more affinity that desk has. And understanding of their knowledge.

 

That's interesting. So the closer a desk is to the consumer - I have to use these simple words, sorry - the nicer that desk is?

 

The better they understand the context within which they're supporting.

 

That's true. 'Cause that's different than they heard, they better understand it. They can still be mean, they just know they're mean.

 

At least they understand the context within which they're being mean, they understand the culture, that their clients better. And so that's why I'm not advocating let's for all just go to one central hunking Deskstar desk, right? We still have to maintain the distributed model which has some elements which are close to the consumer, some which are central 'cause that's still a balance we have to find but then we have to pull this together because what happens is the very remote elements of our support model will start to feel closer affinity to their consumer client, especially if they're actually getting paid by that - it's a whole other conversation - maybe we can do that next time and how do you deal with that.

 

'Cause it really is a two-part podcast.

 

Yeah, so we can deal with the rogue support agents in our next discussion. But how do I keep them part of the team connected but yet still close in providing that value added knowledge-based service that you're doing on the plant floor in the branch.

 

Totally.

 

I think if I was like a consultant and like someone actually paid me for my advice, I would say, "Okay, before we even look at the tools and the IVR's and everything." You know, doing your little mapping exercise on our graph of support, right?

 

Support Model as a support strategy we are talking about.

 

Before I did anything with tools or I would just want to sit with each team and make sure everybody was consistently answering the phone the same way.

 

Well that's the front door. But in the end I've still got to get this big picture of what does tomorrow look like Yeah.

 

model, front to back. And then I take my inventory and I start mapping it and understand how to better consolidate improve the current state to where I want to be, well maybe in today's show some people at least have the idea that it's OK that if the front door is done and you don't have to do the whole house, you can just maybe do the front door and the front room.

 

First step. Yeah. Because again, you're going to change the front door, paint it up and make it nice and pretty and easy to access. But unless you fix the back end, you're eventually going to be in the same place you were. Right now we're foyer and next time, next show, we'll maybe move into the main living quarters.

 

Absolutely, I like that. Troy, do you know what it is? It's that time. It's time for Troy's Terrible Tip of the Day! Okay, so Chris, a distributed service desk strategy is practically a necessity or a given for every organization. The goal is to untangle the current fragmented model and to improve the clear channels of support.

 

Until next time, part two, the distributed service desk rogue agents and moving into the main living area of the base element. This is Chris Dancy with Troy DuMoulin and we'll see you in two weeks.

Enclosure

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (1)

Chris, Troy,

I am a loyal llistener to your podcasts. I appreciate your work, thank you.
I have a question regarding episode 26: Do you have a link to more information on the "open ticket initiative"? My google search did not bring up much more than episode 26.
Glad to get a response from you, thanks!

Rgds

Klaus Dörner, Vodafone D2 GmbH, Am Seestern 1, 40547 Düsseldorf
Process Engineering und Quality Management
Mobil +49 (0)172-2187010
Fest +49 (0)211-533-5532
Email klaus.doerner@vodafone.com

June 21, 2012 | Unregistered CommenterKlaus Doerner

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
by Chris Dancy