cgs-cust-svc

Understanding Customer Service Processes and Procedures

The Service-based Help Desk Model - So diving right in, what is the service-based help desk model? Well, it revolves around many different types of emphases in this space, so let's take a look at what that means. For one, you will have a help desk knowledge base, and that would potentially revolve around self-service, giving your organization a way to try to look up the answer themselves. The self-service piece can also focus on things like password changes, in addition to those troubleshooting options. Frequently asked questions are FAQs, so it's a location typically web-based, where it's a knowledge base full of information that before I pick up that phone and call my service center to fix my issue, I can look and see if the answer's there. When you're setting up a knowledge base, it's really important because it's a value add in training and educating your staff, empowering your users in your organization to make sure that they get what they need, possibly even before they give you a call. I know with the way we use technology today, many of our organizational users would much rather help themselves. A help desk knowledge base is going to be full of known issues and fixes, so these are the things that are repetitive, that do happen on a regular basis, and can be fixed pretty easily. And finally, a knowledge base provides tools to users, again to empower and make sure that they get all the knowledge they need to do their jobs, and even potentially fix some of their issues. An IT service desk focuses on many different activities, it's not just about break/fix, although my first example here is incident management. So anytime there is an issue within your organization that's related to IT, your users can pick up the phone and open a ticket and get the support they need. They should be offered multiple methods of contact, web, meaning a website, that FAQ portal we just talked about, email, phone, chat. From a phone perspective, how about a dedicated toll free number that gets them right to the help desk? These different methods appeal to all different types of users. Every organization is full of different generations of individuals, and we all have different preferences, so making sure there's multiple ways to get at the help desk and get those answers to those issues is so important. Fast response, answer those phones, answer those emails, open those tickets, and then make sure that there's a resolution that's being worked on. Not every issue can be resolved in two minutes, some can, but not every one, and so when those issues happen, ones that might take days to resolve, be transparent, call with updates daily, or ask, you know if I can't get an answer to this today, when should we follow up again? And they might say well this isn't an urgent issue so if you didn't call me back for a couple of days, that would be okay, but make sure you're making this decision with them if you're not going to call them every day. And be upfront, again transparent, let them know what to expect. Service level management and incident response is also an invaluable piece to an IT service desk, it revolves around incident escalation and coordination. So for example, a ticket might come in as a low priority, but as the morning goes on you realize you're getting more and more similar tickets. Well that might change the level of service that that ticket applies to, and what I mean you might get more and more tickets, I mean it's the same exact issue, there's a whole group of people having the same problem. And so in that case, it becomes how do you respond? How do you escalate and coordinate those activities? Now you're looking at what would appear to be a low level, low incident, low need to respond, and now with multiple people, that has just become a really high priority. Leadership may end up being involved, it might become what's considered like a Sev1 or a SevA, this is a critical issue now, and so making sure there are processes in place that help with that escalation and coordination will be so important to your environment. Standard reporting, knowing what's going on within that service desk. How long is it taking to handle a call, what's the average? What's the average speed to get an answer for that user? How often can you get that customer of your environment first contact resolution? What types of tickets are being handled by the service center, and which ones are being escalated? Is there any cross training that can occur just based on reporting on ticket types and then tracking severity and location? So if your organization has multiple sites, and the severity of those tickets is always low, it's good to understand that, or if you have a site that's remote that keeps having problems on a regular basis and they are critical, what can be done to fix them permanently, as opposed to just being passive and not looking deeper to do a better job for that location? Ticket confirmation and communication management, this goes back to that transparency, letting your customer know that you've responded to that ticket, and then making sure they know if it's not going to be resolved right away, what the plan is, updating daily, or like I mentioned before, coordinating a time where you will communicate again, maybe that's two or three days from now. Whatever the case might be, ticket confirmation and communication management are so important here. So as a customer or a user in my organization, why would I contact a service center? There are many, many reasons, but let's talk about these in further depth. So one of the things I may do is call to request information on using an existing service that the organization provides, that I'm already subscribed to. This is called an information request. I might also contact the service center to subscribe to an existing service that is being offered, so this would be considered a service fulfilment request. Or, maybe I have a new request to meet a new need to do my job, this is considered a new service request. And finally, I think a lot of help desks, instantly we go to this right, I'm calling because I have a partial loss, degradation, or total loss of a service or feature on my computer, or on my mobile device, or on my printer or whatever the case might be, in my organization. I'm calling for break/fix. This is considered incident resolution requests. So what are the organizational benefits? Let's kind of summarize this now that we've talked about some of the aspects of a service desk. Well, for one, you now can enjoy a cost controlled business model while providing excellent customer service. The controlled cost comes from the fact that you've actually planned out and organized the tools you're going to use, you know how much time and how many people you need to support, the initial calls that come in, you know how many calls are being transitioned to other teams to be fixed, cost controlled business models with excellent customer service. Keeping things extremely simple for our customers of our organization by providing them a centralized point of contact for all of their issues. That's a huge benefit. I don't want it to be complicated if I'm the one picking up the phone calling for help. I just want to know that I have one place to call, and that's it. I've worked in organizations that either don't have this at all, or they have two different types of support centers, and then it gets confusing, and so centralize it, one point of contact for all problems. This next one is huge, first call problem resolution. Now not every problem is going to be fixed with that first call, however, putting together processes and procedures for issues that have solutions that are not complex, that are routine, fit in this category and will allow for first call problem resolution. Excellent customer satisfaction, that should be the goal and one of the key benefits that your organization would achieve through this model and approach. Why and how? Well for one, you're now going to have reporting that gives you information about what was successful and what wasn't. Who's getting helped right away, who isn't? What's being escalated, what's not? How long are we spending time on the phone? Monitoring, call centers should have monitoring in place any time you're answering the phone. And I can tell you more and more I'm hearing this that there's a level of recording going on for learning. I have been on the phone lately with multiple different entities and they're upfront about this is a recorded line. That is being done for cross training purposes, so that there's a learning opportunity occurring with each call that happens with each customer. And then finally this all gets tied to evaluating measures, evaluating what can be done better. Even if everything is going extremely well, what can be done better? So here are some examples of problem resolution that I wanted to share with you. So first of all I have Staci Roberts. She gave my service center a call because her network drives are disconnected, so she's logged in, but the network drives won't let her in, and she did already reboot. So Staci in this case is extremely frustrated, she's just trying to get going, do her job, get about her day, and so what can you do as the person answering the phone? Well number one, be empathetic. Empathy goes a long way. For example, Staci, I am so sorry this is happening to you today, but let's take a look and see if we can't get this issue resolved quickly so you can continue to do your work today. Those words go a long way with that frustrated customer. Now, the nice thing about an issue with network drives is oftentimes, not always, but most of the time this is a relatively simple fix, and so in theory she should be able to have her issue resolved relatively quickly, and with the right approach, that empathetic approach, she will be happy and on her way shortly. Next we have Tim Summo. Tim is looking for some assistance because really, he just wants a new laptop, he's not calling for break/fix, he knows he's been with the company for a couple of years, and so it's time for him to find out, you know, can I get something new? So the service center takes a look and finds out that he is eligible for a new laptop in about two months, so based on this call the team put in a request, they did it now because procurement can take a couple of months, and in no time Tim will be set up with a new device. As you can see in both of these examples, a very proactive and transparent approach was used and created a large amount of success with this service center.

Customer Service Processes and Procedures - Next let's cover customer service processes and procedures. So these are the actual processes that define a core part of the success for any help desk or service desk. Let's talk about that a little bit further. So, Gartner describes customer service organizations in a way that I felt was really valuable to share, so let's think about this. They state, customer service organizations need a complex technological infrastructure that is flexible, extensible, and scalable, and so it means that you're going to have a combination of technology tools that help you with things that we've already talked about like recording phone calls, knowledge bases for both the customers and for the service center. Leadership will have ways to measure the success of all of what is happening in that service center and so as long as you have the infrastructure to support that, to do the right research creates that flexibility and is extensible and scalable, your customer service organization will be extremely successful. So let's next talk about some of the customer service processes and procedures in more detail. So first of all, understanding the organizational benefits, what is the organization gaining by having the right processes in place? Having process management goals. So for example, if my average call time on first call response is five minutes, is there a way that I can improve the knowledge base, or is there a way that I can better train my first call resolution team to improve that time? Maybe our goal is three minutes. Or alternatively, process management could be about improving the knowledge that our enterprise users have. It could be about empowering them greater, empowering them in a way that improves and reduces the number of calls that come into our customer service center, so those are just some examples. Being able to measure the outcomes, that is very strongly tied to the process management goals. We don't know what our goals would be if we're not measuring what our success rates are, and that goes back to those tool sets we have for recording phone calls, for monitoring the average call time, for understanding how many calls we can resolve without escalating. Having accurate documentation, and refining it as we find mistakes. We are all human, errors happen and they happen all the time, or maybe there's nothing wrong with the documentation, but while working with a particular customer on the same issue, a new level of the issue appears and that needs to be added to the documentation. So having a process that allows the call team to improve the documentation is so important. What else do we need to be thinking about as it relates to customer service procedures? Well, content management, we already, we started touching on this a little bit when we talked about having accurate documentation. Content management is about having the processes and procedures laid out ahead of time, and then documenting them. So what tool set will my team use for their knowledge base, making sure you're not using five different tool sets to accomplish this? From a knowledge base perspective, what should be in that knowledge base? Here's my guidelines. If you helped someone with an issue once, then the issue will occur again. You've now determined a process that you're going to develop a procedure around and document it. Make sure there's a team knowledge base. And finally, know when to escalate to that next level so that the customer gets what they need in a timely manner.

Outcome Driven Support and Summary - Outcome driven support, here's what this means. Making sure that the support your organizational users or customers receive provides them with the very best outcome. What I find really interesting is when I started out in this industry 20 years ago, it wasn't like this at all. Nobody, I mean people cared right, don't get me wrong, but nobody really thought about the outcome, no one was measuring the success of a call, no one was monitoring how long it took to replace a part, and so, it really wasn't unusual to keep someone's computer for a week or two to get a part fixed, or even work on a software issue. People weren't imaging computers, there weren't extra computers laying around to put in place, you know it's just a different time today and so today we don't try to fix software issues, we reimage the machine, and that gets the user up running much faster than years ago, because now we are outcome driven. We also focus strongly on goals for improvement. There is an industry term for this, it's called Business Process Management, or BPM, and what this is, is about understanding what processes need improvement. Because when systems are used to strengthen the wrong thing, there's no efficiency that comes from that. So stepping back and identifying what needs change will go much further. So this applies even if you're doing good things. Even if everything is going perfectly, we want to step back and still work toward improvement. By analyzing existing processes, we can do this. Managers are able to determine what business processes are most important and how improving these processes will help business performance. For example, existing business processes all should be modeled and documented, if this isn't being done, then there's an area for improvement. Also, by analyzing existing processes, the team can identify redundant steps, intensive tasks, bottle necks or other inefficiencies. There's a lot of value to evaluating this information. So always evaluating again and again, even if it's going well, to just adjust and fine tune and improve. This will revolve around your organizational environment, the technology you use, and your users' expectations, and this will all tie into designing what could become a new process. Once the existing process is mapped out and measured in terms of the time and cost, and the outcome of that particular task has been evaluated, you're now in a position to streamline a new process, document it, model it, and compare it with the old process. But more importantly, you now have a new process that can be implemented and then on a routine basis there will be continuous measurement of that as well. So here is an example of some customer service outcomes tied to their measures, so outcomes, I'm interested in my outcome being maintaining business productivity. So how do I measure that? Well, I can measure it based on restore services or features, and how long it took to get them to a satisfactory operational state. Measures could also revolve around providing guidance, and how-to information. Let's take a look at the next one. My outcome is that I want to increase the value added by IT, how could I make IT more important to the business? Well, for example I could facilitate my service fulfillment requests, or make sure my measure revolves around improving user satisfaction. I actually talked with somebody recently and I found that this was a really interesting approach that the organization they work for increases value to the business. Now this is all of IT that's involved, but to increase value to IT tied to these specific measures that we just talked about, they actually do an annual event around all the different technologies they offer, and even like how to fix those issues, like having a genius bar that talks about how they can deal with common issues on their phones. And that creates a great relationship between IT and the business, but also empowers the user by educating them, but also tied back to that centralized location for all requests, users now, or customers now get an understanding of who to talk to face to face about their issues when they arise. Okay, so the next outcome is improving business functionality, competitiveness, and efficiency. And how do you measure that? Well, assess requests for new services and features for potential fulfilment by existing services. So who is asking for the latest mobile device, or tablet, and then being able to understand why, what features are they looking for out of those devices, and then measuring the fulfilment of that by doing the research and looking at it against existing services. And then, the other measure that could be leveraged here is well, taking the opportunity to filter out insufficient justification for new services and feature requests. So if someone wants the latest phone because it's cool, that's probably insufficient justification and so what we can do at the customer service level is ask for specific details on why something is wanted, so we're not wasting anybody's time in the end. So we've just talked about a ton of things. There are so many things to consider, but ultimately your final decisions on how to handle support should align with your support goals for the business, regardless of the size, enterprise to SMB. Again, we've talked about so much today. We've talked about what it means and how we can work toward providing excellent support to our customers of our organization, how to put together well-defined processes and procedures that support the business in a way that's efficient and working with them in a way that's transparent to provide excellent support, and finally, we covered what outcome driven support is, how we can model our help desk and service center in a way that supports our users, that keeps improving processes through business process management, and improving things for the future. Coming up next, we are going to discuss using flow charts for your customer support needs.

Using Flow Charts for Your Customer Support Needs - Course Introduction and Overview Using Flow Charts for Your Customer Support Needs. My name is Theresa Miller and I am the founder and CEO of 24x7 IT Connection. Today we're going to talk about what a flow chart is, why a flow chart could be extremely beneficial for customer service in your organization, and we will go through some flow chart examples. Regardless of the type of company that you work for, flow charting is an excellent way to help make decisions and provide guidance on how to get to those decisions.

What Is a Flow Chart? - So, what is a flow chart? One way to think of a flow chart is that it's a decision tree that helps guide you to the final conclusion as it relates to a service incident, or really anything. Let's take a closer look. This definition came from Wikipedia. A flow chart is a type of diagram that represents an algorithm, workflow or process, showing the steps as boxes of various kinds, and their order by connecting them with arrows. So, that's just another way to think about what a flow chart is. Let's keep talking about this. Here's an example of a flow chart. Now, I had mentioned that a flow chart could be really helpful to your help desk and customer support needs. This example steps outside of that a little bit. This is a lamp that doesn't work, and this lamp we're going to say is in your home. So, if my lamp doesn't work, the first think I would do is check, well, is it plugged in? If not, then I plug in the lamp and the solution has been implemented. But if I get to the plug and find that the lamp is plugged in, I need to check if the bulb is burned out. If the bulb is burned out, then yes, I would replace the bulb and now I have a solution in place. But if the bulb is not burned out, then I'm going to need to repair my lamp. This is a great example of how a flow chart can help us make decisions. Now, imagine this, if you were answering phones for support needs, or answering a chat window because somebody needed assistance with their lamp. A pre-setup, pre-defined work flow like this would make it really easy to make sure 1, we asked all the right questions, and 2, that we implemented a solution that has worked before for other people.

Why Use a Flow Chart for Customer Service? - So why would we use a flow chart for customer service? When we do, we are creating an efficiency and a consistency to the decision-making process. No matter who helps that customer, the same set of guidelines are being used. It really makes the process efficient and effective. So, using a flow chart in customer service allows you and your team to identify and communicate your optimal process. Again, it doesn't matter the size of your organization. You are helping your team get to the correct solution for that particular user or customer that's calling in for assistance in a manner that's pre- defined, it is well fine-tuned, and it's the correct way to resolve an issue. So, when should I use a flow chart? A flow chart should be used to define a process to solve a problem. It should be used for communication to a team of a new process. So a brand-new issue comes up IT related, user calls in for assistance, all of a sudden there's a new issue. Let's get it documented in a flow chart with all of the steps that you tried, and in the end, the correct solution. Flow charts are an amazing way of creating process standardization, ensuring that the team is using the same steps to resolve repetitive issues. Process improvement. If the entire team has the same solution to an issue, that is one piece, but process improvement comes from the ability to see the big picture, and even add resolution steps to it. Improve that resolution process by having the big picture available through a flow chart. Additionally, diving in a little bit deeper, it helps identify areas for process improvement as well. So, let me give some examples. Inexperienced team members might follow a flow chart to help them complete activities in the right order. Or a manufacturer could ensure that it keeps to its values by applying a quality control flow chart that presents questions and decision points. Human resources might combine a flow chart together to show people who to contact about an issue and when. And so, those are even non-IT related flow chart opportunities. Imagine the possibilities for how this can improve your customer service in your organization from an IT perspective. A customer service process flow provides the overall structure for those that support customers within the service center. These processes are the efficiency and guidance that work for all team members, experienced or not.

What Level of Experience Is Expected? - So what level of experience is expected? I just mentioned that it doesn't matter. And that is the great thing about working with flow charts. Experience is not required to follow a flow chart and work with a customer to get the best possible outcome for their issue. I talked to a few users within an organization to find out what their expectations were of their customer service centers. And so, Carrie Miller is someone that I spoke with and this is what she told me about what she expects when calling in for assistance. She said when I call in for support, I understand that sometimes it will take time to find an answer. However, it's great to know whether or not my organization has put time into a structure that also allows for quick resolutions. A very transparent and well communicated process to the business will go a long way for the level of cooperation and support that you will feel from your customers. And it goes both ways. When I talk to Carrie, she needs to know that I respect her work, and that I understand she has a need, and that she needs to complete her work and not worry about these issues, and that I will do anything possible to make sure she gets back up and running the way she needs to to do her job, no matter what it takes. I also talked with Pete Selling. Pete's expectations were a little bit different. For him, he stated that it was about having a high level of quality and access to his technology toolsets. He wants us to mimic his experience with his home devices. When I step back and think about that, it is so true. That's why there are options like bring your own device to work. When we look at what we can do on our mobile devices, our tablets, and even on our home laptops and PCs, when we receive them, they just work. That's what Pete Selling expects when he gets to the workplace. And I fully support that. He should be able to do his job without worrying about things not working.

Flow Chart Examples and Summary - So we've talked about two sides of the story. One, we've talked about how flow charts provide a way to allow for superior customer service where issues and resolutions are known. We've also taken a look at what our customers are thinking and expecting when they call in for assistance. So with that, let's talk in more depth about how a flow chart that's more complex can get the correct resolution in place. And this is going to go back to the beginning, right down to the initial phone call. So, someone's going to call in and we're going to record that particular user's contact information. From there, we're going to record the detail of the request. For example, is this a request for information? If yes, then we're going to plug it in as an information request. From there, we'll determine supportability. Then we'll classify and prioritize the request. From there we'll determine supportability, and what this means is, how do we resolve the issue? Determining supportability is about locating the correct answer. Does that mean that it's in a knowledge-based article? Maybe. Does it mean that I need to talk to somebody else on my team? Maybe. But, more importantly, is there a flow chart that will provide the correct steps that I can use to answer and resolve this person's request? Once I've figured that out, we can work through those steps and resolve the request. Now there is the chance that when we get to the point of supportability, we may not be able to resolve this request. We may need to escalate, and that should be built into the flow chart. If I get to the point where all of the steps don't work, I need to escalate to another team member that has the knowledge or has the ability to work through this issue. Once the request has been resolved, we should take the time to confirm resolution and close the request. So, this doesn't mean we call the user and say, oh, it's resolved. It means that we take the time to reach out to that user or customer and ask them if they could try again and see if the issue is resolved. Once they've confirmed that the issue is resolved, you can then close the request. Don't close it before the user's confirmed that it's working. They're going to get frustrated, they're going to be wondering why their ticket was closed before they ever heard from you. That is not good customer service. And I've been in that situation. It's extremely frustrating. I've been in that situation where somebody closed my ticket when I put in a request, and hadn't even taken the time to call me. Then, when I went to check to see if my request was truly resolved, it wasn't. So the lesson here is that if you are providing end-to-end quality service, make sure that you've confirmed that the issue is truly resolved to the expectations of the user. Never assume. What happens when you do not assume? The outcome is quality service and a happy customer. Some approaches when talking with companies in terms of how they handle these situations, and even companies I've worked in, there are ways to think about how to handle this. One is, white glove service. Making sure all expectations have been met. The other way, that I feel is a really great example to share, is it's like when you go to a hotel. They take care of you. They make sure you're happy. They get the elevator for you. There's bottles of water in your room. They ask how you're doing. They say hello to you in the lobby. When you are immersed in a quality experience, you feel good when the experience is over. That is the same level of support that the customer service experience should deliver, even in IT. So, back to flow charts. Flow charting provides easy-to-understand diagrams that show how the steps of how a process fit together. And in the end, it turns into that quality customer service experience you want to deliver, and that your customers and users expect. So let's talk about the flow chart processes a little bit more in depth. When someone calls in, we're going to record the user's information. So what are some of the questions we may be asking? Well one, is the caller an internal employee, an outside user, a partner or a service provider? I've been in situations where I've called in to a support center and they said you are not an employee, you're an outside user, sorry, I actually cannot help you. And so, knowing what the expectations are when recording the user's information is extremely important. Also, what is their contact information? So I'm an internal employee and I call in, how do I reach you when I'm trying to provide you support? Record a call back number, an email address or a physical address, if that's relevant. And that may be, some businesses are so large that the location does matter. Know how to classify the request. Let me expand on this a little bit more. Is the user asking how-to questions? Do they just need to know how to do something? Is the user already using an existing service, but has concerns about not getting the desired results? In this case, it would likely be break/fix, because they're not getting the desired results. Next, when we get to the point of resolving the request, have we met their expectations? Did we give them the information that they were trying to obtain? Were we able to direct them to a frequently asked questions list, the FAQs? Is the question about something that was in the IT service catalog? Do I, as the person answering the phone to resolve the issue in the customer service role, are there any knowledge bases available that will help solve this request? And most importantly, have I leveraged the flow charts available to me to work toward resolution in a successful manner? Once that has been done, we're going to confirm and close the request. And again, it so important to close the loop with the person who called in with the question or issue. Don't just close tickets without having some form of contact with the user. That is not quality service. Which leads to my final point. Ensure that the overall experience provided quality service. A flow chart will allow for all of these aspects to be addressed if the flow chart is set up correctly. So the value of flow charting is that it records the nature of the customer request. The request resolution and changes are also captured for future issues. Flow charting leads to the resolution of incident requests in a timely manner, which ensures quality customer service for your organization. So we talked about flow charts in great detail today. We learned what a flow chart is. We talked about some customer service examples, and we discovered in depth the value of a flow chart. Coming next, we'll be having some fun with Implementing a Troubleshooting FAQ Knowledge Base.

Implementing a Troubleshooting FAQ Knowledge Base - Course Introduction and Overview Implementing a Troubleshooting FAQ Knowledge Base. My name is Theresa Miller, and I am the founder and CEO of 24x7 IT Connection. I really enjoy this topic. For years I have watched organizations figure out how to work through this type of issue, and even more than watching, I helped implement various knowledge bases. So, let's talk about how we're going to work through this conversation today. We will dive deeper into what a knowledge base/FAQ is, it can also be known as a content management system. We'll discuss the cross-training value that comes from having a knowledge base, and discuss how it leads to a supportive team environment.

What Is a Knowledge Base/FAQ? - So what is a knowledge base/FAQ? A knowledge base is a location where your help desk and support center can go for answers to issues that other team members have experienced in the past. A frequently asked question's knowledge base is extremely similar. Now the example I just provided you focuses on the support center, but some organizations use these knowledge bases for externally-facing customers as well, ways to empower the user to find the answer on their own, and we are definitely in a day and time where users are more empowered than ever, and this becomes their preference. Let's talk about a knowledge base from a definition perspective. It's a technology used to store complex structured and un-structured information used by a computer system. This is according to Wikipedia. Let's think about that. A technology used to store complex structured and un-structured information used by a computer system. That means that I need to decide which program or platform I'm going to rely on to be able to support this structure so that it works well when I need it to. So what kinds of things are we going to find in this knowledge base? It provides team cross-training. This is so important for a call center, support center, help desk. Extremely important that the team is trained in a uniform manner, in a way that provides the customer the answers they need right away. This means that it's possible to achieve first call problem resolution. This means that I am not escalating my calls all the time, or using the person answering the phone to just triage tickets and not doing anything when they first pick up that phone. This improves time to resolution for those users, getting them their answers more quickly than ever. And finally, you're going to have an overall improved support model. Now like anything, just because you put a knowledge base in place and it exists, doesn't mean it doesn't need care and feeding, so when you're making these decisions, it's extremely important to make sure somebody owns this project and gives it the attention that it needs to work toward completion. Frequently asked questions. What is a frequently asked question database or website valuable for? Well, 1, this type of resource is often shared with your entire organization, and depending on whether or not your company has an externally-facing customer service model, it could be shared with people even out on the internet. It's extremely valuable for repeatable issues, the kinds of issues that happen over and over. Having a place to find the answers in a frequently asked questions list saves time for the person needing assistance. Frequently asked questions are also resolved with repeatable procedures. Those repeatable procedures are documented and can be very easily followed to move to resolution. So how do you choose a content management system? What aspects should it have to be successful? Well the first thing I want to mention is email is not a content management system. I feel like all of us have gotten used to email always being there to hold our information. We've leveraged archiving, and PST files, and things like that, that let us go back to information we've stored, but that's not always sharable with the team, and it's not always easy to find information. Your content management system should allow for version control. You are not going to get that in email. In fact, you will have so many different versions of the same document in email that it will be very easy to get lost, so your system should have version control. Backup and recovery. Make sure that whatever you are doing has the ability to be backed up and recovered, and this can include how you leverage versioning. There are ways to do this to get back to the latest version of a document, but more importantly, if that entire content management system failed, there needs to be a recovery process for it, there's way too much important information in this database and system to have it get lost. It needs to be easy to use. We don't want our teams, whether it is the support center, the help desk, or if it's a frequently asked question's knowledge base for customers before they call in, it cannot be complicated. It has to be simple.

Cross Training Value - So what is the cross-training value of having a knowledge base? I have been part of teams, many teams, over the years where some people wouldn't share their knowledge, and that is not acceptable. Share your information. There is so much value in doing so. Let's talk about this. First of all, we're going to be able to preserve article versions. So I can go back and see what changes were made to the documentation without the person who made the changes even being in the office. We will now be able to offer our organizational users access to this information. Extreme value add for the business. This is a common mistake that I see quite a bit. One, the procedure, or the fix, needs to be documented, even if all the answers aren't available yet. Don't wait for perfection. Get the information out there for the team. It's for the better of the team overall. The document can be modified later and improved over time, as opposed to not having that information at all. Get it documented. Cross-linking your articles. So, sometimes we've written part of the procedure because it's a sub-set of a larger issue. In that case, don't re-document that process, create a link. Say start with this article, create a link to it, and then do these steps. Cross-linking goes a long way and it saves time when you're sitting down and documenting your work. And finally, have one knowledge base. Don't have multiple knowledge bases. It is going to be near impossible to find all the correct and accurate information if there are even two places to look for the information. But commonly, I see different teams using different knowledge bases, so that means an organization could have 20 document repositories. We don't want that. Make sure the organization as a whole, regardless of the size, is using one knowledge base. So why would I set up a help desk knowledge base? First, it creates self-service, empowering the user, the customer, to get the answers they need without even contacting the support center. Now, we can't have all the answers in there. These shouldn't be complicated answers. These are the repeatable issues that happen frequently that are straightforward. A knowledge base for your help desk can train and educate the staff. You're going to hear me talking more and more as we move forward about the value of training and educating staff. Again, this is for known issues and fixes. Repeatable, straightforward issues and fixes that the team can use when they are assisting customers. And finally, when you're setting up a help desk knowledge base, you are providing a toolset to your organizational users. One that is simple, and straightforward, and easy to use.

Supportive Team Environment - A supportive team environment, we're going to talk about what this means to any organization as they move into the future of knowledge bases, content management, leveraging FAQs, and sometimes I feel like this is even a lesson in general about what it means to be a team player. So even if you're not leveraging this for customer support, we're going to talk about the value of team to every individual on it. So as I mentioned, support your team. Here's how you can do that. Provide them documentation. Don't be that person that doesn't share the information they know. And here's why. Don't you want to take a vacation? How about being out sick without feeling obligated to be checking email, and still working, and be online when you really should be resting? Cross-training is an extremely valuable piece to this. Again, being able to take a vacation is so important. I personally have worked in unsupportive environments before, where individual people felt it was job security to hold that information to themselves. But in this situation, in the end, it was only hurting the team and the organization. You will personally stand out for your work through your documentation and cross-training. Team players are more valuable than individuals that are looking out for themselves. So, using your documentation and cross-training to create a supportive team environment will go much further and create better outcomes for your organization than one where each employee is in it for themselves. I absolutely love this quote and I wanted to make sure I shared it with you today. Train people well enough so they can leave. Treat them well enough so they don't want to. This was a quote by Richard Branson and ties directly into that supportive team model. Documentation, cross-training, being there to assist, is all about educating your teams and employees. It's about being there for your organization for years to come. The value of team support also leads to career growth opportunities. One, your skills are going to improve and sharpen every single time you document something and work with a team member. You are going to grow in your experiences to a degree that will lead to new opportunities within your organization. Your communication skills will sharpen immensely every time you interact with a team member and work on this supportive team model. Being able to develop training really shows how you understand an issue, so document it. It also shows your problem-solving abilities. Documenting your procedures to fix an issue goes a long way in problem solving. And finally, you are learning the business. That is one of the most valuable pieces of all of this, combined together it's even better, but when you look at growing within a company and you're in a position where you are talking with users throughout the entire organization to be able to resolve their problems, you are learning the business. You're learning the politics, you're learning who each person is, and what their value is to the organization, this is really priceless in terms of your career growth. So in summary we talked about knowledge bases and why we need them. We talked about frequently asked questions and content management and how that ties into a knowledge base. We created an understanding about why it's all about the team, because when it's all about the team, it's going to lead you to career growth opportunities that you cannot even have imagined. And that concludes our topic for today.