Episode Transcript
[00:00:02] Speaker A: Welcome to the Table Service podcast where we'll dish on all things support, success and beyond with the people and companies building the future of customer experience.
Table Service is presented by Tavolo Consulting, and I'm your host, Jordan Hooker.
Today I'm welcoming Brian Levine and Garin Tarikian to the table to talk about yeto, a customer support platform built by customer support practitioners. Who for customer support practitioners Brian and Garan. Welcome to the table.
[00:00:32] Speaker B: Hey, it's great to be here.
[00:00:34] Speaker A: So glad to have you guys. For our listeners who may not be familiar with each of you individually, we'll certainly talk about YETO as we get further in, but I'd love to hear from each of you guys just about your background, experience and what brought you to where you are now.
[00:00:46] Speaker C: Yeah, my background. I started my career in tech, actually writing API documentation for Autodesk. They made computer assisted design software for architects, and I enjoyed it. I liked working on docs, I liked writing, I liked helping people. That was great. Moved on to another company and that company had issues with its doc build tooling. So I sort of transitioned into being the doc build tool guy. After that I started working at GitHub, where I met Brian just doing documentation at GitHub. And lo and behold, the same problems happened. I became the doc build tool guy and then I sort of transitioned into just API programming for GitHub. After that, kind of bounced around doing writing and programming until.
What do you want to call it, 2019. Brian, is that the official start of the first version of yeto? Something like that.
[00:01:37] Speaker B: It feels so long ago.
[00:01:38] Speaker C: Yeah. So always straddling this line between like what I call an empathetic programmer and just straight documentation, just trying to make end users lives a little bit easier.
[00:01:47] Speaker A: Awesome.
[00:01:49] Speaker B: Yeah, And I, I didn't start in tech at all. I started as an aerospace engineer working for the military. And I did that for like 12 years. But then, I mean, I hated it. But it was, you know, stable job, sure. But. But towards, towards the end of my time there, I got really into, you know, writing some software and, and a lot of integration software, helping like one team work with other teams. And this idea of like, teams working together was like, really exciting. And I thought I should just go do that professionally instead of, I guess, this side project at the government. And that's how I ended up at GitHub, which also had this like, you know, kind of teams working together vibe back in 2013. So garden and I started like a week apart there, and that's how we met. He was on the documentation team while I joined the support team. And that was like one big team. It was like 15 people. It was one team at the time. And I eventually became the VP of support there. Garth and I worked together on that team for years. I was there for like five years. He was there a little longer. I left that I was head of support at Plaid. I did some other like head of support, VP support roles around the tech world, the Silicon Valley tech world after that. And then realized like we were kind of solving the same problems over and over. Like teams not really talking to each other. This like interconnectedness that like I'd imagined existed in Silicon Valley just like kind of didn't. And I don't know, this, this urge to like build tooling that like connected all of our teams together was just too strong.
So we, we kind of started hacking on this on weekends and, and nights seven, eight years ago now. And yeah, this is just like an obsession of mine at this point.
[00:03:24] Speaker A: Awesome. Well, I think that leads in great to our conversation here just around ghetto. You obviously hit on it there just a bit. But why go build a help desk? There's I don't know how many. Too many to count out there. There's a few major players, there's a bunch of medium sized players and there's a bunch of very, very small players in the market. Why go join a crowded market and.
[00:03:44] Speaker B: Build this tool, man? Jordan we didn't want to, we didn't want to do that.
[00:03:48] Speaker C: We didn't realize how crowded it was now.
[00:03:51] Speaker B: Yeah, originally, and this goes back like even pre YETO days, we started building some tools to help like documentation teams work a little differently, sort of like give. It was like a lot of the stuff that Garn had been building at all these other companies, like how do we turn that into a product?
But the. I don't know, my support heart aches and building stuff for like support teams to like work closer with the documentation teams and engineering teams and everything.
It was, it was too strong to put away. But we also, I mean we didn't want to build a help desk. That was not how this started. And we, we started this as what, what was. It was like a plugin for GitHub originally, right?
[00:04:32] Speaker C: Yeah, send emails to GitHub, kind of like one way sync, maybe two way sync. We had a couple nonprofits using it.
[00:04:41] Speaker B: And then yeah, we just got all this feedback from, from customers that like, it's cool. But what we really want is like our own system. We want some, like, we love Being work between support and engineering and product. And like, that capability was very cool, but it felt like they were using another team's tool.
And yeah, it was customer feedback that, that led us down the path of.
I think it was like two years ago, maybe two and a half years ago, where we were like, all right, we gotta, we gotta start over. We gotta build a help desk. That's what the people want. Give the people what they want.
[00:05:11] Speaker A: Absolutely.
[00:05:12] Speaker C: I think for me, what's interesting is I haven't. Despite how crowded the market is, I haven't heard any support person say they love their support tool. Everybody's either fighting it or it's too slow or it does too much. And the perspective, like, when, when Brian and I started this company, it was like, why didn't it just work like this? Like, developers get all these incredible tools, all these automations, all these keyboard shortcuts, whatever. And then when it comes to, from my perspective, documentation, but also support that those teams are just kind of given, you know, whatever somebody, an engineer in their spare time could, could happen to build and put together. And it works for a month and then it stops working.
[00:05:51] Speaker A: Right.
[00:05:52] Speaker C: So, yeah, for my, My perspective is much more. I'm much more frustrated. I think people deserve tools that make their jobs easier and not require, you know, a week to set up, 30 days to set up. Constantly referring to documentation. You put a developer in front of GitHub and they figure out, you know, okay, issues, labels. Got it. I can figure it out. So trying to bring that kind of, like, familiarity to support professionals is. Yeah, I think, yeah, it's been fun to do that. Just showing people kind of what is possible with dev tools.
[00:06:23] Speaker A: So I love that idea. As a support leader, I've been in this space for 11 years. I've worked with probably three or four of the major tools on the market. I've transitioned multiple companies from one to another and now one back to a completely different one, just all around. And some of that just depends on who's. Who's reliable that year. I mean, the reality is of the large players in the market, there's reliable players, and then they tend to be there for, I don't know, a year or two and then something happens and they're not as reliable. So we shift somewhere else and we get excited about the shift because we move to the new thing and, oh, it's going to be great. And maybe it is for a little while. The new features are. They're fun and they're shiny.
So I love the idea of Building something for.
Instead of just this being an afterthought.
Um, I guess my question then is from support leaders. As you're talking to them about your product, what are you hearing from them in this regard? Are they super excited for a tool that was built by people who actually do what we do?
[00:07:26] Speaker B: Obviously, like, all of the above. I think my favorite part of this, like, doing this work is getting to talk to more support people, both support leaders and, you know, level one support folks who've, you know, just started this job who are just excited about doing this work and don't know the history of drama that support leaders have for the past 10 years. And to hear, like, a support leader like you, Right. Like, we've been doing this for. For over a decade. When you sit down and you talk about your tooling with folks, it's excitement about the new shiny thing. It's fear that it's gonna go downhill fast because the last thing did.
It's anxiety about meeting expectations of your C suite. It's, you know, frustration with the tool I'm currently using. But also, I've put so much effort into this tool that I'm using, I don't wanna stop using it. Right. So it.
Right. It's not just one thing, like, people are excited about the stuff we're building and the idea of this, but there's also anxiety around it. And part of, you know, our job is to, like, help people through that. Right. And it's not just the tool, it's also, like, the people behind the tool and on our side and on your side. Right. It's. It's. It's sort of getting people comfortable with the idea that, like, things really could be better.
[00:08:38] Speaker C: One of my favorite bits of feedback that Brian received when something along the lines of, I don't think yeto can do this certain task. And we said, yeah, it's really this one button press. You have to press. And his feedback was because the UI is uncomplicated. Like, I'm used to having to click five, six different toggles to, like, get a thing. People thought that we couldn't compete feature for feature because we didn't look complicated. And that's kind of like. It's kind of.
I don't know, it's a feather in our cap of, like, okay, we, like, made, you know, a simple solution. But it's also like, yeah, challenge of just getting people to sort of relearn a new product because nobody wants to do that. Nobody wants to. You know, you've got the muscle memory of where your hand is going to go and everything. And then, yeah, in terms of support, I think support driven.
They enjoy that people within the support community are actually working on a support tool. That's another thing that you don't necessarily see too often.
[00:09:28] Speaker A: That's very true.
[00:09:29] Speaker C: So that's been pretty cool.
[00:09:30] Speaker A: Talk to me a little bit as you think about. Let's kind of zero in on that design piece because you're absolutely right. I don't know if I. If somebody hands me a tool that is not complicated to use, I am probably going to have a check in my traumatized support leader brain of like, it's got to be more complicated than this. So talk with me a little bit about your thinking around design for users, for administrators implementing this product. Why. Why choose to go the direction you did in that regard?
[00:10:00] Speaker C: Yeah, I think this is something that Nick brought to the table a lot. His philosophy was essentially, I should never have to lift my hands off the keyboard.
Meaning when you're in the flow of answering tickets, you ideally want to be able to move to the next ticket or close, you know, close the one you're looking at and just automatically have the system, you know, bring up the next one. Or being able to see at a glance who's looking at the same ticket, who's touched a ticket that's been similar to this one. Most of the design philosophy is about when you're sitting down and just trying to do your job, what is the next thing you're going to want to do? And if it's is an automation, you want to be able to grab that automation, you know, on screen quickly. You want to be able to see what you can do, what's going to happen. And then just looking at a lot of the other tools, if you look at a workflow builder, for instance, it's, you know, all of these dropdowns and all of these toggles and all of these selections which look great. It makes you feel like you can do everything, which is probably true. But at the end of the day, how do I just get this thing to automatically label if an email comes in? How do I just do. How do I just get to the next thing on my pile without having to wade through documentation?
Yeah, I think insofar as there is a visual design language, it's a lot about just staying out of the way and letting people find things through keyboard commands, mouse commands, whatever.
And I think that's served. Yeah, I think that's. That's served us pretty well.
[00:11:29] Speaker B: Something that Garan said Early on in, in building, this sticks with me like daily, which, not just the visual design, but the whole overall product design is that like a lot of tools make the easy stuff fast, right? You can automate a lot of, you know, your, your refund requests or I need a new password, like whatever your support team's like 90% problem is like, you should be able to automate that stuff and make it easy. And a lot of tools do that. But that other 10%, 20% of your, of your, your queue, right, is 90% of your time.
And no one is making the hard stuff easier, right? And so our real goal is to make the, the hard parts of your day easier to get through. And part of that is, you know, in visual design and UX and UI and figuring out like, what your next step is and having it like, lead you towards that or do it for you. But a lot of it is also kind of like the underpinning, like philosophy is that we know the work of support that this is, this is not something that we stepped into because we thought there was like this great market advantage here. There's. There's no opening in this market. Why would a PM from Google jump into this? This seems like a terrible thing to jump into. But having done this for so long and you know, Garan, having been like with these support teams for so long, seeing them struggle and building tools for, for years at GitHub, helping us get through this, I think our motivation is more on like making your life easier, not just like get a customer's answer as quickly as possible. Which is true. Like you do want to do that, but there's also a lot of stuff that is getting lost in a lot of this, A lot of the current raft of tooling that's out there. And it's that there are people behind the screen on the other side that have to go clicking through all these things to do this work. And you know, I'm not going to get into the AI portion of that right now and that it's not always a person behind and that's also a problem. But like when we, when we think of the product that we're building, the features that we're building and how we put them together, we think of the person on the other side of the screen trying to actually use it and like go from there.
[00:13:42] Speaker A: Yeah, I'm curious. I heard something mentioned here just a little bit about particularly more visibility into workflows to the actual users. Talk with me a little bit about that. That concept and the UX Because I know for me with Intercom Zendesk as an admin, I've built these things in the back. I know what they're supposed to do, whether they do it all the time and no telling, but from a user perspective. Talk with me a little bit about why you decided to incorporate more of that visibility into the work that agents are doing.
[00:14:13] Speaker C: Yeah, I think there's a couple answers to give to that. The first of which being that the people, to Brian's point, doing the job, know what they need. So kind of it seemed like a no brainer to make the automations and the workflows just simple enough for someone to come in, look at it, read it and understand what's happening. I think Intercom does a pretty decent job of their workflow builder, but the one we've got is a little more, I guess, to put it simply, like Mad libs oriented. I come from a literary background, so the idea of just you composing a paragraph or you composing a sentence that says, says when a message comes in, apply a label. It's very clear to me what the intent of that automation is versus a channel that comes in via email and web must now have to apply the following label. It's like I, I get it, you're basically, it's a difference between communicating and coming up with a, you know, facade programming language, right? And for us at least on the workflow side it's, it's much more important to have someone have the autonomy to basically say like okay, I need this system to do something for me. I need my keyboard command to get my saved reply to insert into this text. And you could do that in a, you know, a variety of different ways through whatever, like shortcut combos, whatever. But the point is that people, instead of having to turn to an admin or a manager and say like hey, can you please label and please, when it, you know, a message looks like this, can you like just make a workflow that does that? Like you yourself should be able to just dip in, you know, modify one that you, you know, workflow that you see, fork one that exists, whatever, and then again just carry on with your day.
[00:15:56] Speaker B: I think one of my favorite parts of our automation system is that you can see like blocks of automations for what a support person sees as like an experience, right? So if a VIP customer emails in, what's going to happen, right? And you, you can see all of the different like options in front of you instead of like having to document all of that stuff elsewhere. So like support person is Going to have to go into Google Docs or Notion and see should change. Like I know where to go to make that change and I don't have to like cross reference a whole bunch of different things to find that.
[00:16:34] Speaker A: Yeah, I love that concept of just more, more clarity and more visibility. Because I know as a sport leader I get questions from my team all the time about what's this supposed to have done, what's going to happen. And so I think giving them that visibility is, it saves time, nothing else. But I also think it gives them more ownership of the work they're doing. It gives them the chance to come to me and say, hey, it's designed this way. This isn't working very well for us. We need to do this differently and come with an informed opinion on that as opposed to not really knowing what's going on in the back end of the system that I've built for them.
[00:17:08] Speaker C: I was just going to say, I think just to glom onto that. I think a lot of my experience, again in documentation that support those teams can only do so much. But sometimes it's the product that needs to be fixed, right? You can document your way out of, you know, any error, or you can respond to any user that writes in and says, this doesn't work, right? Oh, you got to click this other button instead. Or you could just fix the button, right? You could call the engineer or the product team, just make the thing, do the thing. And so that's kind of what Brian and I also bring to this. It's, it's always, what is our motto this year? What else can we do? Right. Every year we try to get what.
[00:17:40] Speaker B: Else can we do?
[00:17:41] Speaker C: A five word motto. Last year was how hard could it be?
And this year it's what else can we do? So when the feature is done, we look at it and think to ourselves, okay, like, how can we make this easier for somebody? We're not interested in just shipping an MVP over the wall. These are people's like actual, you know, communication with actual humans on both ends.
Yeah, it's just always, you know, just thinking how can this be quicker and get somebody using this platform off, you know, off the computer as quick as possible so they can go take a walk or, you know, get a cup of coffee or something.
[00:18:12] Speaker B: And also I think to a large extent the difference that we're bringing to this platform, the way we design it, the way we build it, is that we're, we're focusing on how to make the experience great for the support, professional support, Agent, whatever you call that person at your company, this is a product for them. I'm sorry, Jordan, it's not for us. Most products are for the support leader. Right. They're, they're built for the support leader or the exec team. And the fact that it's support agents that have to be in there, answering tickets in there every day is kind of like a side thought. Like we can, we can treat this as a chat bot, as an email inbox. It doesn't really matter. What matters is like this data and this thing and this, this is really for the support leader. And we're, we're taking sort of the other approach that we really want the people who have to use it, you know, for 90 to 100% of their day, they should like, they should enjoy using it. They should get enough out of it that, that they feel like this was built for them.
[00:19:08] Speaker A: Yeah, I love that idea. Cause I agree. I think every tool that I've used has definitely been more geared towards what I can do and I've, I've, I've been off the front lines consistently for a while.
[00:19:19] Speaker B: Yeah.
[00:19:20] Speaker A: And so sometimes it can be hard to remember what it was like to be, to be there. So it's, it's refreshing for there to be a tool that maybe helps me remember that a little bit more as I work with my team. So thinking about 2025, you guys have been at this for a little while. You've been building, you've been growing. Talk with me a little bit about what you're trying to solve for going into 2025. Obviously you've told us your, your motto for the year. And so I think that directs some.
What does 2025 hold for Yeto in, in 24?
[00:19:49] Speaker B: We built out a lot of these pretty big parts of the app, these big features, the automation system, our labeling system, like, like these big pieces that work pretty differently from how other systems work and can be used in like a lot of different really powerful ways. 2025 is really about bringing them all together and showing off like the kind of workflows that you can run through with in action. Right. How labels can be automated and then trigger other automations.
I think the goal by the end of 2025 is for people to think of support not as a thing where you're solving problems by answering tickets, where you're sitting there typing up your answer every day. But you're really like managing this like multi armed beast that is doing this work with you. I want the support agents to feel like they're controlling like a Gundam, right. That by the end of this, I want them to feel like they have superpowers. And not just because they can answer tickets faster, but they can do more. And not just with their customers, but with their internal teams. Right. The thing that, like, started this whole product is how you work with engineering and product and sales and marketing. And how do we automate some of that? How do we, like, tell the system to, like, Go search in GitHub for an issue or open a new issue or tag the correct engineer. Like all of these things tie together. And while we have this platform that can do all these cool things, like building out the workflows around them is a large chunk of what this year is all about.
[00:21:23] Speaker C: Just to add on to that, I think, yeah, we gotta address the. I thought it was gonna.
I thought we were gonna be rid of this monster at the end of last year, but it's back, baby. AI with a vengeance.
[00:21:33] Speaker A: Indeed.
[00:21:34] Speaker C: Our perspective is not our 2025. I think a lot of it is predicated on the belief that humans matter.
So at the same time, there's a lot of stuff in both our tool and other tools that I think people aren't taking advantage of in terms of something we have right now is a documentation link suggestor. So a ticket comes in. It'll. It'll suggest to you documentation that you've, you know, given it sentiment analysis, to Brian's point summaries and like generating searches across GitHub and Jira and Slack and everything else. Like, how can you make the computer do more for the human?
Like, not on behalf of, but rather with the person.
And so I'm really excited to do that for 2025. A lot of, yeah, the last couple years have been getting all your basic searching, labeling, whatever, whatever set up, but now that we've got kind of these building blocks everywhere, it's time to start assembling them into these, you know, magnificent structures.
Yeah, it's going to be 2025 is the year of YETO. I'm calling it right now. YETO on the desktop. There it is.
[00:22:44] Speaker A: I love it. I love it. No, sounds great.
Awesome. Well, as we kind of bring this conversation to a close, I'd love to hear just from both of you, any closing thoughts that you'd like to share with our listeners around what we've talked about here. Anything completely different. We'd love to give you some space for that.
[00:23:00] Speaker B: I'm going to address the AI thing. I'm going to do it. I have been in the past pretty vocally anti AI for many reasons. I think it's an incredible technology, I think it's an incredible tool, but I don't think it alone answers any questions or problems that people have. I think Yeto is a great example of this where we, we have some AI in the, in the platform. We use some, some of it to summarize tickets or, or documentation links like Garan says. But this idea that we can automate all of support with AI platforms I think is misguided and coming from a place of not understanding what the work of support really is. And I think we're starting to see that, you know, a lot of companies last year and, you know, late 23 maybe were laying off a bunch of support teams because, oh, we can automate all of this and you can use AI for all of this and that's great. And now we're starting to see them hire everyone back because, well, it turns out like that didn't work, that didn't do a great job because they misunderstood what it is that support teams do. Support teams don't just answer tickets or phone calls or chats. They solve problems and they communicate with other parts of the company and they, you know, add feedback back to the business and they take feedback from the business back to the customers. Like they're the symbiotic link, you know, between your business and the people supporting your business.
And I'm not saying that we can't use technology to do some of that. I think the great thing that the AI boon has given us is this hunger for automation, which is great. And I wish more people saw that automation is really the thing we could be looking at and not AI as the one way to do it. And I think there are a lot of ways that we can put humans first in this work and still make it better for everyone. So that's my small rant on automation and AI that really, I think is going to be the underpinning of a lot of the work we do this year.
[00:24:59] Speaker C: It's true. He has a much longer version of that rant that goes like 45 minutes. But yeah, everything Brian said for sure, like, people are great, tools are fine, but the tools should serve the people and not the other way around. That's always been kind of my guiding philosophy.
[00:25:15] Speaker A: Yeah, awesome. Well, if our listeners wanted to get in touch with you guys to learn more about YETO or to hear the 45 minute AI rant if they so choose, which honestly, for a lot of us that, that probably actually sounds like a good idea. How could they, how could they reach out to you guys?
[00:25:31] Speaker C: Go to our website at Y e T T o app and I'm G.J. tarikian everywhere on the web.
[00:25:39] Speaker B: I am Balevine at most places on the web Ba Lavigne but not everywhere. I wasn't fast enough but you can find me on LinkedIn or just email me directly at Brian Levinetto app.
[00:25:49] Speaker A: Awesome. Well, I'll make sure to include those links down in the show notes below to make it easy for our listeners to catch up with you guys. But Brian and Garan, thanks so joining us here at the table. It's been a great conversation.
[00:26:01] Speaker C: Thanks for having us.
[00:26:01] Speaker B: Thanks for having us.
[00:26:02] Speaker A: Absolutely. Thanks guys.
You've been listening to the Table Service podcast. You can find out more about today's guest in the show notes below.
The Table Service podcast is presented by Tavolo Consulting, hosted by Jordan Hooker, music by Epidemic Sound.
