Easy Automation Integration, Without API Changes

In this conversation, Chloë Lind interviews Jay Blinderman, VP of Partner Success at SVT Robotics. The discussion covers how to tackle complex problems in automation integration. It also dives into how varying partners including WMS/ERPs, OEMs, and system integrators play a key part.

Chloë: Hi, Jay. Thanks for joining us on the podcast today.

Jay: You’re welcome. Glad to be here.

Chloë: Awesome. So, this is Jay Blinderman. He’s the VP of Partner Success at SVT Robotics. We’re excited to have you come talk to us today and talk a little bit more about the SOFTBOT Platform. Plus, we’ll discuss how we leverage the partner network to enable end users to automate their facilities.

Chloë: So, I’d love to start out by talking a little bit about your background. I know you have quite a history within this industry in supply chain as well, and, and software in general. So, I’d love for you to give a little bit of background, um, give some color to that.

Jay: Yeah, absolutely. I’ve been in the industry for a while.

Jay: I describe myself as like the original farm to table person, because my family owned and operated supermarkets. And so, being in part of my dad’s operation, you had to learn every part of the operation from, you know, ranch hand, which is easy to do being here in Texas. I worked on a neighbor’s poultry plant and did some stuff in the crops as well.

Jay: Um, clearly, I was not good at any of those jobs because I didn’t go on to do any of them, but went on to spend probably 10 plus years in, retail grocery and then another 10 plus years in consumer package goods, uh, working with a couple of major, you know, global brands. And then somewhere along the way, I segued into technology, but it was still all Supply Chain related so early in my technology career.

Jay: I worked with handheld mobile devices and wireless WAN and wireless LAN, and then eventually got into voice systems and somewhere along the mix did enterprise software and then jumped back in with SVT and the role that I’m in today.

Chloë: Here we are. So, let’s talk a little bit about what problems customers come to SVT with. What are you hearing from partners in terms of the problems that they’re trying to solve?

Jay: Yeah. In our industry, I think customers come to SVT with a lot of challenges that they’re looking to solve. I think part of the challenge in and of itself is that they may not know where to start. So, they come to SVT utilizing our tool set to kind of understand, you know, what is available, what, what’s out there that we could deploy that would help solve our problem, whether it’s a picking technology or IOT or sensing technology, something to help solve whatever problem they’re having inside their warehouse or manufacturing facility.

Jay: So they’re just out looking for, you know, who can meet the requirements that they’re looking to fill to help solve their problem.

Chloë: And to tease that out a little bit more, what problems are folks seeing in their warehouse that leads them to say “We need to go shopping for some sort of automation solution to help rectify this.”

Jay: Yeah, in our experience picking tends to be the number one use case in order fulfillment. You know, it’s, it’s been modernized somewhat, or the problem has changed because of e-commerce, um, you know, back to my horse and carriage days, it was always brick and mortar.

Jay: But today there’s a more direct relationship with end users. And, so end users like myself, like yourself, are probably impatient. You know, I go order something now, and I want it on my doorstep tomorrow.

Jay: So, there’s pressures for people to, to do order fulfillment and picking, et cetera, faster. But there’s also an accuracy element that’s as important now as it’s ever been. Food Market Institute did a study many, many years ago on what’s the cost of an error for a grocer. So back then, even if you mis-picked a 10 case of pinto beans, it would cost you ten times that to replace. In today’s world, it isn’t 10 cases of pinto beans anymore, and items fulfilled through e-commerce are much more costly: computers, cell phones, smart watches, etc. So those errors become more and more costly. So, to tie that back to the whole picking solution, you know, people need to not only pick faster, but they need to pick more accurately than ever before.

Chloë: Absolutely. I notice that you have folks in leadership roles that sometimes get really enamored with cool technology that promises them the moon and stars above. And then you have the team that’s sort of tasked with implementing it and driving ROI. So, can you speak to what that process looks like from a buying perspective?

Jay: Yeah, it’s a great, great question. And there’s a lot of stakeholders involved in deploying automation. And to your exact point, someone may go to a trade show or an industry event, or they listen to a podcast like this, and they see some cool whiz bang technology and they have got to have it. That pushes down through the organization, and you’re going to have a set of people focused on operations, and you’re likely going to have a set of people involved in IT (information technology) in support of the organization and the operations group. The IT’s team day job isn’t deploying technology, their day job is to keep the trains running you know, efficiently and effectively, and keep bad actors out of their system. And so that’s where they focus a lot of their time.

So, deploying technology for them is probably a distraction at the least. It’s probably not something that’s welcome. So, I think a key part in getting everyone to adopt anything, this isn’t just supply chain, but it’s any new process, is getting everyone in the organization to understand what problem are we solving? What are the benefits of solving this problem? And who are the companies or what’s the company that’s best equipped to help us solve it with us taking on the least amount of risk and having the greatest opportunity for success.

Chloë: And I think sort of on the other end of that, if I’m sort of going to the extreme of someone going out and buying something and maybe not thinking about through, through the deployment integration, sort of on the other side of that, you know I think there’s all these pressures, right? To change, to innovate, et cetera. And to your point, people have a day job, right?

So, it’s very easy to kind of put that off or be in this sort of perpetual search for the perfect solution because, and feel free to jump in because I know I’m sure you have some stories around this, but a lot of these decisions are massive financial investments, not only in resources, but just in terms of dollars and can make and break careers. And so how do you shift from, you know, that search of perfection and how does that sort of play into the solution you choose, right? Because I’m assuming you’re going to want something that’s lower risk, but also adapts, right?

Jay:  Yeah. Well, for starters, I don’t think there’s ever going to be perfection.

So that’s, that’d be a nice to have, but not, not realistic. Um, I think a realistic approach is the, you know, when you think about your problem set, what impacts your cash register the most, what impacts the company’s bottom line the most.

And I, I’ll go back to what I mentioned earlier, which is order fulfillment or picking is normally the area that is going to have the greatest impact. I think the challenge has always been in the industry and will continue to be deciding what’s going to deliver a return on investment. And then what’s a reasonable ROI for you? Is that six months or 12 months or 18 months or 24, but when you approach it from that perspective, then you can set some goals for your organization to understand, you know, what targets do you want to hit and when, so that the organization gets, you know, good input and understanding around the decision they made, you can always iterate, you can always add more.

So, someone who’s doing manual processes today has a lot of challenges, speed, accuracy, the personnel to do that work. So, anyone doing any kind of manual operation, I’m sure they’re probably in their comfort zone while they’re still uncomfortable because things may not be going well. But if they start with one automation, see how it works, they can always add a second one, six months down the road, you know, a third one, six months after that, but you’ve got to find a place to start moving forward. Otherwise, you’ll, you know, you’ll never reach that goal for the organization.

Chloë: And specifically, within this industry, when you see projects deploying successfully and these automation initiatives are going pretty well, you know, all things considered. And we think about those initial stages of vetting technologies and that whole buy in process – who are the key players that need to be involved at the onset to ensure that successful sort of deployment or, you know, long term success?

Jay: Yeah. So that’s a great question. There’s a lot of stakeholders involved in these buying decisions. And I think the buildings haven’t gotten any smaller. So, my experience has been, even when you’re talking to, you know, a VP or a director or a manager of a facility.

I think it’s also key to do a walkthrough with them, along with some of the people who are actually tasked with being responsible for executing those workflows. So, a lot of people have a standard operating procedure. Uh, not all of them understand that they’re on standard or not. So, it’s great to find that out, because when you go to solve the problem and get, you know, stakeholder buy in to how you’re going to solve them, you want to know what’s working well and what’s not working well.

But I also think besides the operational side of the business, it’s super key to understand or get people involved from IT or the IT group supporting operations to help understand, you know, what are some of the requirements they have in terms of hooking up to a system, you know, what’s in the building from a communication standpoint, what are some of the power requirements for the technology you might be deploying?

There’s a lot of things that hit on the operational side. And I think it’s also key to get someone on the finance side of the business involved. So, it’s back to the ROI I spoke about earlier, you know, what’s going to be. An investment versus something that we expect to get a payback on. And when do we expect to get that? And what questions can be answered for them to get them more comfortable around that? You know, this upfront spend is going to pay dividends in the end. Great.

Chloë: Makes sense. And then, you know, we’re talking, I think a little bit vaguely, but just to anchor this for anybody that’s not familiar already, when we talk about, okay, you’re going out, you’re buying an automation solution, traditionally speaking, what does that integration process look like? What’s sort of the standard, the standard in the industry today?

Jay: Yeah. So back to your buying cycle question. I think that’s the other thing that I probably left out was, uh. There’s a lot of great automation companies out there. They’re going to help people understand what problem they need to solve. It’s probably not common in their buying cycle process to fully go through all the steps for a customer on how you integrate that technology, because you want to get your deal across the line and get that moving forward.

And that’s something I think everybody needs to consider. And so that’s another set of stakeholders that probably need to be brought in early to the process is to understand. You know, what effort’s going to be involved to deploy the automations you’re looking for so that that doesn’t stop you on the backend.

Because the worst thing that can happen is you can go through all the T’s and C’s of a contract and even have robots on the ground only to find out that, yeah, now we can’t utilize them because everyone wasn’t bought in or there’s a piece of software we can’t integrate to. So, it’s better off to have those discussions, you know, as early as possible and once you’ve narrowed down the scope of the technologies you intend to deploy.

Chloë: And then what are those options in terms of how to actually integrate?

Jay: Yeah, I think there’s a few options. So I like to look at in a couple of buckets, the, the, the builders and the buyers, so there’s companies that like to build or do it themselves, and that’s clearly where you need to get the it people involved and others in the organization to understand that the effort involved, and then you’ve got another group of customers that tend to be buyers.

They don’t have any challenges whatsoever going to a third party outside of the organization to help them with what in this case would be integrating technology. And so, in both of those cases, oftentimes writing custom code is how those integrations occur, and that’s actually one of the key problems that SVT Robotics helps solve is the elimination of the need for custom code.

Custom code is great in a lot of cases, but it has some challenges, it tends to take quite a bit of time, can be very costly, often times not well documented, and then it’s inevitable that someone’s business is going to change. They’re going to have growth or they, there’s business may scale up and down because it’s a, a very seasonal business and so if something was done purely using custom code, then more custom codes must be written. More delays, more time, more cost, and that’s the benefit of a system like ours, which is a truly agnostic system that scales up and down basically as the business requires changes to be made.

Chloë: And just to clarify, how are we fundamentally different from a systems integrator? Can you walk me through what that looks like or what, what the true different differentiators are, and do we work with them (system integrators) as well?

Jay: Yeah. So, SVT is not a systems integrator. You know, probably early days we kind of filled that gap because we were proving out that there was a need for what we do in the market, but, systems integrators today are, you know, users of our tool set.

And so, when I say we’re not a systems integrator, let me go a little into detail, we’re not interested in sizing and scoping someone’s full problem set, you know, we’re not going to tell you how many robots you need. We’re not going to tell you what the workflows are. We’re not going to tell you, you know, what ROI’s look like. And that’s where systems integrators as well as some of the other just pure play robotic partners we have do a phenomenal job of that. But then they use our tool set to get those things implemented faster. With less burden on the customer’s IT department as well, so that people can get value out of the decisions that are making a lot faster.

Chloë: Helpful. Thank you. Can you talk about why partners are key in our business and in what ways that we engage with different OEMs?

Jay: Yeah, partners are key for a lot of reasons. Um, selfishly from a pure business perspective, partners are what enable companies like us to, to scale.

Because each partner has a set of people on their team. Salespeople, pre-sales people, engineers, technology specialists. And they are focused on different aspects of the market. So once again, we’re not a systems integrator. We could never understand the full market or meet all those requirements. And that’s where partners come in.

But partners that are there to help solve end user customer problems. And we fully recognize that and then we’re there to help them get those technologies deployed faster so that people can get value out of it faster. And our belief is that by working through partners, we’re going to get our fair share of opportunities to help them solve those problems to you know, lead the outcomes.

Chloë: And then for people that might not be familiar with the SOFTBOT Platform, can you speak to, there’s like high level, how it works and how we connect to different partners?

Jay: Yeah. High level, how it works. We have a cloud-based environment and we provide a platform and build these things that we call SOFTBOTS, which is an OEMs API converted into this thing we call a SOFTBOT that enables it to reside on our platform. And then anything else on the SVT platform can push data or receive data to formulate what would be a workflow.

So quick example, host system, a WMS or an ERP has a SOFTBOT and it pushes out order information or picking information, if you will. And then there might be a picking robot on the other end of that equation or picking robots what’s needed, whether it’s a, you know, pure play robot or an AS/RS system, and it’s listening for the information that needs, which might be location quantity to fulfill the task at hand, which might be order fulfillment and those two technologies reside on our platform without either one of them knowing the other one is there, nor do they care.

Chloë: And so, there’s no changes needed to each respective OEMs API or tech or anything.

Jay: That’s exactly right, Chloe. So, I guess that’s the other unique, one of the other unique parts about SVT is that our approach to the market is that. Not only are we an agnostic provider, the other thing that makes us unique is we don’t ask anybody to change what they’re doing today from a technology perspective.

So, a WMS or a host system doesn’t have to change its code for us to build a SOFTBOT and the same is true on the other side, the robotic company, the IOT sensor company, the conveyance company, the AS/RS company, etc. They provide us their API and we ingest it the way it is today.

Chloë: Yeah. That seems like a benefit because then they’re able to connect to us, like they extend their partner network by default, right? If they’re connected to the SOFTBOT platform and we’re connected to a bunch of partners…

Jay: Yeah, no, that’s exactly right. And so going back to the question you asked me earlier about, you know, we’re not a systems integrator, but we work with them.

We absolutely do. What you just brought up is a great example of why some SIs have chosen to work with us is that we’re an extension of what they’ve already done. So, they may already have built some custom integrations that they’re super happy with and confident about. But there are thousands of technologies in the market today.

I probably average three calls a week from net new technologies from all over the world that I had never heard of before. So, if I were an SI, I don’t know how I would ever keep up. So that’s kind of where we come in is that we can build those integrations based on these new technologies and their APIs that allow an SI or an end user customer take advantage of these new techs that are coming on the market very rapidly. And, it doesn’t require them to have to write a whole bunch of new custom code. It doesn’t require an effort on their part whatsoever. And it may turn out to be complementary to other things they’ve already built.

Chloë: Great. And you touched on this a little bit earlier, but I’d love to break it down. When you hear the word tech agnostic, what does that really mean in this context?

Jay: So, tech agnostic comes in a couple of forms, at least from the chair that I sit in. One is we’ll take anybody’s API on. There are, you know, there’s no favorites, it doesn’t matter. If you have an API, we’re happy to build a SOFTBOT so that you can deploy your technology more often.

Also, we’re agnostic from the perspective that we don’t resell anybody’s technology. So, we’re a pure play provider at this point of integrations. So, we’re not taking on the robotic sale. We’re not pitting robot company “A” against robot company “B”. Competition is a great thing. But we’re going to leave that to the OEMs and the providers. We have full faith that they’re going to show the customer what the value propositions are for their tech. And the customer is going to make the decision on what works best for them. But the other part about being tech agnostic is back to the question you asked earlier about making changes. We don’t require someone to make changes to their API. So whatever communication method they’ve selected, we will absorb that and build the SOFTBOT from it.

So, it doesn’t matter to us if they’re using, you know, FTP, TCP/IP, RabbitMQ. Their communication methodology doesn’t matter. We will take all of them on.

Chloë: And how does that work as their technology evolves and their API, you know, inevitably changes in some way?

Jay: Yep. So those APIs are going to change to meet customer needs, which is a good thing. That’s speaks to the benefit the platform that SVT provides. For the companies that truly are partnering with us, we offer something called a Certified SOFTBOT.

So, a Certified SOFTBOT enables them to fully collaborate with SVT, share mutual roadmaps, etc. Which means that we can keep their API up to date. And so customers that are on our platform benefit from new functionality offered to them.

Chloë: Could you speak to how that differs from the traditional approach to integrating automation solutions? Because traditionally, if you have a change, you must manage it, you have to maintain your integration, right? But then if something changes, that’s a whole potentially new set of work.

Jay: Right. Yeah, that’s exactly right. So, if someone puts in a system, all that effectively gets hard coded for that specific system. So, if there’s three or four technologies involved in the delivery, that can be come highly problematic.

If any element changes for any reason, a lot of additional code must be written to account for it. And that could be adding something. It could be taking something away. Or, it could be one of those four pieces of technology had a change in functionality. Either way, that requires more code to be written.

I think the other challenge is that. Whether, whoever writes the custom code, change is inevitable and it’s not just technology change or business change. It’s personnel change. You know, someone on your team gets promoted, which is a great thing. And they go on to a new role. Well, maybe the code they wrote wasn’t fully documented. It’s not always a great situation when people leave either.

And so, then the problem becomes they’ve left. And once again, still don’t have things well documented. So, now we have a full-blown custom integration reliant on someone who’s no longer here. No one understands you know, how to tweak that code. So SVT helps solve some of those issues just based on the platform that we’ve built. Our system is self-documenting. So, when that person does get promoted, the organization can have full faith and confidence in the automations. It removes the risk of any slowdown or worst case scenario, any stoppage to what they were doing.

Chloë: Could you give me some examples of when SVT has come in maybe after a tech has been selected? And maybe they’re even in like mid-integration process trying to deploy?

Jay: Yeah. So, SVT is happy to come in and help people solve problems at any point in their journey. But I think what you’re what you’re really getting out there is, um, a few things occur.

So earlier we talked about someone goes to a trade show. They get enamored with the technology. Inevitably, they push that through the organization. Maybe the organization wasn’t ready to integrate it. Another time where we get brought in is maybe everyone did take into consideration what needed to happen. It was an organization that really was focused on doing it themselves. But this is the first time they’ve had to integrate an OEMs API into their stack. Maybe no one told them that was a 1200 page API document. Maybe no one pointed them to what the most critical parts of that API document were.

As I mentioned, I think earlier on in the podcast, people have day jobs keeping the current operation running. And so maybe they didn’t fully, you know, figure out the time necessary to go build this integration. We get called when a customer tried to build it themselves but realized there was just way too much effort.

And then we’ve had some cases too, where a company may have been selected to help build the integration. But it’s very possible that one of the things they were building to was new to them. Could have been a custom host system or it could have been a robotic technology that they weren’t familiar with.

So, perhaps they had done similar things. Maybe presumed this one was going to be like the ones they had done in their past. And turned out to not be the case. It seems like all of those things pile on top of each other. In the end, we end up getting a phone call nine to 12 weeks before peak. Someone already has robots on the ground. They’ve made any number of efforts to get them up and running to no avail. Then we get called in and we’ve actually had success in that exact scenario a couple of different times.

Chloë: So, I know final question. I know you are in a lot of conversations with, you know, large retailers, 3PL’s (third party logistics) partners, right? Other OEMs, etc. What surprises people the most in those conversations?

Jay: Well, there’s a lot of elements that surprise people, I think.

So, I think time surprises people. Um, I think cost surprises people. And then I’ll also say that the thing that I think surprises people about SVT. It doesn’t seem believable that we build a repeatable process that takes 12 weeks or less. That’s the thing that often surprises people.

You know, how is that possible? And, I had the opportunity to work on a technology for about eight years of my career. I weigh it up against your question about what surprises people to help address it. So, we told the public that it always had an ROI payback of six months or less. The reality is the ROI payback was typically significantly better than six months. The reason we use the six-month number was that was the believable number. Anything less than six months wasn’t believable, even though that was almost always the case. And I find that to be the case with SVT as well.

We tell people that we can do typical integrations in 12 weeks or less, which is absolutely the case. But if it’s technology that we’ve deployed before, typically it’s significantly less. We try to stick with the 12 week number because that’s the believable number. But  aI think even, even that’s, you know, the surprise to people.

Chloë: All right. Well, thank you so much, Jay. It’s been a pleasure.

Jay: Thanks for having me on today.

This interview has been edited for length and clarity. Please listen or watch the episode to catch the entire conversation.