In episode 118 of The Content Strategy Experts podcast, Bill Swallow and Sarah O’Keefe discuss content ops stakeholders in tech support.

“If you are delivering multi-hundred page PDFs to your tech support people, then I can assure you that your tech support people hate you. Opening a 600 page document and then having to search through it while you’re on the phone under all this pressure is not the experience that you want.”

– Sarah O’Keefe

Related links:

• Content ops stakeholders: Localization (podcast)
  
• Content ops stakeholders: Tech stack managers (podcast)
  
• Content ops stakeholders: Executives (podcast, part 2)
  
• Content ops stakeholders: Executives (podcast, part 1)
  
• Content ops stakeholders: IT (podcast)
  

Twitter handles:

• @billswallow
  
• @sarahokeefe
  

Transcript:

Bill Swallow:              Welcome to the Content Strategy Experts podcast brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way. In this episode, we continue our series on content ops stakeholders, this time focusing on technical support and field service. Hey everyone, I’m Bill Swallow, and I’m here with Sarah O’Keefe.

Sarah O’Keefe:              Hey, everybody.

BS:              And this episode is part of an occasional series we’re doing on content ops stakeholders. You can find other episodes on scriptorium.com or wherever you get your podcasts. We’ve previously discussed a few different stakeholders, including IT executives and developers. This time we’re focusing on technical support. So Sarah, how does tech support fit into content ops?

SO:              Tech support is interesting because they perhaps uniquely tend to be both content contributors at times, and also content consumers. So when we say technical support, we’re talking about the frontline people that pick up the phone or answer the chat when you call with a problem and/or in a hardware world, it might be a field service technician or a field technician, people who go out and actually fix hardware, fix machinery. So on the content consumer side, the phone rings or the service tech gets a work order and they have to fix a thing. They have to do some problem solving and fix a thing.

SO:              And in that scenario, they are content consumers. The customer calls up and says, “My thing is broken. I hate you. What is going on?” And it’s the tech support person’s job to figure out as quickly as possible what the problem is and give the customer some answers, remembering that at the point when they call, they are probably upset and angry because their product isn’t working for them.

SO:              So tech support is not just a content consumer, but very much kind of a frontline emergency, kind of first responder content consumer. On the other side of things, tech support also tends to be a content contributor because I pick up the phone, I deal with some weird problem that involves an edge case of, “Oh, they have an older version of our software and they have a weird version of Linux and they have an audio driver. And those three things together contributed to some very bizarre problem bug that we’ve never seen before.” So when something like that happens, tech support will go in and document it. “I saw this configuration, I had this combination of things and we eventually figured out that if you uninstall and reinstall the audio driver, it will work.”

SO:              So they create a case or a knowledge base article that says, “Hey, if you have this configuration or this combination of circumstances, you may also run into this problem.” And so in that case, they are content contributors after, I guess, being an attempted content consumer and discovering that particular case was not yet documented in their content universe.

BS:              Right. So given that they’re both a contributor and a consumer, I’m assuming we do have and pretty much every tech support group out there has a knowledge base that they rely on. How does that kind of feed into things?

SO:              So in theory, the knowledge base is full of these weird combinations or these weird edge cases. This is something that it’s not, “Here’s how to log into the database.” But rather, “If your login fails and you have these 16 other conditions, you might see this problem or this might be the root cause, or this is how to solve the problem.” So it’s kind of like, “Here’s a problem and here’s how to solve that particular problem.” That’s related to, but not the same as the core product documentation, which tends to be more like, “Hey, hi, type in your name and type in your password. And oh, by the way, every 90 days you’ll be told to update your password.” That’s kind of the context of what you’re going to see in the docs probably.

SO:              So the knowledge base tends to be very, very specific and situational. The problem with saying that is that’s all true in theory, but in practice, a lot of the core user instructions tend to creep into the knowledge base because as you’re answering these calls and documenting what you’re finding, you’re probably going to capture information that either is all already in the user docs so you’re duplicating, you just didn’t find it, or should be in the user docs. It’s not there, but it should have been.

BS:              Right. So in that case, you have a nice blend of documentation that resonates or I should say amplifies what’s in the core documentation set and then another complete set of information that completely contradicts what was written in the first place.

SO:              Yeah, I mean, it’s really kind of a mess, because what you really want is for the knowledge base to be the quick look up, and we want to have some sort of a loop back to the user docs so that the user docs can be updated with this new information that’s being uncovered in tech support. So essentially tech support would be to a certain extent stress testing the accuracy of the docs and finding mistakes and reporting those, but they’re also finding edge cases and then you have to make a decision as to whether that edge case belongs in the core docs or not.

SO:              We have seen a number of places where the knowledge base was duplicative. It just explicitly duplicated what was in the user docs. And then it was worse than that because it actually contradicted them, typically because the tech support content was more accurate than the user docs, because it’s based on bitter experience. And so they contradict each other. And now what do you do not to mention the fact that you have two copy or two sets of your content that both document how to log in, but do it in different ways?

BS:              Right. So they have this whole set of content that the consumer has. So this way of course they can point people to, “Oh, look at page six of this particular guide and you can see where the instruction is to do the thing you’re asking about.” How else are they really seen as content consumers?

SO:              The tech support team or the field services people are going to use what’s in the user docs to provide support. So they will look up the information that they need, or they will search for the information that they need and hope that it turns up in either the user docs or the product content. And getting those kind of into alignment can be a really big problem. Typically, if you’re, again, frontline tech support, you’re answering the phone, your number one priority is speed of search, the ability to find something very quickly, because probably there’s somebody on the phone kind of yelling at you and that’s not the most fun thing.

SO:              So they tend to push back on content formats or delivery points that are not fast. And what I mean by that is if you are user docs and you are delivering multi-hundred page PDFs to your tech support people, then I can assure you that your tech support people hate you. Opening a 600 page doc or even keeping a 600 page PDF open just on general principle, but then having to search through it while you’re on the phone under all this pressure is not the experience that you want.

SO:              So what tech support needs as a consumer is a fast search that gets them to the place they need to be as fast as possible. And then secondly, and we can argue over whether it’s more important or less important, but secondly and also critically, they need accurate information, accurate up to date information that they can get to quickly. If any of those things fail, then they basically can’t do their job or at least can’t do their job with the user docs.

BS:              Or at least not efficiently anyway, because they’re spending all their time looking up the info.

SO:              Right. And getting yelled at, which is suboptimal.

BS:              So we’ve been talking a lot about tech support for software, but what about people like field technicians or service engineers?

SO:              Right. So here we’re talking about somebody who goes out into the field, which is to say out into the world outside of their corporate environment, the product manufacturer. And they go maybe onsite in a factory to fix a machine or they go to a hospital to fix a medical device that’s not working. So the field service tech is sort of, I mean, there’s tech support, but they’re mobile tech support instead of being call them up on the phone tech support.

SO:              So as a field service tech, I show up on your doorstep, you’re my customer. And you say, “Hey, this machine is broken, fix it.” And I go look at the machine to figure out what’s going on there. Well, at that point I start plugging in the issue that I’m seeing. Maybe there’s an error code. And if I’m very, very lucky I can plug in the error code and have it tell me, “Oh, that means the battery’s low,” or, “Oh, that means you need to unplug it and plug it back in,” which I think in general is good life advice although not for medical devices. I’m not giving anybody medical device advice.

BS:              Especially don’t unplug it if you’re not supposed to.

SO:              Yeah, don’t unplug the thing. So the service tech is responsible for service and/or repairs. And so they need the same thing. They need their procedure that says what to do. How do you turn the machine off? Which part do you pull out? Which part do you replace? How do you do that? Which things do you have to unscrew and open up and disassemble to get to the piece that you need to correct, put in the new part, put it all back together, do whatever you need to do?

SO:              So service techs, I would say in general, produce less content than the technical support people. You might get annotations like, “Oh, I did step four, but it wasn’t quite right. You might want to do it this other better way,” that type of thing, but they don’t generally write extended procedures. And I think part of that is because the service techs tend to be experts. It’s like a car mechanic who knows how to fix the car. I would need 127 step procedure. The car mechanic needs a procedure that says like, “Open the hood, remove the battery, put in the new battery, close the hood maybe.” I need a lot more than that, even for something like replace the battery.

SO:              And so for a service tech you might get a very high level procedure that’s four or 10 steps, but then maybe you can expand those steps because if I can’t quite remember how do I do this one thing that I need to be doing, I can kind of expand it and it’ll give me the more detailed version of that. But service techs in general are relying on detailed standard operating procedures, instructions, how to do this. From a content ops point of view, the service techs very often want or need integration with their dispatch system. So Bill you’re the mechanic in this scenario. I’m a hundred percent sure you’re a better mechanic than I am. And-

BS:              No, we need all the help in the world if that’s true.

SO:              I’m sure you’re better at it. So you show up for work and they hand you this work order that says, “Hey, we need you to go work on this car. It has this problem and we think this is the fix.” And so you kind of get this work order that says, “Go do this thing, but it’s already got the procedure glued into your work order essentially.” Again, the work order is, “Replace the brakes,” or, “Fix the battery,” or something that I understand. And then the procedure down below is, “Oh, well, for this model, from this year in this configuration, here’s what you actually need to do to replace the brakes.” Now, again, if it’s you or me we’re going to need all the details. If I’ve been doing mechanical work on that type of car for the past 20 years, I really just need to replace the brakes.

BS:              Mm-hmm (affirmative) And likely you’ll find places where the docs are wrong and you need to annotate it so that you don’t run into it a second time.

SO:              Yeah. And if I’ve got 25 years of experience, I’m probably not even looking at the docs or I’m only looking at it to get the work order and the high level. “Wait, what did they do? Oh, no, that’s probably not the brakes. They diagnosed this problem, but I’ve seen this before and it means something totally different.” And so there’s that level of expertise, but it’s interesting because the service techs very often are, again, looking for that integration between the service management system and the procedural content that tells them how to do particular kinds of tasks.

BS:              So stepping way back, so what are the core priorities that tech support and field service has for content ops?

SO:              From a content ops point of view, again, the field services people really need that connectivity between their work orders and their instructions. On the tech support side, we ask questions about how to connect the knowledge base, whatever that may be, and the product content delivery endpoint. So basically the user docs and the KB. How do you connect those? How do you establish a good feedback loop so that people are farming the tech support database looking for content updates and corrections.

SO:              And I would say, ultimately, we really want to think about how do we distinguish between core product content and sort of support only content. And I mean, I’ve said repeatedly knowledge base versus content delivery, but at least in theory those could be delivered in the same place even if your access points or your entry point as a content developer are different. But those are kind of the things that I see as the key priorities here are connecting to what amounts to the dispatching system or service management and what that looks like. And then this question of how you align product content and tech support knowledge base content, and how you feed back into that loop to make sure that they all get updated properly.

BS:              And I think that’s a good place to leave it. Thank you, Sarah.

SO:              Thank you.

BS:              And thank you for listening to the Content Strategy Experts podcast brought to you by Scriptorium. For more information visit scriptorium.com or check the show notes for relevant links.

The post Content ops stakeholders: Tech support (podcast) appeared first on Scriptorium.