Applying disruptive technologies in a familiar fashion in conservative business sectors with Tim Anderson of Kasasa

Transcript

Ledge: Tim, great to have you here. Thanks for joining us.

Tim: Ledge, thank you for the invite. I appreciate it.

Ledge: Can you give a two or three minute intro of you and your work, just so the listeners can get to know you?

Tim: Totally. I work for Kasasa. We are a community financial institution, fintech company, really geared towards community financial institutions.

We work with a lot of the credit unions and banks throughout the country. We have a suite of checking account products. We have our Kasasa loan product we just put out. That’s what we do.

I’ve been here for eight years now. I work with our implementation and support team, so once customers come on it’s our responsibility to make sure that all their data and everything is onboarded properly so that when it comes to servicing their consumers they can do so in a way that they’re proud of.

Ledge: It’s interesting because I don’t think a lot of startups or small companies really think about that technical operations and onboarding. There’s a little bit of discussion around customer success, or whatever that is. Is that part of marketing? Is that part of sales? Where does that happen? How does that intersect with the actual developers and the engineering teams?

What’s your experience of best practices there?

Tim: Customer success and customer experience has to be cohesive throughout all those realms. From product ideation, through development when things get built, you need to take into consideration how it’s going to impact your clients, how it’s going to impact your users, your internal, your external users, your consumers. You’ve got to take that all the way through.

Specifically now in the age of so much customer data being available, and a big part of customer experience is that personalized experience. Not only from a support standpoint, but also from a usage standpoint.

From a financial institution standpoint, for example, if I log into internet banking and I already have an auto loan and you’re advertising to me for an auto loan, why are you doing that? I already have one of those. It’s not something that I should be a target for.

When it comes to marketing, product ideation, service, all those things have to be intertwined together.

Ledge: Before we started recording, you made a great point about how you guys are serving a traditionally maybe slow-moving or conservative area of the banking sector. It’s not the place that you think, hey, there’s going to be this cutting edge, disruptive revolution because that would be literally be cutting the knees out from your customer. There’s this fintech disruptive hype cycle narrative that I think is maybe not accurate to the people that are doing great things in the space.

Tim: It’s a little bit out of that. It is accurate, to a point. It is very disruptive. The products are very disruptive to what we have. But, like you had said, the industry itself is, by nature, conservative. If you are going to be disruptive in the realm of service or in the realm of product, you have to do so in a way where the feeling that customers get or the feeling that consumers get doesn’t feel like they’re interacting with something that’s completely new to them. They have to feel like they’re still interacting with something familiar.

When I say familiar, I don’t even necessarily mean something familiar to the banking industry. If you were to put together an app, for example, to interact with your accounts and you’re using that app, I’m not comparing that app using to, how good is a megabank app usage. I’m going to compare that app usage to, how user friendly is that app compared to the other apps that I use? Without you really knowing it, I’m comparing my mobile banking app to Uber. I’m comparing my mobile banking app to Lyft, to the different types of applications that I’m using every single day and not necessarily just in that fintech space.

The trick is to be able to be disruptive, to be cutting edge, but to do so in a way that’s familiar to your clients and your consumers.

Ledge: Do you have some recommendations? Tips, tricks, things that work in that space? Bring it down to the tactical.

Tim: Sure. One of the things that is most exciting right now throughout customer service is AI. Whether or not you’re using AI in the realm of machine learning, and whether you’re using it in the realm of communications chatbots, and whatnot. Chatbots are probably the most common use of AI right now that you see in the customer service world. If you can combine a good natural language processor to figure out what your customers are asking for, and you can do it in a way where they’re not feeling like they’re talking to a robot, that’s how you can really win over your customers.

If you think about what customers actually want from a service perspective, what they want is they want friendly, personalized service. They want it across multiple channels. They want it to be convenient. They want it to be quick and consistent.

So, whether or not I text you, I call you, I chat you, I interact with my portal online, they want that service to be personalized and consistent.

AI really comes into play there, and that’s something that personally I’m really excited about being able to continue implementing.

Ledge: What’s the difference? How does that work where, some of those things you just know this is a robot, and some you know I have a live person who doesn’t really know what they’re talking about? There’s this whole Turing Test sort of evolution that’s going on. Sometimes the robots are really getting so good that I kind of can’t tell.

What is that? Where’s that coming from?

Tim: First of all, the robots that are really good are really good. Earlier today, my phone rang from an unrecognized number, and as soon as you pick it up if you hear you missed the beginning of the sentence, you can tell by the tone it’s just not a person, it’s almost getting to the point where it’s offensive because now you just wasted my time.

The difference is understanding where those limits are. Especially in the industry we work in where like we were saying it’s a very conservative industry, you’ve got to make sure that if people do interact with AI or interact with a chatbot, they don’t feel that way. The natural language learning is a big piece of it and that comes from big data. It’s not something that you can necessarily build on your own. Typically, it’s something you’re going to purchase a vendor for, but there’s a lot of really good vendors out there for it.

The difference is whether you send a chat that says, ‘I’m locked out of my account’ and the chatbot knows, “Oh, no problem, let me reset your password.” Or the chatbot responds with, I’m not sure what that is, let me give you one of these canned answers. As smart as chatbots are, they can’t do human reasoning for diagnosing complex issues. They have to be able to have a really warm handoff process where you can hand it to the right person so you can get that issue resolved at the right time.

Some of the exciting things that come from the AI involved in that is when it does come to the right person it can get it resolved quickly, but it comes with all of the relevant information from that existing issue plus any previous issues that are tied to that. From a customer service perspective, when you can implement AI as a complimentary asset to your human service representatives, that’s when you get the best benefit from it.

Ledge: Give me a rundown if you can – maybe it’s proprietary – but what’s the toolchain look like for your operation? You’re really doing this at quite a big scale and there’s got to be a lot of stuff that works together there.

Tim: There is a lot of stuff that works together, for sure. You have to have your systems talking to each other.

In an earlier episode I was listening to you had Christine Spang, she talked about build versus buy for connectivity. You have to be able to connect your proprietary internal databases with your tools moving forward; your CRM, your case management system.

I’ve got a lot of experience using Salesforce, and for me Salesforce for case management works really well. They have a natural language processor built into there specifically for chatbots that seems to work really well. You can program a bunch of other things into it, but you do have to kind of program that workflow to the handoff. Whether that gets handoff within the system to a service professional, or it gets handed off to an external API, for example, that’s going to run a query against a database and return that result to the client, you have to have all those workflows built together.

The tool stack is really, what are you going to use from a customer facing perspective? Whether it’s your customer-facing portal – Salesforce has got a bunch, Zendesk has got some. There’s that option. The chat option. Then also on your backend, what’s going to talk to your databases?

Ledge: When you guys do custom development. Is it going to be a lot of the middleware between there, or custom product development? How do the two bump up against each other?

Tim: We built everything in-house for a long time. Our internal data structures, our DevOps team, CloudOps, all of our internal stuff is built by us. It really came down to the choice of whether or not we want to build a customer-facing portal, or build a chat tool, or build the AI involved in it, or whether or not we’re going to partner with somebody. At some point, you have to see what the return on that investment is.

Now, when you do decide to go with that vendor – again, in our choice we went with Salesforce – you also need to understand that it’s not going to be out-of-the-box. There’s going to be continuous development involved. There’s going to be continuous requirements gathering, internal teams.

On our side we have a business process management team that works directly with the vendors, that gets requirements from all over. Me, as a representative for technical operations, regularly interact with the product team for, how do you want this product to be functioning within market? We work with our product owners, product managers, as well as the developers individually to say, hey guys, this is what the vision looks like, here’s how we’re planning on getting there, let’s work together on what the details start looking like now.

Ledge: You run the support operations, essentially. We talked about the handoff between what would be the AI to human handoff to take care of an end customer issue. Typically in support, there’s an additional handoff from that Tier 1 customer interaction to maybe Tier 2, to Tier 3. Where at one point or another your support person has to go, “I’m going to escalate this to engineering.”

I’m curious, how do you handle that and know where those incidents live and how the responses can and should come back, You don’t want to ever put your support operations in the place where, oh god, we have to send it to engineering and the reality is we really feel like this thing is going into the black hole. How do you integrate those functions?

Tim: Well, there’s two different sides to that scale. As a support representative, I don’t want to feel like I’m putting something into a black hole, but as a support representative I also don’t want to feel like I’m overwhelming my development team, because I need those guys to finish working on what is most likely the improvements that are going to start making my job and my life easier and our clients enjoy the product more.

There’s the balance of, how do I have a channel where I can quickly get help when I need it, to, how do I not abuse that channel?

Really, it comes down in my mind to, what can you measure? There’s a rule of thumb. We’re all human beings. At Kasasa we have the luxury of working in the same building, for the most part. What we say is, if it’s going to take you longer to put in a case than it will be to solve the problem, don’t bother putting in a case. But, if it needs to be documented, it’s got to be documented.

For us there are subject matter experts on the team where everything kind of flows through these two guys. Those two guys have the ability to decide when we need to escalate over the development team. They work directly with the product owners on the team to make sure that either the issue is documented when it has to be, or that resolve it quick.

From an SLA standpoint, it’s tough because you want to be respectful of the work they have without disrupting the sprint that they have going on. You end up in the situation where you are talking to clients about – like if I’m relaying to a client where your issue is, we’ll work with the development team and you end up communicating not necessarily when a resolution is going to be had, but when I can get an update for you.

The concern of, this is going into a black hole, is also felt on the consumer side as well. Being able to avoid that by over-communicating.

For us personally, we have JIRA as our case management system for development where things go. We can measure SLAs out of there. We can measure how long things take. How many people have interacted with it. Things like that.

Most importantly, you have to be able to see trends. If I start seeing things coming up around a configuration screen, for example, well then we’ve got to take that to the product manager and say, “Hey, look. Here’s an opportunity for us to invest some time from the development side that’s going to save not only time on the backend of support, but also make the experience better for the users.”

Ledge: It sounds like you guys have really developed an equal love, equal opportunity culture where there’s a product input from all the stakeholders. I can remember organizations, and maybe more back in the day, but support was the throwaway job and nobody wanted to talk to the customer. Things have really evolved since then.

From an advocacy standpoint, how does that happen and how do you do it right?

Tim: Well, it goes back to the first question you had was, how do you tie these things together and the understanding that support is a function of the product as a whole. It’s a function of how well your product is working in the market. You have to take that into consideration. How well your product is being marketed.

Customers talk to each other. If your product isn’t good to use, if your support isn’t something that they want to interact with – especially in the community banking industry – customers talk to each other. You want to make sure that you keep that reputation up.

How do we interact with each other? We have the standard stand-ups regularly. We have representation within the development team for stand-ups. We have prioritization. About every two weeks we go through prioritization with the product management team. Just the standard rituals that are involved in an agile development shop, we just make sure that we have representation in those.

Representation is great, but you need to have buy-in of the importance. That’s kind of a top-down approach. If a Chief Technology Officer didn’t believe that supportability was a crucial function of the product, then my representation wouldn’t mean any more than one more seat filled in that room.

Our Chief Technology Officer does understand that supportability is crucial. We call it commercialization, as far as how easy it is to use our product. Usability, UI, UX, all those types of things. It’s kind of a top-down approach and just making sure that…

I mean, we’re all human beings. At the end of the day, we’re all human beings and it comes down to building relationships and leveraging relationships.

Ledge: Absolutely. Last question. I was thinking about how do you know, as a growing organization, when you start thinking about making a full support and customer success sub-org? That it’s no longer tenable for the main developer to be answering support tickets.

Now, you could go in and out. Some people really are advocates of the, hey, you build it you support it, you build it you operate it.

What’s that tipping point for the org so you could start to leave the engineers to develop product, and then separate out that support piece?

Tim: There’s a couple different iterations that products go through. You have the whole ideation phase where you’re really just testing this product in-market to see if it’s even worth building, frankly.

Then you have your transformation phase where you have your first few of them that are coming up. You’re at maybe 15 to 20 or so. Again, the development team is probably pretty heavily involved in that process because you’re learning. You’re continually learning more things about more product, you’re finding more edge cases and you have to address those issues.

From there, you really get into your production mode. One of the things I believe and what we practice here is that, whenever you do release a new product you really have to go through three processes.

You have to do your first of five, which is going to be real dirty and just figure out if the thing works. You’ve got to go to about 15 to 50 to figure out what are those edge cases. Then you’ve got to hit your prime time. By the time things get to prime time, by the time you’re over 50, you need to make sure that your development team is focusing on the things that are going to enhance that product, not the things that are going to keep the product moving.

That kind of transformation zone, I think, is where you need to make that step.

Ledge: Tim, thanks for spending time with us. Great insights.

Tim: No problem, Ledge. Thanks for having me. I do appreciate the opportunity. I think you’ve got a great thing going, and I’m glad I was able to listen to a couple more of your podcasts and hear a little bit.

Hopefully giving some insights into what the customer support experience is like will help your engineers out.

Ledge: Thank you so much.

Tim: Thanks.