Happy to Help | A Customer Support Podcast
If you work in customer support, if you lead a support team, or if you are looking to better the customer experience for your company, then this podcast is for you!
Happy to Help is a podcast about all things customer support brought to you by the people at Buzzsprout. Join us, on the second Tuesday of every month as Buzzsprout's Head of Podcaster Success, Priscilla Brooke dives into the world of customer support to make remarkable support the standard, not the exception!
Happy to Help | A Customer Support Podcast
Communicating Effectively with Developers and Tech Support
We're diving into the complex dynamics between customer support teams and developers. Buzzsprout Co-Founder, Tom Rossi, joins us to explain how strong communication between these groups significantly impacts product quality and customer experience.
In this episode, you’ll learn how strong communication between customer support and product development fosters better teamwork, ensuring support teams stay informed and confident when changes roll out. Discover strategies for improving collaboration, from setting clear expectations and sharing positive feedback to involving support in feature planning and aligning release schedules.
We want to hear from you! Share your support stories and questions with us at happytohelp@buzzsprout.com!
To learn more about Buzzsprout visit Buzzsprout.com.
Thanks for listening!
Welcome to Happy to Help, a podcast about customer support from the people at Buzzsprout. I'm your host, Priscilla Brooke. In this episode we'll tackle the sometimes tricky relationship between support teams and developers. We'll discuss the importance of having strong communication between teams and the strategies for effective communication. Thanks for joining us. Let's get into it. This is a very important topic in the world of CX. I feel like it's something I hear a lot when I'm talking to customer support professionals, so I'm really excited to jump into it. I figured for this conversation we should have someone on from the other side, from the developer side of this relationship.
Priscilla:I like that you called it a tricky relationship.
Priscilla:I said sometimes tricky relationship, sometimes tricky relationship. I said sometimes tricky relationship, sometimes tricky relationship. I think it is.
Tom:I think it's a great description, yeah.
Priscilla:Sometimes it's not, but I do think sometimes it can be tricky and you listen to other support professionals talk about it and for some companies it's really hard to navigate. Just so everyone knows, I'm talking to Tom Rossi, who's one of the co-founders of Buzzsprout and also does work on the product and works closely with the support team as well, and so I thought having Tom on would be a great person to talk to us about kind of what that relationship looks like, since Tom and I, over the last several years, have really worked hard at making that communication really intentional and effective so that everyone's kept in the loop, and so it's just done in the best way possible. So that is why Tom is here today. So thanks for coming, tom.
Tom:Thanks for having me.
Priscilla:So, before we jump into any episode, we like to ask our guests who has made your day recently?
Tom:You know I knew you were going to ask this question and so it was fun because I was thinking back of like an experience and this was great. There's a restaurant that we go to for lunch a lot of times right near us called the local and you know I I never take credit cards anymore. I try to always do tap to pay and so I asked him if they could do tap to pay and they took my phone to go do it.
Priscilla:Like into the kitchen or into the back, yeah, into the back.
Tom:So I trust them, I give them my phone, whatever. So then, like a week later, I'm looking at my photos on my phone and there's a picture of them all like smiling and waving the whole the waitstaff. And what's great is I'm replaying in my mind like when they brought my phone back, like there was no giggling. There was no, like they totally knew that it would be a week later that I would come and see that picture and it just yeah, I loved it, it made my day.
Priscilla:Oh, that's so fun. You got to see the like. Commitment to the bit you know when you bring it back and you're like we are not going to let it go, we're just going to give it to him and we're just going to let this pay off without us present. Like that takes a lot, I think, like to let someone else have the payoff without you being able to see it.
Tom:And I haven't deleted the photo yet, and so I can't wait. The next time we go, I want to see if any of the people in the picture are working.
Priscilla:You should like print it and have it framed and then take it back and then they can hang it somewhere. That is such a good idea, that's great. I love that example because that's like a good way to have fun and humor in your customer service experience, because I mean, you could have just taken it and scanned it and brought it back. But whoever it was was like, hey, I want to do something a little bit outside of the box and like they know that you come in often, so they probably weren't taking that much of a risk.
Tom:Yeah, and it solidifies the relationship. Yeah, and it solidifies the relationship. The brand.
Jordan:No, that's really good. Well, now you guys have this like inside joke, right? So that's just too fun.
Priscilla:Right. So before we jump into talking about specifically the relationship between support and development, Tom, do you want to talk a little bit about what your typical day looks like as far as communicating with the developers and then communicating with?
Tom:the support team, sure, and a little bit too, about how it's kind of evolved, because I think this is what a lot of companies run into is when you first start a product company like ours, you're doing everything. So you're writing the code, but you're also the one that's responding to customers. And then, over time, you know, you try to find that balance of I'm spending time writing code versus spending time working with customers Right, and so I in particular, I enjoy interacting with customers. I really enjoy the good and the bad. I enjoy being able to hear feedback of what's friction that people are experiencing, what are things that they love about it, and so I really enjoy that. But it tends to be like a relief valve almost. So you're coding and you run into something and you know you just need a break. For me, it's great for me to just go pop over, open up support and see what kind of interactions are in there, and so it's totally random, I know for you and for the support team. It's weird. It's like oh Tom's in support today.
Priscilla:What is he seeing that we're not seeing? Yeah, right, right Like. Why is he?
Tom:in here. But yeah, so it's not systematic, it's not like I say, oh, I try to do X number of hours a week, as much as it's a great relief valve for me to be able to just take a break from whatever I'm doing, do a reset and go jump into support. Now that's the ideal. Now there are times, of course, when I don't have a choice Right, and so those I try to batch with a similar process of. I know that there's some support cases that are waiting for me. I'm going to wait until there's a natural break in the work that I'm doing. I just solved an issue or I just deployed some code. Now I'm going to take a break and I'm going to go knock out the support.
Priscilla:So a lot of times again, from your perspective, you'll see, you know them kind of stack up, but then all of a sudden they all get you know answered at once, or yeah, yeah Well, and it's interesting over the years, in the beginning of having like a full support department, I was the only person doing support and so you and I were in a lot of communication and it was really easy because it was just me and it was just you, or it was you and a couple other developers. And so it's interesting over the last eight years to see that grow from one support person with a couple of developers that have a very tight kind of relationship and communication style. I mean we were like two desks away from each other, so it was very easy to have that communication. But now having a larger support team and a larger group of developers working fully remote, it just means you have to be more intentional about that communication and giving it places to happen and then being intentional about sharing knowledge and having that you know something that you said.
Tom:I think that's key is that you and I worked together when it was small and it was easy, and so what happened is you kind of learned how I worked. You kind of learned, okay, if I tell Tom this information, there's a better chance he's going to knock it out now, versus me having to wait longer. But you know, if I queue him up with everything that he needs, there's a better chance he'll just knock it out right now. You also kind of got an idea of what kind of things I could do and what kind of things I couldn't do, right, and I think that that really benefited the support team and a lot of the things that we're going to talk about today. Because you're able to translate that to new members of the support team, you can say hey, look, you know this is the way that we want to do things, because it gives us the best chance of getting the developers to be able to do this in the most timely way possible for us.
Priscilla:In a way that respects them, so that they don't hate coming into support when they have to come in and help out with something. Yeah, so it's interesting, I feel like you know, over the years, when I've been in conversation with professionals in the CX or customer support space, one of the reoccurring like gripes maybe is a strong word, but like themes is this idea that the support team is so separated from the company as a whole, but from development specifically, but from development specifically. And so there's all this like oh, I found out after the fact that this was rolling out and no one told the support team. Or we're in the middle of some kind of a crisis, there's a bug and the support team is talking to customers, but the development team isn't communicating with the support team. And I'm sure that there's truth on the other side too, that developers are like I didn't even know this was a problem, that was happening because the support team isn't communicating with us feedback in that way, and so I think that there's got to be some of that on both sides. But it's interesting to me because when I sit in these conversations with people, I don't feel that I feel very out of place, because I'm like, I actually think we do a really good job at communicating with the development team, and I think what you were just saying is a big part of that is because we kind of started small and the people who started small are still here, and so there is that strong relationship. And so I think that a big way to make your product better, to make your service better, is to have a really good, strong communication between these two departments specifically, but really all departments in general, and so that's what I want to talk about is the importance of it and then shift into some strategies about how to do that in an effective way that respects all parties.
Tom:Yeah, let me add a little bit of color to that dynamic as well. I actually tweeted about this as a joke. This was a joke, but I feel like it is a bit of a. Developers can have this mentality and what I said was our product would be so much better if it wasn't for all the customers, like our software would run so much better if it wasn't for all the customers. And there's some level of thinking that way as a developer, where you're like well, don't click on that, why are you clicking on that? If you click on that, of course it's going to do something. You know what I mean, right? And I think that some organizations that actually penetrates their culture. Yeah, so that it's a relationship where you're at odds. You're literally at odds with the people that are paying your salary. You're literally at odds with the users of your software. And I think that we've been fortunate that you know we were small and we could. We appreciated every one of our customers and we've been able to scale up and continue to value all those customers. But you can definitely see that in other development cultures where it's like what I said as a joke actually becomes real.
Priscilla:People think, yeah, well, it's funny because if you look at the support side of things, a lot of times what you hear in support is you would be nowhere without your customers. Your customers are the reason that you have success, and that's true to an extent because you're also successful because you make a really good product, and so there's kind of this like balance there a little bit needed that, hey, you want to make sure you're respecting your customers and that you are listening to them and taking their feedback and letting that impact the way that you build a product. But it shouldn't be the driving force necessarily. But you shouldn't go to the other side of the spectrum where it's like we don't listen to them at all. So there's kind of like a necessary relationship there, but without one necessarily being like the only voice.
Tom:Yeah, there's another dynamic too in that typically, when there are support interactions as a developer, a lot of those are a result of the stuff that you did as a developer and it could be a bug, and so, even though it might not be a bug, there's a defensiveness. There's like a pride in that there's a pride in the work that you did, and so that's another thing that adds the somewhat tricky relationship between support and the developers, because the developer is not necessarily hearing it from. Oh, there's a customer who's experiencing a pain as much as they're hearing. Hey, you did something wrong. Yeah, you know.
Priscilla:Well and it's funny because I think I run into that a lot because I will see a bug or something that's just not working as it's intended to work in support from a customer. And then I'll just turn to a developer and say, hey, this is what's happening. And they immediately push back and I go, oh, I'm not connecting this with work that you did, I'm connecting this with paying the customer's feeling. But you, because you built it, have personal investment in it and so you do feel that defensiveness, and so it's worthwhile to think about it from both sides and, as a support professional, think, ok, I want to make sure I'm doing this with some tact when I respond or pass this off to a developer, because they might feel personally responsible or a little bit embarrassed or whatever it is, and so you want to be respectful of that. And then, as a developer, there is probably some benefit in stepping back and detaching from it as much as you can when something like that comes up. Because sometimes I'll say bug and like. Tom, I know you've been like it's not a bug and I'm like well, I didn't mean that in a mean way.
Tom:I just mean that it's not working. That's a great example. That's a great example of like hey, there's a bug with this, and then a developer might respond and say it's not actually a bug, it's user error because they did this or that.
Jordan:You know what I mean.
Tom:Well actually you could say it's a because you've allowed them to do this thing. You know Right.
Priscilla:Yeah, exactly Okay. So as far as importance of it goes, I think we both agree that it's important. But I want to talk through some specific reasons why it's important to focus on this communication specifically and strengthening it. So the first thing you know we've been talking about is that the support team and the development team overlap a lot. You know your development team is developing a product that your support team is supporting and your support team is supporting a product that is developed by your development team. It's like super simple, but you have to be hand in hand because you are helping each other out in those ways, and so I think that sometimes you can see them as totally separate, but the reality is I think I work most with the development team than any other team in Buzzsprout because we are so hand in hand. So having a strong communication there is going to make your product better and it's going to make the service that you're providing your customers better, which is just going to enhance everything. So that's like number one. Those two teams overlap a ton. I also think you know we talked about a second but communication. Having that like strong communication is going to enable that feedback loop to be shorter for customers' feedback to get to your developers easier. And you know you can put processes in place that are these big, long processes that allow customer feedback to get logged in a certain way and then that logged feedback goes through this system and then that system gets over into developer and then two months later someone on the development team sees it. But having a good, strong communication on like a regular daily basis can shorten that, so that really what's happening is you hear this feedback from a customer and you're able to pretty quickly get it in front of a developer and see if it needs to be something that's a bug or something that's the intention of the feature.
Tom:I think, the relationship that we have with our customers. As developers, we want to get input, but it's input. It's not necessarily this is what we have to do, and sometimes people overcorrect and it becomes well, everything gets logged. Like you were saying, everything gets logged and then developers get assigned to it and then they have to go address it. Obviously, if it's a bug, that's one thing, yeah, but a lot of times it's more of just something that might be hard for customers to be able to navigate and we want to come up with a new solution for it, versus, you know, just move a button because of something, and so it's figuring out how the customers have input into the development, not necessarily demanding it. It's not a sign of an unhealthy product to have interactions with your customers. Yeah, one of the things that we learned over time was when the product is healthy and growing, you have a spike in your customer support because people are first, they're first coming onto the platform, they're going to interact with it and you know that's not a bad thing. If we look at support, as anytime we get support, oh, that's a bad thing. That's because there's bugs, it's because there's something that's wrong. That's not always the case. Yeah, it can be, but it's not always the case, and so I think that all plays into why that communication is important and how you have to figure out as an organization how are you going to process that feedback? For us, it turns into the support team making pitches for things that the development team should consider adding to the product, but other organizations might have different ways. But there is a feedback loop, like you said, and it's an important communication because that's the only way you're going to hear from your customers.
Priscilla:Yeah, well, and the other thing you know, with new customers that are coming in and having that support, it can be really beneficial to hear from people who are new to the product, who haven't been working in it for years and years and years, because they're going to have a different perspective on how things work and they might have some idea or some thought about something that we hadn't thought through because we've been working in it for 15 years or something, and so that can be really valuable feedback. To get like right at the beginning of someone. It's like when you bring someone new on your team and you do a 90 day review and you're like, hey, you're new. What is it about how we work that you want to tell us before you're fully indoctrinated and now you're thinking the way we think? We want to hear your outside opinions to help us grow.
Tom:That's a great analogy because, exactly like you said, somebody who's been with Buzzsprout for a long time we've gradually added so many features. Buzzsprout has grown so much in the last whatever five years. We've added so many features and so somebody that's been through that whole process it's probably not overwhelming for them, because it was one thing here and there. But for somebody who just signed up today there is the chance that they're like a deer caught in headlights and they don't know where to go next. And you would never hear that perspective if you aren't interacting with those newer customers.
Priscilla:And then that perspective can go back to your development team, who can build something or introduce some education in the UI that helps new customers navigate through those things. So I think it can be a really, really cool way to shorten that feedback loop. Another thing I think that's a reason why you should really focus on this kind of communication is because it shows value for your support team. I mean, it shows value for the developers too. But I think it's pretty common in a lot of especially bigger companies that your support team is kind of this sectioned off group of people that support the product but they're not really in the day to day, they're not necessarily at the table with the rest of the development or the designers or marketing. Even they're like on their own. And so I think that this kind of intention behind the communication helps you bring that support team into the fold a little bit more and shows them that they're valued as important members of the team and then just gives them that I don't know reassurance that the work they're doing is valuable and not like, oh, you're over there in the support team and we'll tell you what we want to tell you, but we're not going to spend the time investing and making sure all that communication is there.
Tom:Yeah, but I think it goes both ways Absolutely. I think, the opportunity for a developer to go into a dark space and write code and never know the impact that it has on customers, and if all they ever hear is the negative, all they ever hear is the issues, the support cases that come in, versus the positive experiences that you hear, and so something that, at Buzzsprout, our support team does a really good job of highlighting positive feedback from our customers. And that really motivates developers so that they feel valued. Yeah, that's right. I spent all this time writing this code and solving this problem. It's great to hear from our customers that they value it. I think that it communicates values both for the support team, the developer and the customer, so all three feel valued if that communication is strong.
Jordan:And that would wear anyone down to just consistently hear negative feedback and never hear the good feedback. You know, if that's all you know is the bad, then you're going to think wow, I'm really bad at this.
Priscilla:at some point, Well, one of the benefits of working in support is that you are hearing positive feedback, but you're also hearing negative feedback from customers too, and you have to kind of hold both of those, and so being a developer on the other side and not hearing anything or only hearing negative can be really difficult. We at least get those like dopamine hits of, like the positive things I mean. In Buzzsprout it's a regular basis. I'm sure with some other companies it might not be as regular, but that's why we try to be really intentional about when someone says a good thing about the product and the way the product works or the design of the UI or something like that. We want to share that. Just the other day someone wrote in something nice about our newsletter and so I shared that with the marketing team because I want to make sure that they're getting those positive feedback, the positive reinforcement there, so that they're encouraged, because when your work is good and someone gives you praise for it, it motivates you to do a good job tomorrow and to just keep putting your all into it and keeping your standards high and all of that and it just makes you feel good.
Tom:And if you think about how cultures go sideways in this area. You'll hear a lot of times where support turns into tickets. Tickets get assigned to developers and that's the communication that's happening there and a lot of times it's. We want to make sure that the developers aren't wasting time. You know these nerds are expensive. Man Like you just gotta you gotta make sure like you gotta make sure that we're we're really respectful of their time, but what they end up doing is the only interactions they're having are tickets that are being created for things for them to go fix, versus being able to hear those positive interactions as well. And so you can see how that would make a culture go sideways, where all of a sudden now, as a developer, there's a resentment, because the only time you ever hear from support is when they've got, you know, stuff that you've got to go do, and it's reflected because they take that approach of oh, we want to just make sure we're limiting the communication between the two teams.
Priscilla:And developers have feelings too, you know you want to make sure that you're sharing that though, because it really is important, and I mean, I'm a very extroverted person, so to think of someone who is super introverted, who really feels comfortable working in code and being alone at their computer, like, even that person wants to hear those positive reinforcement. They want to hear that positive feedback. So I think that's really important. Another thing that I was just thinking about is that strong, clear communication encourages confidence in your work. As a support professional, you are expected to kind of be the expert on the entire product that you're supporting, and so, depending on what that product is, it can be a lot of information, and so if something new comes out or if an update gets pushed out or something, not having that communication can really be a hit on your confidence as someone in support who's trying to field questions, and so if you have that clear communication when new things roll out or when updates are made, then it really puts that confidence back in the hands of the support team and they can feel really secure in the knowledge that they have, and having that clear, easy communication between developers and support professionals allow this like easy relationship for the support team to go. Hey, I have a question about this very specific thing that I am not sure of and I want to ask you about it. And I feel comfortable coming to you and asking you about it quickly because we have this relationship and now I can go back and answer this question with confidence, instead of feeling like, well, now I have to assign this ticket to this person because I'm not sure about this, and then it becomes a much bigger thing than just hopping over and asking a quick question and then going back and finishing it.
Tom:And if you don't have that strong communication, then what can happen is you assign the ticket, right, you give it to the developer, the developer fixes it. Well, what happened? What happened? What'd you do? Yeah, and so this is something that you know. I communicate a lot with you, where you know I might send you a ping and say hey, here's something that you should know, Right? I see whatever five or six replies that show wait, there's this little piece of information that maybe you don't know, or the support team doesn't know, that I want to share. Sometimes that turns into a message that we post onto the support base camp so that way everybody can see it. Right, but the idea of investing in the support team so that they have the confidence to be able to answer those questions and understand how things work and what's funny is it goes the other direction. Sometimes, too, where we won't even remember how a certain feature works because we built it forever ago. We may have to go to the support team and ask hey, wait, what is this supposed to do?
Jordan:Or what are?
Tom:customers doing with this thing Right, and you might say, oh, nobody uses that. You might say, oh no, we hear about it all the time, like yeah. So I think that that's a good point about having confidence. The support team has confidence and that happens. The developers can help build that confidence by sharing information with a support team in such a way that they could oh, that's why we do it this way, this is why we, you know, do the things that we do.
Priscilla:Right. Well, and it comes back to. You know we're talking about feedback and sharing that when someone requests an update that we know is never going to happen, it allows us because we know it's not going to happen. We know why it's not going to happen. We know why we're not going to go down this path that they're asking for. It gives us confidence in saying no, and doing it, of course, in a respectful and kind way, but being clear about hey, this isn't a feature that's going to happen, but here's why I have information. I know why we're not going down this path because I've talked to John about why he developed it this way or why we've decided not to include this option or whatever it is, and I think that also leads back to that confidence of that's better support being able to say no when it's a no versus saying maybe I'll log it as a feature request, knowing it's never gonna happen. The better experience is actually getting the no and getting a workaround or something that's gonna help you accomplish what you wanna accomplish. It's worse support to say yes because you're not sure or say maybe because you're not sure and then leave someone on the hook like that.
Jordan:I've actually seen this in our community group, because support explains the why behind the things that we do or the features that we provide. I will see people post a question in a community group and then other members of our community will comment oh yeah, they're not going to do this and here's why. And so our community members are jumping in and explaining it to others, and so it kind of like lightens the load for the support team too.
Priscilla:Well, and it helps people that are using the product understand, like why we built it the way we built it. It strengthens that relationship because you know, I don't know it's like if your parent decides to punish you and they don't tell you why they're punishing you, like they don't tell you why they're punishing you, like they don't tell you what it is that you've done wrong. You're like, ok, well, I guess I'm just going to have to live with this because I don't understand it. And they're not taking the time to explain but taking the time to educate someone on why you've built something a certain way as much as you can. I think gets buy in from them. And if, ultimately, they decide this is not the way you built, it is not the way I want to use it, well then that's fine and they can find somewhere that works for them. But like having that understanding of why that really comes from the developers who developed it and came up with that, passing it on to the support team and having buy-in from that, I think can be a really strong experience for customers.
Tom:Yeah, and it helps build better product, because if all we do is say yes, because everyone asked for it, then you're not going to have a great product. But if you have, you know we talk about like a mantra, like we're going to be the best product to help you start podcasting and keep podcasting. And any feature goes through a lot of debate before it gets built. We let the support team into that debate conversation so that they understand how we approach building features, so that you can share that with customers. So when they ask for something that's maybe not in line with where we're going, rather than keeping them on the hook and thinking, oh well, maybe one day we'll do that, we articulate no, this is what we're about, this is what Buzzsprout is about, and I think that that's something that's always been important to us. And what the support team has done way better than we did at the beginning is communicate that message in a way that's you know, it used to be way more direct like, oh, you should go somewhere else. Here are three of our competitors and you know now you know you're much better at it, but even we had that. We had a case this week where somebody was leaving and we were very friendly and like how, how to leave and making recommendations, and it was almost like they received it as a negative to like well, why aren't you trying to keep me on the hook? Look, you already said you're leaving, right, like hey, what we want to do is make it the best experience possible for you to leave Like, and I think that that's something that the support team has added, that really it's a deposit in those customers.
Priscilla:Yeah, and we have a lot of faith in our product. We really believe that this is the best way to start podcasting and keep podcasting, and we have reasoning behind that. And so when you say to someone, if this doesn't work for you, we would love to help you find what will work for you, knowing that it's possible you go somewhere else and realize that, oh, actually I like the way they did it back at Buzzsprout, and we don't want you to leave with a negative taste in your mouth. We want you to leave with a positive taste so that if, in the future, you realize that you didn't actually need that thing that was a deal breaker before you can come back knowing that we're going to treat you with respect and kindness, regardless of whether you're going to pay us or not.
Jordan:Yeah.
Priscilla:So I feel like the most common communication between these two teams show up in kind of two scenarios escalating support questions or comments that come in, or like fixing bugs that's like one, and then the other is rolling out new features and updates. So I kind of want to talk about them in two separate conversations. So the first one is this effectively escalating conversations to development, like what strategies can we use as a support team to do that in a way that will encourage the developers to want to enter in and do their best work and support, but also be effective with time and respectful of each other's jobs, when we know that the developers are not being hired specifically to be in support right, they have other things going on in their days and so how do we be respectful of that? I have a couple strategies. I'm sure, tom, you have some strategies and some perspectives from your side as well, but I think the most important thing is when you're starting this conversation, when you're figuring out what that's going to look like. Start by setting expectations. Writes in to support. Has a question that has to go to a developer. What are those time expectations going to be, so that we're all on the same page? Is it three days? Is it 24 hours, is it a week? And finding an expectation that works for the developers, so that they're not getting tagged in an email that they have to answer in 20 minutes, and that also respects the support team, who's having to kind of hold on to this conversation with a customer, and setting that really clearly in the beginning is really helpful.
Tom:Absolutely. That was one of the first conversations we had when we started really having a support team. Right when you were, you were like I need to know, because we are very protective of our time and attention and we want people to be able to go into a deep focus mode when they're, when they're writing code or when they're answering support or when whatever work they're doing. We don't want them to feel like someone's tapping them on the shoulder and interrupting them, which is the way that support used to be. As a developer was literally like looking at your email and seeing somebody's writing in with this question and you know, kind of an interruption, and so that was one of the one of the things that we talked about was what expectations are realistic for us to set so that way I can go to a place where I can close all my windows and all I have to do is work on the thing that I'm working on. But I want to be respectful of the support team and I want to be respectful of the customer, and so I think setting that expectation and it could be different for every company- oh yeah, it'll be different for days, sometimes like days of the week.
Priscilla:One thing we run into, like we right now have an expectation of a 24-hour turnaround. So once a developer gets tagged in an email or assigned an email, they basically have 24 hours to make that first connection with the customer or get an answer back to a support specialist. That's a 24-hour window. We're going to tell people on Monday that there's a 24-hour window, but on Friday we're not going to say there's a 24 hour window because now the window is Monday, because I'm not going to have a developer held to a 24 hour turnaround time starting at 4 pm on a Friday. That's not a respectful thing to do to someone who doesn't work on a Saturday and a Sunday. And if you're a support professional, you might work on the Saturday and the Sunday, and so you have to be aware of that, and so I think when you're setting those expectations, take into consideration people's schedules. Not everyone is going to work a nine to five Like. You might have developers that are working odd hours, and so you might want to keep that in mind. So it might be different depending on the developer you assign to, as long as it's defined and agreed to on both ends. That's the most important thing is that the support team is on board with it being a good expectation and the developers feel good about it, and then if it's a deadline that keeps getting missed, then maybe you need to revisit it and go hey, this isn't a good expectation because no one's meeting this expectation. We need to change it and make sure that that's communicated.
Tom:And customers respond well to that, like whenever I've seen those interactions where, hey, you know somebody will be back in touch with you within 24 hours, nobody writes back and is like, oh, that's horrible.
Priscilla:Right. I don't think I've ever seen someone respond to an expectation of a 24 hour turnaround with anything but thanks.
Tom:This is surprising and great, because one thing that we realize as well is the developer has to respond within 24 hours, but not necessarily solve the issue. Yes, and so sometimes when they hear back from a developer and you say, look, I'm the developer looking at this, I'm whatever, I'm trying to figure it out and I'll let you know when I figure something out, yeah, but they love that they're talking to the actual developer. Yeah, you know like it buys you time and goodwill with them, right that it's like, oh, they're taking me seriously as a customer, right? Like you're never going to get that from Google okay, you're never going to get that from a lot of companies that I could name, but having the actual person write you back that communicates, oh man, they really they're taking this serious.
Priscilla:They're going to get back to me. We say this in support sometimes, where if something's taking you a long time to figure out, or if you need to pass it on to a developer and have them dig into it more, you always want to respond to the person who's writing in and let them know what to expect. So what we will say is hey, I've looked through this, I'm stumped, or maybe everything from my end looks good. I want to get a perspective from a developer and we will be in touch in 24 hours. It's kind of like you know you want to get the credit for doing that, for passing it on and escalating it to someone who is developing the product. Like that makes you feel like a VIP. We were. When we were first setting these expectations up, we were very intentional about the words we used to describe the development team, Because at first it was tech support and we thought, well, that just sounds like I'm going to send you off to an IT person. It doesn't make you feel special. And we thought, well, what are the titles of the people who are going to be the ones answering these emails? They are developers of the product. So if I tell a customer, I'm going to get a perspective or pass you off to a person who develops the product that you're using. It really makes you feel like you're getting an inside track, and so we are really intentional about that wording, because that's what's happening and we want to get the credit for it. I mean, I know it sounds a little bit like I don't know, it might sound a little bit like nefarious, be like we want the credit, but I think it's like hey, if I'm working on this, the problem is you're working against all the poor support that's out there.
Tom:Yeah, exactly, and so what you're trying to do is differentiate yourself and say look, I know you've heard from other people that they've escalated it and it didn't mean anything to you, but we're telling you that we actually have a developer that's going to be looking at this.
Priscilla:And so it's kind of like you're trying to communicate it in a different way so that they believe you that this is going to be different, exactly. Well, and then if the developer responds within that 24 hour period even if they don't solve it, like you were saying, but they respond and say hey, my name is John, I'm working on this, I have this follow up question that I need information about, or something. It's like hey, we're working on it. The 24 hours isn't a mark of hey, we're going to start working on it Through this, 24 hours is when we're working on it. So it's kind of like we're taking care of you, we're taking care of this question and we're taking it seriously. I think that communication with the customer is really important, because you could work on something for four days, not tell the customer you're working on it. The customer is going to think you've forgotten about them.
Tom:They're not going to think, yes, I haven't heard anything, but I trust that the developer is working on this because they told me after a couple of days they're not going to think that they're a priority and so that communication can be really good, and I think for us the way that we work could be different than other companies. I'm sure it's different from other people. Having that kind of access to developers, like that's important to us and we're small and nimble enough that we can do that. For other companies, though, I still think the application can be the same, which is you can still set realistic time expectations and you can still communicate in a way that is different enough that they feel valued, that they believe you, that you're going to do something. Whatever the thing is in your organization of what that next level is going to be, you communicate it. For us it's developers, but for somebody else it could be other things.
Priscilla:Yeah, when you're talking directly to a customer and something's about to get escalated, tell them what you've done, Like tell them what you've already looked into. Like I know sometimes I'll write into a support team and ask a question and then their response is I'm going to escalate this to tech and I'm like okay, but did you take a swing first, Like before you moved this on to another department? And so I think for support, it can be really again like honoring to the customer to say here are the things that I have looked through. Everything in this looks good, Everything here looks good. At this point, I think the best step is to move it to one of our developers so that I can get their perspective on it, and that, like transparency with the customer, again reinforces this idea that the customer is being cared for and that they feel like they're in good hands with your team.
Tom:It's also great for the developer, because the developer sees what you've tried and they don't they don't feel like you. Just, oh, that was a complicated question. I'm just going to give it to a developer, versus trying something on your own. You know what I mean.
Priscilla:Like yeah, and I think that that's valuable as a developer to be able to see that the support team they're trying, they're trying to figure this out Right. Well, and on top of that, it starts when the developer gets to the question. There's already been a foundation of a relationship with the customer and the support professional before it gets to a developer. So when they get to it, the customer isn't going to be angry because they're already feeling cared for, you know. And so it almost like also gives them this foundation of like. You're starting on a healthy, like. I've already gotten us to this like healthy place and now you can come in and torch it and make their day.
Tom:Like make it great, did I say torch it?
Priscilla:I don't know what you said. I couldn't really hear you Connection was bad.
Tom:We don't let the nerds speak to the customers. That's the way that we work.
Priscilla:Sometimes the customers are nerds and they want to speak to the nerds, exactly.
Tom:Those escalate directly, just to give it right to the developer.
Priscilla:I think another really important thing when you're figuring out that communication with the customer piece of it is to not over promise. So when you're a support professional, you're working with someone you don't necessarily know what the outcome will be. You don't know if the thing they're trying to do can be done. Sometimes it can't, and so you just want to be careful that you're not backing your developers into a corner that they can't get out of without being the bad guy. And so a lot of times I'll say things like you. And so a lot of times I'll say things like you know, I can't make any promises but we'll see what we can do. Or I want to get their perspective on this instead of saying like I'm going to pass this to John and he's going to fix this for you within 24 hours. That puts a lot of pressure on John to find an answer in 24 hours and also just to find an answer. It's possible that what they want can't be done or can't be done quickly, and it's a part of a bigger thing that has to be solved in a different way. So I think it's just really important when you're passing that along and you're communicating with your customer, you just want to make sure you don't back your developers into a corner, because there's nothing worse than coming in as a developer and then being like, wow, you promised that I could do something that. I can't do and you didn't know that I couldn't do this, but you know, so just be careful about that wording. And then, tom, you talked about like what information to share with the developer. I think this is probably like my favorite thing about the communication between the development team and the support team, because the way we work in Help Scout and so we use notes in emails to communicate back and forth. So, depending on what you're using, you might have a different process for that, but whenever someone on the support team assigns an email to a developer, they leave a note and in that note we are very specific about the information that has to be included in the note and it's all intended to make the developer's life easier. That is the full intention of the note, because you could easily just assign an email, not give any context, and let the developer go to town. But what's that going to do? It's going to make the developer have to do extra work, which is going to take more time, and then over time they're going to resent having to come in the inbox just the reality of it. So, like Tom was saying, like early on, I learned strategies that I could use that would make it easier for Tom to answer a question for me, which in turn, got me a faster answer and got the customer a faster answer.
Tom:And so.
Priscilla:I just want to talk about some of the things that we do that are intentional. So the first thing we do is we summarize the context of the conversation. We want to be thorough, but we don't want to be lengthy unnecessarily, so it's like a balance of being thorough in the context and being concise. No developer wants to read five paragraphs about what's going on, but they also don't want to read 14 emails back and forth either, and so finding that balance of here's the context you need I'm not including all the fluff that I waded through. I'm just going to give you the context that you need to handle this, and it might be that they need more and that you don't know what they need, and so they might have to read through the email, but at least giving them a shot to say here's the context that I know is important. I'm going to give you this right off the bat. The second thing that we always make sure we include is all of the account information that's necessary. So it might be the email that's linked to the account, or maybe it's account IDs, or maybe it's owner names or something like that. Whatever it is for your product, don't make your developers have to track all of that down as the support professional. Just throw that in there. You've already tracked it down, so just put it in there so it's easier for the developer. It takes one less thing off of their plate for them to have to do. And then I always say, like, be really clear about what you need from them. You know what's the question that you're trying to answer. Do you need them to tell you something so that you can go and respond? Is that what you need, or do you need them to accomplish a certain task? Like, be really clear about what the outcome is that you want as the support professional, so that your developer knows what's expected of them in the response that they give, whether they're going to respond or whether they're not going to respond to all of that. I think all of that helps keep that process streamlined and shows respect for your developers, respect for their time and, like Tom was saying, their deep work and all of that. Like you want to make sure that you're aware of that.
Tom:And you've already done the work. The reality is you've already done the work. If you don't do that, the developer then has to go do the work that you just did, right? So, for example, for us, one of the most critical things that support does is they provide us with a podcast ID, right, the customer number. Well, it doesn't take us that long, right, to go find it. But sometimes it can take a little bit of time because you're trying to figure out. Oh, actually they wrote in from a different email than the email that they used on their account. Well, the support team already figured that out. They've already nailed down what podcast that they're supporting them on. But you've already done the work, and so by sharing that podcast ID, it doesn't take that much more time from the support team, but it saves the time for the developer. And again, if you go back to how we work not I'm not saying that all companies work this way, but the way that we work our developers you know it might be I want to take a break from writing code I'm going to go knock out a support ticket. Well, if I go and I look at the support ticket and I've got to read 14 emails and I can't figure out the podcast ID and whatever. Well, I'm just not going to do it. I'm going to go back to my code, like, okay, I think, okay, this is going to be a pain, I'll deal with it later. And then I go back and I write code. But if I go over there and there's a podcast ID and I need you to move these episodes from one podcast to the other, and here are the IDs that you need, well, that's, that'll only take me a couple of minutes. I can do that. Yeah, but if I have to go do all the investigation, no-transcript.
Priscilla:Hey, John, will you take a look at this and let me know what you think. Yeah Right, that's horrible and then you're like, whoa, okay, there's just a lot of the weight put on John then to do that, whereas if you say, here's the outline of what just happened, here's what I've tried, here's where I'm stuck, here's the account information. Can you give me your perspective? It's completely different and it feels like way less of a burden on John. And if you want John to come to support because he's trying to like get out of the code hole that he's in and like come over into support, you don't want to make that uncomfortable. You want him to like it, because if people like coming into support, then they're going to do it more often and they're going to do it with more enjoyment, which is just going to be a higher standard and everyone will win. The other thing that I think is really important is to make responding easy. We've talked about this a little bit, but you know, people who are really good in customer support, really know how to talk with people that are from all different walks of life, right, that's one of the reasons we do the job that we do, because we love communicating with people. So if you're working with someone who's a developer, it's very possible they're like Tom and they love communicating with people and they get the ticket and they figure it out and then they respond because they love talking with people. But it's very possible that you get someone you know in your development team or tech support who doesn't like talking to people. And you want to be respectful of the expectations when it comes to responding. I always try to say I mean, we, I think, have a pretty unique situation where most of the people in our development team are pretty personable and enjoy responding to podcasters, and so that makes it easy for us. But if you work with a bunch of developers who are like I do not like talking to people, that's why I chose this profession, I don't want to be responding Then sometimes it can be really nice for them to have the option of not responding directly but just giving you the details and letting you do the responding. Then, as the support person, you can say, hey, I discussed this with our lead developer, john, and here are the things that he recommends, and then you can still get the credit for them looking at it, still make the customer feel like a VIP, but then you're doing the communicating instead of making someone who really doesn't feel comfortable in that space doing that part.
Tom:Yeah, there's times when I'll look at a. It'll get assigned to me and I'll see this long conversation that's been going on with one person. So let's say that they've been going back and forth with Kate and then it gets assigned to me. Well, they have the relationship with Kate, yeah, and so I think it can be a good experience for them to hear back from Kate, who they've been talking to, versus somebody else writing them back, which a lot of people receive. That in a negative way. It's really not a negative thing on our support team, but in other companies it certainly is where they feel like I'm starting over. There's a new person here. Okay, now Tom's writing me, but I've been talking to Kate this whole time. Tom's writing me, but I've been talking to Kate this whole time. And so there's times when I'll see a long history and I'll just be like, okay, I'm not going to respond, I'm going to let Kate respond, because I think that'll be a better experience for this particular customer. You know, and I think sometimes that's true- that's a good point.
Priscilla:Yeah, I think it is a really good point. I think it's a case by case basis too, and one way that you that feeling of like oh, I'm being passed off to another person, that's just like some random person, is when you're the developer and you're coming into an email that might have some back and forth with a support specialist. Introduce yourself, you're now entering the conversation and so say like, hey, I'm Tom, I'm a developer for Buzzsprout. Kate asked me to look into this. It starts that relationship between you and the customer a little bit, because sometimes if you just come in and the only place they see your name is in your signature at the very end, that can feel like I don't even really know who I'm talking to now, and I've been talking to Kate but now I'm talking to someone else and I don't know who it is until the very end.
Tom:That's a really good point If you respond and say hey, this is Tom. Kate shared everything that y'all have been talking about and I'm here to you. Know, do this thing. I think that's a really good way of mitigating the thought of oh well, now there's a new person I got to start over. Well, no, I just told you, kate's already shared everything with me and yeah, and it again gives you the credit.
Priscilla:Right, you're like we did all the work, we did all of the sharing of information, and so now I'm going to tell you that we've done the sharing of information, because, if you, don't say that Because they don't see those notes Exactly. They don't see the notes and so you want to make sure that that's clear. Another thing that can be really helpful when you're working on this communication and getting this set up is if you have a tone for your support team. It doesn't hurt to take your developers and do a mini tone review at the beginning of a period or something. They don't need to be like your support team experts and writing in the tone, but having an idea of what that tone is or how you've said it can help them be intentional about how they write. Just because you know, if you say, hey, we don't talk in a super, super professional way, we're really conversational, we try to be very personable, and then you get someone who isn't used to coming into support and they go OK, how do you talk like a support person? That's what I want to do. Then it's going to feel very different. But if they go, oh, I can be myself, because that's part of the tone is being conversational and friendly. That can help me take some of the pressure off when I'm responding, and so I think giving some training or some tone expectations to your developers can be really helpful. And then another thing I like to do is say, like, if you want me to review a response that you've written before you send it. Anyone on the support team is happy to do that. We have one of our developers who it's funny because he's always the person who's asking us to review his responses and his responses are probably the best of all of the developers.
Jordan:He's so good, I'm sorry, I know.
Priscilla:He's so good. I'm sorry. I know he's so good. He's so personable and kind and understanding and he is always the one who's like, hey, will you just this is a really technical thing Will you just review my email before I send it? I want to make sure that it's coming across correctly, Giving your developers the knowledge that, hey, at any point. If you don't feel comfortable responding or you want us to review one of your responses, we're totally happy to do that, Just ask. I think can also take that pressure off that might cause people to not want to get into a support inbox. Ok, so the other side of things is when new features are rolling out and that communication so it's not necessarily inside of the support queue, but just in the company conversation when new features or new updates get rolled out, what does that communication look like? Recently, sometime last year, I heard something from a support professional that was about how a feature had been rolled out and they didn't know about it until a customer emailed them about it, and that was baffling to me that a feature would get rolled out and your support team wouldn't be fully aware of that before it happened. And so I think it's more common than I realize that developers, or just you know, products in general, will push things out and not clue in the entire support team. So establish a way for your support team to communicate with your developers and for your developers to communicate with your support team, and so we just have a chat that is a podcaster success chat that all of the developers can get in I mean, anyone from the company can get in and it's open to everyone. So if someone throws a question in there, everyone has access to it, and so we use that a lot to kind of give support a heads up like hey, we're pushing out a new feature this afternoon, here's the details you need about it. Or sometimes our infrastructure team will post something and say we're going to work on something tonight. We broke something Be aware, or yeah, something broke and we're fixing it, but kind of like that communication. Having that be a clear and accessible way to communicate between the teams can be really, really helpful for the support team to stay in the loop. Another thing that we've done with big rollouts is we'll do like a new feature training type of thing, where someone from the development team will either prepare something asynchronously so maybe it's like a document or it's an FAQ or something like that that they post internally for the support team to see and access, or really for everyone to access, but the support team uses it a lot a support team to see and access, or really for everyone to access, but the support team uses it a lot. Or we'll plan a deep dive together with some people from the development team and some people from the support team to get together before something's rolled out so that we can understand the workings of it before we're asked to support it.
Tom:Yeah, this is something that's more recent. I feel like it used to be. We would just roll it out and see what happens, and now we're way more intentional about communicating with the support team to make sure that they know that adding a new button that does something cool, that could result in a bunch of emails, and you don't want the support team.
Priscilla:That's how they learned about it.
Tom:That's how I learned about it was the customer wrote in. Oh, I didn't even know this was here, right?
Priscilla:Well, and it can be as easy as saying one of the developers who built the feature jumping on a screen share with one person in support to cross that knowledge over and let them ask their questions, and then the support specialist going back to the team and saying, ok, here's a rundown, like it doesn't have to be this. Ok, we got to plan a meeting. Everyone has to be available for it. We all have to be in the same room and do this huge knowledge dump. It can be a quick thing or it can be asynchronous. You can write something up and post it for everyone to get to, and it's nice because when you do it asynchronously, you can go back and leave comments on whatever that is and ask questions specifically about this feature, and then that information is shared publicly within the company so that anyone else on the support team can access that when they run into a similar question. So I think that having that piece of it really helps the rollout go much smoother, especially in the support side. I'm interested to hear what you say about this, tom, but consider support rhythms when you're planning rollouts. We all know that. You know with developers there is an internal timeline that the development team is working on. Obviously, they're developing this really cool thing that they want to push out. But sometimes I think we've all been in a place where it's like Friday afternoon and the developers are like, yeah, we're going to push out this new thing, we're so excited about it, and the support team is like, well, we're about to sign off for the weekend. Who's going to take care of the customers that see this? And so I think just taking into consideration support rhythms before you plan that or while you're planning that, can be a huge benefit to your customers, because then when they have a question about this new thing that just rolled out, they're going to get an answer quickly and your support team who's going to feel like they don't have to now be tied to their computers all weekend because this new feature went out on Friday at 4.30.
Tom:Yeah.
Priscilla:There's a lot of truth to that.
Tom:This is something again that I feel like as you mature, you learn and you start to apply, but we used to be way more aggressive about deploying on Fridays. And now not so much. Now we will deploy fixes, sure, we'll push code on Fridays, for sure, but a new feature we wouldn't launch on a Friday. Yeah, like there's sometimes you launch a feature that you know is going to result in support. People are going to have questions about this new thing and so those in particular. We will communicate with support and make sure that we've got enough people on coverage and enough time to be able to respond to all the different people that might write in.
Priscilla:Right, and it's not just weekends, it's you know, busy times. So maybe I don't want to do it on a Monday morning or oh, half of the team is on PTO tomorrow, so our coverage is really low. Even though it's a Wednesday, it's going to be a really light coverage day, so we don't want to overwhelm those people that are working. So it's just kind of like taking into consideration those rhythms and then allowing need to be the dictator. Sometimes you need to roll it out even if you have light coverage in the support team. But avoiding that when you can, I think just shows everyone that we value you as a person and we don't want to overload you with all this work and we want to give the shot to have the best rollout possible. When something is in crisis as a development team, don't forget your support team. We have an episode about crisis management and how the support team is kind of standing in the gap between your customer and your product and making sure that when you're setting up these strategies to make that strong communication between your development team and your support team, to make that strong communication between your development team and your support team, keep in mind that when something happens, like a fire or a crisis or something like that, you want to make sure you have a clear path in that moment to allow communication to flow. And so just be proactive about setting that up before you're in the middle of it, so that your support team can feel like they are in the know and are able to communicate well with customers what they can communicate and then what they aren't supposed to put in front of the customers.
Tom:You have to have a plan for that. Those lines of communication have to be open before the crisis happens. And we say crisis, I mean like we've had issues where there's just a slowdown. You know we were doing some changes to our infrastructure and the infrastructure team went and posted on the support. Hey, just so you know you might see a slowdown and people might write in about that. It's respectful to the support team and it's better for the customer Customers, I mean. I don't know if it's just Buzzsprout customers, but when we tell them, oh look, we're doing some infrastructure upgrades, you know, that's why you might've seen, you know this thing, they're super gracious about it. It's if you go gaslight them and say, no, you didn't. Or if you don't respond like, yeah, that's, that's not going to land well, but if you write back and like, yeah, oh, I'm sorry you ran into this, this is what it was like, it just goes a long way.
Priscilla:Yeah, absolutely All right. So question for you, tom what, from your side, as a developer, would you say that the development team can do today or tomorrow to start improving this communication?
Tom:I mean as a leader of developers. I would think you would want to articulate a strategy for how do we bring support into the fold of what we do right. Like being able to articulate this is our strategy. Like support, they will give us pitches for improvement. They will communicate clearly when there's issues with customers that they're going to escalate and that we're going to go troubleshoot for them, but being able to just communicate that strategy to the developers in a way that reflects the values of the organization. Hopefully, you're an organization that values customers, and so that will come through in the way that you communicate to your developers what that relationship should look like with the support team.
Priscilla:Yeah, you know I'm on the support side. So if I'm thinking of something you can do tomorrow to start making this communication stronger, I would say, like, get the development team and get the support team together so they know each other. It doesn't even have to be work related, it can be a lunch, like let's all go to lunch and let's get to know each other a little bit more. I think one of the big reasons why this communication is not strong is when departments don't know people in the other department. So when you don't know the development team, you're much more likely to say hey, brian, can I get your help on this, or can I pass this off to you, or can you take a look at this, or something like that. I think bridging that gap between the teams because I think a lot of times they're so divided that you don't even know the people on the other side. At least when I talk to other support professionals that are in bigger companies, there's a lot of that. Like well, I know there's a guy over there named Frank. I don't know much of what he does, and so if you kind of get everyone together and start building those relationships within the company, I think that will really strengthen the communication when you get to a place where you're in a crisis or when they're rolling out a new update and you have that relationship to build on. I think it can really buy you a lot of trust there.
Tom:Yeah, and I think it's easier said than done, right, like depending on the size of the team and how you work. Like, for us we're remote, but what you articulated is one of the reasons that we do regular meetups.
Jordan:Yeah.
Tom:The opportunity to be able to get together at least once a year the whole team to be able to see face-to and interact with one another. But it's expensive. It's an investment. You have to be strategic in how you do it, but that's one of the reasons why it's important and you should do it as a remote team If you're all working in the same office. Well gosh, you got no excuse. Just go to lunch. That should be easy.
Priscilla:Well, and if you're remote, it could be as simple as jumping on a Zoom call at the end of the day or toward the end of the day, everyone having a drink and just chatting. And sometimes that can feel forced and you have to be honest about why you're doing it and say, hey guys, we're going to all get together because we want to know each other, so our communication can be stronger. Like I wouldn't try to pass it off as, hey guys, this is happy hour and we're just going to hang out and have fun, Like no, the goal is that you get to know each other. The goal is to be able to make that communication stronger, and so I think if you're honest with people about that, then hopefully it makes it a little less awkward. But yeah, that is one of the struggles with remote work is finding ways to have that personal relationships between coworkers in a real, authentic way that doesn't feel forced. I think at the end of the day, you know, the relationship between support and development is a really important one, and it impacts your team and impacts your customers every day. So taking the time now to set up clear communication strategies will go a long way in the health of your product and the service that you're offering your customers, and then just in the health of your employees as they're working together and communicating. So I hope that some of these strategies that we've talked through will be beneficial to you as you try to be intentional about that communication, and hopefully it'll ultimately make your customers more loyal and your communication stronger. So it's time for Support in Real Life, our segment where we discuss real life support experiences. So what do you have for us today, jordan?
Jordan:All right. So today we have a question from Reddit. I lead a small customer support team. We are considering providing dedicated support specialists to our customers. Do you recommend dedicated specialists or have the whole team support all customers?
Priscilla:Ooh, that's a good question. Yeah, it's funny because we are at a place right now where we do whole company support, so we don't have dedicated specialists. There are probably two or three customers that have dedicated specialists, although I don't think they know that. Oh, and it's just because they have unique situations that we want to make sure that they're getting good quality service every time, due to whatever it is that you know their situation is, and so having someone learn the context every time can be hard. Exactly, but for the most part, we do just have everyone answer everything, and I think that there are pros and cons to both of these strategies of having dedicated specialists for clients or having whole company support for clients. I mean, you think about companies that are like in insurance or in health care those products. You might want to have dedicated support specialists because you want to make sure that the information that's being shared is staying to relatively small number of people, possibly like, depending on what's being shared. You might have, over time, these strong relationships and having a individual person that you go to every time can help strengthen those. But then there's also the side of OK, well, if you have dedicated support specialists, you're going to have a longer turnaround time? Yeah, Because you only got one person and so you might email someone and they're out of the office for three days and you might not get an answer back until they come back and so that's a longer turnaround time and so it kind of depends on what it is that your customers need. Like, some of the benefits, pros and cons for doing whole company support is you have a faster turnaround time because anyone on your team can jump in and help out, on your team can jump in and help out. It allows you to balance your team a little bit better, because you can strategically schedule people to be in the inbox and kind of have coverage more. So you feel a little bit more of a balanced kind of carrying of the inbox or the phone calls or however that is. But it also does give you the need to schedule people then, because now you're working together in something and so it's a little bit less individual. So now you're working together in something and so it's a little bit less individual. So now you're working more as a team, so you have to be aware of scheduling. That can be a little bit more of a burden depending on how big your team is, but you also get the shared expertise. So you might have someone who's really great in one area and if they're not the dedicated person for that client, can they come in and share their expertise or not, or are they supposed to stay in their own lane? And so I think that there's just benefits on both sides, and I think it really just depends on what it is that your clients value and what it is that you as a team value, and how are you going to provide that for your customers. So that's what I would start by doing like step back and look at the most important things for your customers.
Jordan:Yeah, I think that's a good point.
Priscilla:And then I think from there you can make a decision on okay, this is how it works, and then, if you find that in a couple months it's just not working well, you can try the other option. We went through a phase back when we were just a team of two or three where we tried to assign out emails because we were, you know, we were noticing that reading the context was slowing us down, and so if we didn't have to read the context every time, it could help us move quicker. And so we started assigning out emails, and it did not help us move faster. Really it slowed us down. Yeah, it really did. Now we were a small team, I think we were two or three people, so it wasn't a lot, but it really did not make things better for us. So we probably did that for a month, maybe two, and then went back to sharing the inbox load and I think that knowing that you can make that change and then go back on it without feeling like, oh, we failed, that's OK.
Jordan:Just give yourself permission to experiment.
Priscilla:Yeah, exactly, and you'll find out what's the most important to your customers. Doing that, that's true, and then you can make the best decision for your team and your customers and balance that. If you have a question or a support story or a situation that you want us to discuss or shout out, you can email us at happy to help at buzzsproutcom, or text the show using the link in the description. It says send us a text or something along those lines and that text will come straight to Jordan and I and we might shout you out on a future episode with those texts. So feel free to reach out, as always. If you liked this show, please share it with someone that works in the customer support industry, or leave us a review on Apple Podcasts, or do both both would be great yeah, and I want to thank Tom for being here and sharing his perspective from the developer side. that was really awesome for us to learn from that, and thank you all for listening. Now go and make someone's day.
