Fireside Chat: Empowering Your Customers to Upload Clean Data
Customer data is needed to power your product. But ingesting that data is easier said than done. Tune in to hear how Animesh Pathak, head of R&D and Engineering, and his team at myKaarma are solving this problem and empowering their customers along the way.
Fireside Chat Transcript
Kirat: Hello everyone. Welcome to another one of our Osmos webinars. I'm Kirat Pandya, I'm the CEO at Osmos. And today I have with me Animesh Pathak, who is the head of R&D and engineering at myKaarma.
Thank you for taking the time, Animesh, to come and chat with me. Why don't you take a moment to introduce yourself.
Animesh: Thank you for having me here. Hi everybody, my name is Animesh. I often call myself a recovering academic. I've been with myKaarma for seven years and some little more now as the head of R&D. Having started when the organization was about 30 people, now we're about six times as large, having grown through many stages of growth from a small startup to what is definitely now a market leader in our particular sector.
Previously, I used to be a research scientist. I used to work for the French government in Paris. I'm a proud Trojan. Fight on. So got my PhD at USC and proud of that. Grew up in India, got my undergrad from IIT (BHU) Varanasi. So lots of computer science and all that background.
From a company perspective of myKaarma, we are a B2B SaaS organization. We work with car dealerships and we have about 1700 odd car dealerships now. The usual big brands, the Mercedes, Porsche, BMW Mini, Audi, Kia, all the various brands that, some of them we have very deep relationships with. And for me it's been a lot of fun just seeing good tech difficult problems applied to real world issues of business processes in this case to give exceptional interactions to our customers' customers. So it's been fun.
Kirat: Yeah, I mean, can I just say I really like the pun in the name of the company, that's pretty cool. Anyway, so working with your organization, number one, I'd never really wrapped my head around the complexities that go into how dealerships interact with customers on a sort of lifetime relationship basis. I think most people think of CRMs, they think about Salesforce, but that is one flavor of the problem. Industry specific CRMs is its whole separate problem space that most people don't even run into if they work in that industry. Can you tell me a little bit about how data fits into that larger picture for you?
What makes customer data so important for your business?
Animesh: Sure. You're exactly right, a very common thing. Those of you who are listening who have bought cars would agree with me when I say nobody wants to buy a car, everybody wants to drive a car. Buying a car is one of the more stressful, crazy experiences. Driving hopefully is a better experience. And what I realized, which was very surprising for me was so much effort goes into keeping the customer happy during the vehicle's ownership experience. If you look at classic US lease times and stuff, you may have a three year lease, let's say. After three years, you'll hopefully want to get a second lease. Well, with whom? That question will be determined by how optimally you were treated during the ownership experience.
For us here, data comes into play very much in that story because ideally a dealership will have... We can just call it front office and back office. The front office would be people whom you meet when you get your vehicle service. So your service advisors, technicians, your parts managers and so on so forth who play a role in getting a vehicle handled at the moment. However, the dealership also has a call center or as it is known in the dealership world, a business development center, a BDC. Whose job is to do outreaches to dealerships. So if there's a recall, it is the BDCs responsibility to reach out to customers and say, hey, Mr. Pandya, your vehicle has ABC recall, it's a safety issue. We'll come pick you up. But that outreach has to happen.
The moment that outreach has to happen, you start running into very interesting interoperability issues because that data for this recall may have come from an email with a PDF that was sent by the car company to the dealership. Now I'm making a terrible example here, traditionally the system’s slightly better, you can download CSVs. But it's a CSV. And the format of the CSV is not guaranteed to be interoperable with a system like myKaarma. And that is immediately the genesis of the problem. And the sad reality of this all is that the systems in some cases are so backwards and so horrible that the people who use these systems don't even realize that there could be a better way. So they would give into fate if you will, and type out the number and type out the thing and make the entry completely by hand.
And the format of the CSV is not guaranteed to be interoperable with a system like myKaarma. And that is immediately the genesis of the problem.
Kirat: Have excel on one side and type each thing out into the browser right?
Animesh: Yeah, I've often heard the term civil share integration. That's very sad and unfortunately part of the course. And that's where these very interesting problems arise.
Kirat: Yeah, I mean it's interesting that you mentioned that people sort do the effective copy paste solution here. When you think about your end users where on the technical spectrum... Technical, maybe not be the right term, but how do you reason about how much technical complexity you put in front of them in terms of do they even need to know what a CSV is? How do they you think about that problem?
How do your customers think about this problem?
Animesh: So I've been wrong a couple times when visiting dealerships. After a couple of rounds of doing this, I've now begun to realize that the people who use softwares at dealerships, a good number of them are pretty technical, partly because they can fix cars. I can't fix a car that takes some engineering skills to debug processes and fix things.
Kirat: It requires you to have a mental model of whatever you're dealing with.
Animesh: A mental model, they know how to debug things and all because they're literally diagnosing problems in vehicles and fixing them. So that part thankfully exists. The second, and again, this is where the sadness comes in, their IT systems are so bad that some of them date from the good old days of DOS. So a very common thing that I had not thought of until I went to dealerships to look at what they do, and we are a production systems shop, so there's this whole concept called Genchi Genbutsu, you have to go and see for yourself. I went to some dealerships and I realized that they are the masters of keyboards trackers. And the mouse, like an ancient mouse, thankfully now optical mice, not like the Dell ones, was sitting inside the drawer somewhere all dusty.
Kirat: I'm pretty sure everyone in the audience has that mental image of that black plastic Dell mouse, right?
Animesh: Yeah. Black plastic Dell mice is what we have, but they're in the drawer and difficult to reach and all that stuff. And I'm like, what is going on? And I realized that they have software, their primary softwares are often DOS days software. And also because the PCs run so slow, they can trust the serial port of a keyboard and therefore the flow in a keyboard is going to be in order. So these systems are designed with keyboard shortcuts in mind. That is something I had not thought of. So I'm like, oh, only advanced users use keyboard shortcuts. Yeah, they're advanced users, they use keyboard shortcuts.
However, a CSV file format and the nuance of what is the proper escape sequence for a multi-line CSV cell and things of that nature is not something that they think about. Data encoding is not what they think about, automations absolutely all day long. And because oftentimes they will allocate their time to do the repetitive motions of a task. And they're very receptive to the process of automation, not receptive, and they shouldn't be, to the task of can you write a Python program to read a CSV file and hit my APIs? For me, that's where the spectrum where their lives and multi dimensional spectrum I'd say.
A CSV file format and the nuance of what is the proper escape sequence for a multi-line CSV cell and things of that nature is not something that they think about.
Kirat: Right. No, it makes total sense. I mean, if you take the other sort of axis of this problem, so you've got people with some level of technical skills that are not necessarily in the same Venn diagram as what you need to deal with this data. But then the other side of it is it's an end to one problem. There's different people and data and systems at each of these dealerships. I'm assuming there's thousands of dealerships across the US that you have to deal with.
Animesh: 15,000 odd dealerships in the USA.
Kirat: There you go. So my mental model here is you've got 16,000 plus slightly different data formats that you're dealing with. How do you-
Animesh: Go ahead.
Kirat: At some point you must have realized that this is going to be a problem. What was that point and how did you go about looking for a solution? Or what was your thought process?
At what point did decide that enough was enough?
Animesh: For us, the data integration issue has been with us since the very early days of the system because the same DOS based system I told you about where you have to type all these things, well, they are the heart of dealership's main system. When you walk into a dealership and they give you a printout that looks like it came from a DOS matrix printer, that stuff is the old system. But those systems thankfully had APIs through which you can consume data.
Now there's only two big players, maybe four if you count the slightly smaller players in the market. So once you have built your four to five integrations with a whole bunch of very smart engineers, you are generally done. And their data structures of course do not evolve so rapidly. So that plumbing exists. But of course we were very clearly aware of the maintenance of the plumbing and how to handle that and all that and how much it takes.
But then when myKaarma built a module called the follow up module, that's when the challenge became very clear. The N to one challenge became very clear because that is when we squarely entered the space of these BDC agents saying, oh yeah, my manager sent me an email that ABC car company, our car company, has just announced recalls-
Kirat: And here's a CSV of customers or whatever, right?
Animesh: The format that we just got is from the latest version of their portal, which may have one extra column in there or something has gotten split a little. So that's one piece of the puzzle.
The second piece of this puzzle is that the data is oftentimes very dirty. So the first names and the last names and the phone numbers and the formatting is not very good. Oftentimes these sheets may have not even just been a clean download from a system, they may have actually gone through stages where somebody tried to clean the data by putting text in a number field and so on so forth. And now I'm a spreadsheet puritan, a spreadsheet should not look pretty, it should look very dense. That's how I look at spreadsheets. But there are people who have much better aesthetic senses than I do, and sometimes it doesn't quite look that way.
So when we started the product, very much core to myKaarma ethos is APIs. So we build the system API first. And then when the very first store came up, this is a store out of the east coast, and I was working with the BDC manager over there and she's like, Animesh, here's my file that I have to reach out to every month because in the east coast in Pennsylvania and stuff, they have state inspections like a smart check, but once a year you have to do it. No ifs ands or buts about it.
So the dealership has an opportunity to do a free smart check but hopefully maybe find something else wrong with the car so they can possibly upsell in the process. So she's like, I have to add them and I can use your tool to reach out very quickly and nicely to my customers, but can you please help me upload this list? And I was like, sure, let me take a look at this. And again, classic TPS fashion, there's a concept called judoka, which is human power automation. You want to start by looking at it yourself to feel for it-
Kirat: Do it three times and you try to automate it. Yep.
Animesh: So I wrote a Python script, which is available on our GitHub now and stuff. I was like, people can use it. But then I had to look at the data, I'm like, oh my god, data's wrong sometimes and have to clean it up. And we had all these validation steps before where I would upload stuff on Google Sheets and ask her to clean it up for me. And you were like, okay, this is all nice and good for one store, but there's no way the product can grow if we can't solve the upload and clean your data part of it. The good news is the ingestion is nice, we have our APIs. But the upload process is clinky. And that's when we are looking around, we absolutely toyed around with building our own.
I was like, A, it's not our core competence. Sure, we are software engineers, we can build whatever we want to build, nice. But not our core competence, somebody else should already have built this. And secondly, the problem space is going to grow. There's going to be much more of this. We are now stepping into the space where we have dealerships who have mature IT organizations who are willing to hit our APIs. And if we could again, leverage a good data pipeline where it would be easy for both parties, both developers, but still good parties to say, here's a connector, make it flow through. That would be nice.
So that's how the data problem came to us. And so far, I'm happy that we've been able to use Osmos to do some quick integrations and it has allowed us the same people to whom I would go and say, look at my Google Sheet and fix your data. I can be like, don't even call me. It's okay. Call me for the fun stuff, but for the boring stuff, upload, fix, proceed. And that's been pretty good.
Sure, we are software engineers, we can build whatever we want to build, nice. But it's not our core competence, somebody else should already have built this.
Kirat: That's amazing to hear. Your point about build versus buy, vast majority of customers who come to us are usually grappling with that. And you're absolutely right in that the problem is one of those where it's insidiously simple at the surface. Every engineer dealt with a CSV in CS 100 at some point and they're like, how hard can it be? One example I ran across was, did you know in Germany and Brazil, it is pretty common for a file to be CSV, but it'll be semicolon separated.
Animesh: In Europe as well.
Kirat: It's dot CSV. Why?
Animesh: Because you can spell semicolon with a C–
Kirat: Yeah, right. There you go. So last question Animesh before I let you go. You've been through this journey. Looking back at it, what advice would you give to someone starting out on their version of a similar journey?
What advice would you give to other engineering leaders?
Animesh: I would say for me, in my journey in the big picture part of it.
Kirat: I'll interrupt you. Sorry, one sec. It doesn't have to be, go buy Osmos, please.
Animesh: Of course. Of course go buy Osmos!
Kirat: Yeah, absolutely!
Animesh: No I'd say the bigger part of it is I'm happy to be working with very smart individuals, collaborating with smart individuals like yourselves, solving very difficult problems, these are not easy problems. Being an academic, I often tell my students and everybody basically that, hey, one of the hardest problems be complete problems and stuff takes example from the traveling salesperson problem. It's a very real sales plan traveling.
The real world has very good hard problems. But the last piece which makes me happy is to know the impact of this stuff. So this is before Osmos, but I'm happy to say that there's a dealership out of New York City who basically, I was talking to them in the middle of COVID and I was like, How are you guys doing in the call center and stuff? Have you had to lay off people?
And the manager, Joe Gallagher was like, no, we were able to use your tool. So my team was able to send out messages to my customers saying, guys, stay safe. Stay at your home, but your vehicle has a recall. We can have our guy come to your home, pick your car, bring it in at no cost to you, we'll fix a recall for you. What do you think? And because you were able to use your tool for this whole purpose, we were able to get business to the dealership at a time where nobody wanted to bring their car in for service and nobody used their car, so nobody needed service, at least normal stuff. But as a result, I was able to not lay off workers.
Because you were able to use your tool for this whole purpose, we were able to get business to the dealership. And as a result, I was able to not lay off workers.
Kirat: That's amazing.
Animesh: But I'm going with this is, as engineers I would recommend go talk to your customers, figure out whose fingers actually touch your UI. Go spend some time with them, whether they are developers who are using SDK. I was talking to an API developer today and I was happy to see how happy he was to see our API endpoints and all, or end users who have a cup of coffee and they're typing and they have the black Dell mouse and they're not even touching it. Once you feel that, A, you'll build a better product. B, I think you'll feel happier.
Kirat: For what it's worth 100% agreement there. It's nothing like seeing a user's day made with what you've built. So Animesh, thank you so much for taking the time to speak with me and our wonderful audience. And thank you everyone for tuning in. More of these coming soon. Thank you.
A big thank you to Animesh from myKaarma for speaking with us. Check out myKaarma to see how they work with franchise car dealerships to improve operations and the customer experience. MyKaarma offers POS, mobile payment systems, digital conversation tools, appointment setting, and auto-reconciliation in one app to integrate with car dealership’s Dealer Management Systems to create exceptional interactions for car owners and their dealers.
Should You Build or Buy a Data Importer?
But before you jump headfirst into building your own solution make sure you consider these eleven often overlooked and underestimated variables.view the GUIDE
Fireside Chat: Empowering Your Customers to Upload Clean Data
Customer data is needed to power your product. But ingesting that data is easier said than done. Tune in to hear how Animesh Pathak and his team at myKaarma are solving this problem and empowering their customers along the way.
Fireside Chat: Creating Impact Through Partnership
There's been a fundamental shift in the way companies ingest customer data. Which is why we're excited to talk with Kyle Rowland, CEO of TechMentor, about how companies are trying to solve the messy problem of external data ingestion.
Fireside Chat: Fixing the First Mile of Data Ingestion
Most people have never come across the kinds of data challenges that an organization like Rahi goes through to operate their business day-to-day at scale. Tune in to hear how painful the external data problem is and how they proactive approach to dealing with it.