Transcript for "[Tech Panel] API/Platform/Hybrid? The Carrier Tech Decision That Determines Whether Your $1M Automation Pays Off": Alright. I believe we are live for this pros who know 2026 session, and I'd. like to welcome everybody to today's webinar, API platform or hybrid, the carrier tech decision that determines whether your $1,000,000 automation pays off. I am Clint Boas. I'm the senior sales engineer here at ProShip, and I will be moderating this discussion. And the idea behind this session is that when companies invest in automation, they often focus everything and all their attention on the four walls inside the warehouse, but often overlook a critical dependency, which is shipping technology. And we're gonna explore what happens when shipping becomes a single point of failure in a highly automated operation. We're gonna talk about that question nobody wants to think about is when shipping goes down, what happens? Labels stop printing, conveyors stop moving, and all that automation that's been set up stops delivering the value that it was originally built for. Before we get started, we'll go over some housekeeping items here for the webinar. Feel free to submit questions using the q and a function in the webinar. We're gonna address those at the end of the session. This webinar is being recorded, so you're gonna receive an on demand recording, within the next week. And you can also download any resources from the related content section, and you're also gonna find a link there to a survey. They'll help us build our annual ProShip report on the future of parcel shipping. We would encourage you, to fill that out. Eligible responses will receive an Amazon gift card. And, last of all, at the end of this, please submit the survey and, let us know how we did on this webinar. Well, let's introduce the panel. Like I said, I'm the moderator for this session. And, twenty four years in multi carrier shipping technology, I've seen the good, the bad, the ugly thereof, and had the opportunity to get a lot of exposure to different types of warehouse operations and automation equipment. But I'm joined here today by a panel of experts in the shipping technology space, and we're gonna let them introduce themselves, tell us a little bit about what they do and what their company does. And we'll start with Alex. Alex, please introduce yourself. Sure. Sure. Thanks a lot. a lot. Alex Kinkade, director of sales and marketing for StreamTech. And StreamTech is a material handling systems integrator. So we offer, you know, pick, pack, and ship automation systems, for, you know, ecommerce companies and, we have our own warehouse control software that ties really nicely, to tie the equipment with, your multi carrier software platform such as ProShip. So that's what we. do. Welcome, Alex. Cameron, please. introduce name's. my name's Cameron Stout. I'm the vice president of partnership development at a company called Packsize. Packsize is the global leader in right size on demand packaging. So we make, you know, a box that perfectly fits whatever you are shipping. So I've been at Packsize roughly nine years. Hail out of Salt Lake City, and thanks for the opportunity to be here today. And then Julian. Hey. I'm Julian Cavaloto, director of transportation for Backcountry and CSC brands. I'm a shipper. I do I've been in ecom, shipping for the last ten years at through various roles. I've been with Backcountry for going on six years now, managing anything and everything that has to do with our transportation, including systems, and getting packages out of our fulfillment centers. Alright. Well, thank you to our panelists for being here today. And as you can see, we got software, we got automation equipment, we've got experienced consumer of those things. We can answer anything today about this topic. But as we get into this conversation, I do want to provide a little bit of, background just in terms of what we mean by a shipping architecture decisions and what we mean by API or premise or hybrid. And that's really that when you're deploying carrier compliance, multi carrier technologies, there are a couple of options that you have for processing shipments, you know, doing rate quotes, doing rate comparisons, getting shipping labels, manifesting your shipments with the carriers. You can either use the carrier's free public online APIs, where every time you wanna get a rate, every time you wanna get a shipping label, you have to make a call out over the Internet to that carrier's web API. That is one option. The other option is that you can deploy everything on your shipping system platform, meaning that your shipping labels, your rates, and all that is self contained on the shipping system without reliance on calling out over the Internet to the carrier's external API. At ProShip, we often call that a platform engine or sometimes a premise engine, though the operation of that could technically be in a cloud infrastructure. Still, all the processing happens locally there on the system, or it could be a combination, a hybrid of one of these approaches. And it's a critical decision to make, when considering some of the questions we're gonna talk about today in which technology is most reliable for your automation environment. And we'll get into some of the advantages and disadvantages here. But let's let's start off by just talking about, really this hidden dependency in warehouse automation because most automation projects focus on what happens in the warehouse. Everybody's looking at schematics. Everybody's looking at equipment. They're looking at process flow. But as I've just highlighted, there is a critical dependency that might exist outside the four walls. And it's really more than just what happens in the automation equipment. And I wanna talk with our panelists here and let them provide some of their insights. And, Cameron, let's start with you. From your perspective, how has the automation discussion expanded beyond the traditional four walls of the warehouse? Yeah. I think this is something that that I certainly talk about quite a bit. So shipping, you know, has really become the you know, it's a it's a final stage of fulfillment. Right? So it's it's your last promise to the customer. And, really, with, the way that, buying patterns have shifted with, you know, the increase in ecommerce, now the new storefront or the new retail storefront is your customer store step. So those decisions that are being made about, you know, how things are you know, what mode of transportation it's, It's taking how, I guess, is does it come in a carton? Does it come in a bag? You know, how are you shipping it? Who's your shipping carrier? Are they, you know, fulfilling the needs that that you have? All those are very important, to be thinking about. And then in multi carrier environments, it's not only you know, it's it's how is it going to get there? Is it going to get there when I promise my customer that it will get there, but how much is it going to cost me? And so some of those decisions that are being made are extremely important because FedEx and UPS continue to kinda change the rules. You know, they will they will move the goalposts on customers. It used to be kind of an annual thing where you had an annual base surcharge increase. But as as the environment has changed, as the world has become a little bit more dynamic, a lot of times we're seeing those changes happen within any given year. So if you're not considering it, then your cost of partial shipping, is really getting out of control. Yeah. Great points. Alex, your thoughts on that question? Yeah. I mean, you know, as as Cameron mentioned, we one of the things the automation can do is really personalize that order. So in addition to making sure that the package arrives when we promised that it was gonna arrive, we can add we can label with their, their personalized information. We can put something in the package, cross sell, we can, you know, give them some sort of a loyalty, aspect to it and really make sure that the opening the package opening and receiving experiences is what, drives them to, you know, order and shop from you again. So, the automation really powers that and some of the information that you might get from your multi carrier or, software platform can facilitate that. So Yeah. The the shipping software is is a bridge between the different fulfillment systems, the the automation equipment, the carrier networks. And if that connection is not working properly, then all those automated processes, start to break down. Cameron, let's let's talk about something we see all the time. Why why do you think shipping technology decisions often receive less attention than automation investments. Yeah. There's a couple different reasons, but I think the general assumption that a lot of, customers have is that if you have if you condense all your volume into one shipper, that you're going to get a better price or that your overall cost will will go down. Right? And that's certainly, you know, what, you know, what the FedEx and UPSes of the world would would want you to believe. Right? Because they want as much volume as they possibly can get. Yeah. Yeah. It's it's it's about making, you know, better decisions with the with the data, you know, executed through the technology. I think that oftentimes, warehouse operations, they're viewed as just kind of a staff function. Right? Only gets attention when something's broken. Otherwise, just kind of put on the back burner, which we think is a mistake, because shipping directly impacts, you know, customer satisfaction, as you've mentioned, revenue, operational operational performance. It's really easy to see just to add to that, Clint. You know, it's really easy to see when, something with physical is breaking down in the in the warehouse, but it's very difficult to see something that's not physical like software when, you know, a customer experience might not be optimal. But you you may not know that, just from looking at the the shop, the warehouse itself. So. And and I would say that, you know, a lot of times, like, the decision makers for what's going to happen within the four walls of the warehouse are not necessarily managing the p and l for outbound logistics, right, or for parcel spend. So, you know, while it may matter to the company, you know, it doesn't necessarily matter to the KPIs that, you know, that they're trying to improve upon or it doesn't matter to their project or may, you know, they may not just get credit for, you know, the, I guess, within the business case for the project justification. So, you know, it is you know, they're laser focused. If you got a, you know, vice president of supply chain, vice president of operations, it's Like, they're laser focused on optimizing what's within the four walls of the warehouse. And so sometimes that gets lost, and and it's a little bit hard to pivot, you know, out of, you know, out of that talk track or or to get someone to think a little bit bigger or maybe pull in another decision maker into, you know, into a project's, I guess, decision making unit. Yeah. Well, at some point, those, intangibles, like, transportation spend become very tangible, when you actually have to pay your carrier invoice. But those are those are costs large costs and costs that are controllable. Now from, like, a customer focused perspective, Julian, I'd like to hear your perspective, on, on your approach to thinking about this at Backcountry. Yeah. I think, you know, it ties in very closely with Cameron and Alex have been saying. Right? You, at the end of the day, like, our first thought is how does shipping and automation, how do all of our systems impact our customer experience, right, when that package gets to the door? How are we getting it there? When we told them we were gonna get it there? Is there clear visibility on package tracking and things like that? You know? And on the back end, it's did we do it in a cost effective manner that, you know, enables our business to be profitable and continue growing and being successful? Right? So that's kind of, at the highest level, everything I work on on a daily basis. Right? And it's I would say my big point on this would be if you're a shipper looking at automation or systems, you wanna maintain as much flexibility within those as possible. Don't don't limit yourself to a very rigid system that works today because what works today may not work next year or the year after that. And, typically, these are very long term investments, and you wanna make sure that as FedEx, UPS, and other carriers change the rules, you can be very agile in moving with those rules to keep your costs in check. Yeah. Great points. The differences in in architecture and deployment can have significant operational consequences, especially when something goes wrong. So let's talk about that next. What happens when it goes wrong, other than maybe a few choice words being, Okay. being said. But when that that kill switch flips, when that critical fuse blows, I wanna talk about what happens when that dependency that we just talked about fails and and it breaks down. If you think about your typical warehouse process, the happy path, right, is we get orders. They come in through an order management system. They flow down to a warehouse management system. They go out to the warehouse floor. The automation equipment, helps with, you know, conveying, moving, packing, hits shipping software where, we have carrier connectivity, possibly choose our carrier there, get a shipping label, labels applied to the box, goes through sortation, and then eventually out to cater to the carrier. But at any point, that process can break down. So I'd like to hear from the panelists as you know, what does a failure look like, from each of your areas of expertise? Again, Cameron, we'll start with you from a pack size perspective. What does a failure look like, at a at a boxing solution? Yeah. Certainly depends on the solution. So we we've kind of have two, you know, major process flows that that we will sell to our customers, and one is BoxFirst. So with BoxFirst, you know, maybe you can keep packing. It depends on, you know, when the shipping label is actually being created. We do have some customers where a shipping label is is being created. It's a very first step of our process. So if you don't have any labels and you can't route anything throughout the facility, and, really, you're just down. You know? The only thing that you could do is just manually label, you know, or possibly work offline. But either way, it's really diminishing the value of your automation solution. And then if you function in a box last, you're actually doing manifesting and packaging at the same time. So, you know, a product will go and flow through a dimensioning gate that will tell it, tell our machine what size of box it needs to actually create. And the very last step of that is going to be to put a shipping label on the on the end. Or maybe you could do an LPN, and then it goes to a slam line. But either way, you're really stopping, you know, the the entire show. You have to move to and cut over to full manual processes, which, you know, a lot of customers are just not prepared to do. So, you know, couldn't couldn't be a a bigger deal. And then, really, it's going to cost, you know, thousands upon thousands of dollars to, you know, to the person that's trying to run that warehouse and trying to get, you know, trying to get packages out the door. Yeah. So there, the impact is immediate, and and nothing's moving, because you can't get that final shipping transaction to occur. Alex, I'm sure with automation equipment, like at StreamTech, you see the same thing. Yeah. Yeah. Yeah. It's a very similar story. I mean, we can pick and pack orders, but when it comes to manifesting, you know, we we typically will scan way and dimension, orders in real time, you know, either in real time or in waves. And unless the wave was sent, you know, in packages of of a large subset, and we can continue to to consume that wave. If something goes down, it's Hello? on the software side, we're we're dead in the water. You know, we'll put a an error label on the package, if there's a server timeout response, error, we'll do that maybe two or three times and then we'll stop the line and and you'll have to we'll have we'll be someone will be calling IT. So And then, Julian, at, Backcountry from the operator side, what happens in your environments when that whole process breaks? Yeah. It's usually a fun, mad scramble of problem solving. Right? Typically, it's the first step is what's going on. You kind of get an estimate from our tech folks of, like, hey. This is gonna take an hour. This is gonna take six hours, or we don't know when this is gonna be fixed, right, which is always the worst. Then you quickly do an analysis of, like, how will this impact our customers? What you know, are we gonna be able to get packages out today? Is there a manual workaround around we can do? If we're down, a warehouse being down for us costs about $10,000 an hour, right, that we're not shipping, which is probably much less than some folks and maybe more than some folks, but it's not no money. Right? So you're trying to limit that as much as possible. If you lose the ability to rate shop in automation, right, then you could be shipping, suboptimally, maybe only with FedEx and not able to ship packages with some alternate carriers. That could cost upwards of hundreds of thousands of dollars if you have to do that for a substantial amount of time. So it's just a big problem solving exercise and trying to figure out, should we do a manual workaround? Is it better to sit and wait if it's only gonna be a couple hours and we pay some overtime? It's just a cost exercise. Yeah. It's, all those ripple ripple effects of, what happens related to labor and customer service, revenue recognition, commitments that you've made to the carriers even, according to your operation schedule. So let's let's drill down a bit more into that because, there are real there are real costs. There are costs associated with downtime, and, Julie, and I appreciate you sharing, some of the the cost that you anticipate happening in the event of an outage. But, Alex, let's let's talk a little bit further about not just resolving the technical issue itself, which takes time and takes effort. But what do you see as the real cost of downtime? Yeah. I mean, one of the things that we struggle with and and we can't on our side as the equipment provider, you know, we can't address them, but it it's definitely a concern when we get a call from one of our customers. If there's something outside of our control that went down, you know, we start thinking the customer may call us and say, I've got, you know, x number of people over x number of hours that are sitting here can't process orders. I've got x number of orders that are not getting processed and they start to they start to sort of spin up these sort of, conversations and and we, you know, we cannot that's not something that we can address on our side. But you start thinking about the type of liquidated damages that occur when something goes down. You know, and and, you know, luckily for for Julian, he's got options because he's directly fulfilling to his own generated e com customers. And so he maybe he can maybe a customer might get something late tomorrow that may not be a huge I mean, it's not ideal. You don't want that. But when you think about our 3PL customers who if orders don't go out the door, they're gonna be hit with an SLA, finding of some kind and, that's a huge they're under a much tighter margin on things like that. So Yeah. Yeah. And it's cert certainly can, you know, kinda put their put their contracts at risk, you know, and they are one of the more sensitive, you know, customer types, as a result of that because it's it's really they're being paid to fulfill orders. You know, and if they are not doing that, they're, you know, failing at their core purpose and what's driving the most amount of value. So if you lose that trust and you lose the trust from the person that is, you know, that you're responsible for getting their packages out the door, then you may lose a contract. You, you know, you may lose market share, you know, and then everyone talks to each other. So, you know, it might have an impact that just goes further than just that one customer that was impacted. Mhmm. Yeah. Definitely lanes differently depending on the industry. Three p l versus retail versus health care. Right, different implications there. Julian, as as a retailer, you know, as a as a shipper, when there is an outage, like we've been talking about, where do your priorities go first? I'm gonna I'm gonna I'm gonna beat the dead horse, but, like, you know, question number one is how does this impact our customers? Right? Like, at the. end of the day, the people that are relying on us to get their gear are, you know, we want them to come back to us time and time again. And if we're not reliable in our operational execution of getting the package out the door and then our carriers aren't reliable in getting it to the customer, then they're gonna find somewhere else to go buy that gear. Right? I think, you know, Wook, there's a lot of things depending on the area that we can do that we can work around. I mentioned some of it, you know, previously, but a lot of the times it's can we do a manual workaround? Is it short downtime? Is it long downtime? You know, we have a couple buildings. Can we swap orders from one building to the other? There's, you know, there's no end to the problem solution the the problem solution that can go in place. It's, you know, what do we have to do to get boxes out the door, and how do we mitigate the additional cost as much as possible while doing the right thing for the customer. 100%. You know, I, you know, I was thinking about as you're mentioning that, Julian, we have one customer who's, who does surgical instrumentation. And everything they ship is overnight. Like, everything goes on a plane because it's going to surgery tomorrow or the next day. And, however, the supply chain is set up, for that type of, product, you know, they, if it's it's just on demand, there's not a lot of storage and health health facilities and so it goes straight to the the site and if we're late, someone's surgery is getting canceled and that's bad. So we, you know, we have like you said, every customer is a little different, different pressure. Luckily, we're only canceling ski trips, not surgeries. Hey. That you don't want that. not can't. good. that might be. not good. as important. Nobody wants that. Yeah. So it's it's all about running that, business continuity plan and making those assessments and, you know, determining if it's if it's necessary to even inform customers, you know, if, if there's gonna be a a delay, in processing and, and such. Cameron, let me ask you this. How quickly do you believe the value of the automation disappears, when you've got either upstream or downstream systems that aren't available? Yeah. I mean, short answer, very fast. You know, and the reason is is that all automation equipment, for the most part, relies on information from another system. Right? Whether that's customer information, whether that's, you know, where the the shipping label request, whether, you know, whether or not you've got, like, you know, an upstream, conveyance system that needs to bring, you know, the products to the mouth of a machine, whatever it might be. It's like you're you're relying on other pieces of of data in order to make this thing be able to do its job. You know? It's it's it's the instructions. Right? It's kind of the work manual for for this automation equipment. So, you know, the if it is not being fed correctly or if something is down, then, really, usually, you're kinda back to where you started, right, which is taking away, you know, the entire reason why you invested the money in this equipment in the first place. But, usually, it's even worse because, you know, you don't have that same process. Right? You're not functioning in, like, an SOP in a standard, you know, standard way at that. So you're not going to be nearly as efficient as what you were doing before because you've got no practice in doing it, not to mention that you've built everything that you're that you're doing usually around, you know, this this piece of equipment. And for ours, you know, a lot of times, we are feeding we are feeding other things. You know? So we are feeding into, you know, whether it's carts or whether it's into, you know, conveyor fed pick module, whatever it might be. We're feeding another system. You know? So not only is it going to impact what we're doing with ours and the investment that, you know, yeah, that someone would put in the Packsize, but then it's going to hurt every other investment that's been made along the way because it's just an interconnected world, and everything is just in time. Alex, I'll ask that same question to you, about, the value of the automation equipment. You know, what happens to that when, Oh, yeah. you you're missing dependencies? I mean, you've built the ROI. We typically, when we put in automation, like, for example, an end of line shipping system, you know, you've built the ROI around, let's say, a labor savings, a, too many touches, you know, if we can cut out this many touches, it's gonna speed up the process. We'll get more orders out the door in the day. They'll be more accurate because we're going to only ship them when they're scanned and weighed in dimension and verified yet again. So that we're always gonna know that they're over 99 something accurate. All that goes out the window when the key piece in this the chain breaks. It's actually it's similar to a supply chain a supply chain issues when something goes wrong, you're you're gonna need to have, some other way of, you know, processing those orders and, you know, that's where when you have a system like an an offline pro ship on premise type of solution that you can you can turn to, and say, look, we're gonna still process orders. They might be at a slightly different rate, but we're going to, we have some sort of a backup, plan, so you can recover that, that ROI. So And then, Julian, I'll give you another shot at, at this topic before we move on. In terms of automation equipment, you know, missing out on on on the advantage of having it, And then maybe also just some what are some of those contingencies, that you need to plan for in the event that you you you don't have the advantage of the automation? Yeah. I mean, you know, Cameron and Alex, framed up as perfect. Right? Like, everything in our warehouse is optimized around our automation equipment. Right? We don't think about I mean, we do think about what happens when it goes down, but, like, the majority of our time is how do we maximize this equipment? How do we save the most money on labor and shipping by utilizing this equipment? How are we getting, you know, our ROI back on our, you know, automated picker or automated, you know, box making machine in a pack size? Like, you know, all those things, that's what you're working on constantly. So when that goes down, it again, depending on what happens, it's problem solving, but a lot of the time it boils down to throw labor at it, get it solved, right, the best you can. Like, it's it's not a sexy solution, but that's typically because you don't have you know, we have some SOPs for, like, hey. If this goes down, here's what we do. Right? But at the end of the day, it just requires more labor and more hours, more processing time to get the same boxes out the door at a a much higher cost. And then when they go to judge that ROI on that, automation project later, it doesn't quite look so good as good as it did before when. it was all just theoretical. Yeah. Yeah. Yep. Depending exactly. Depending on, you know, the length of the outage and how big of a a problem, it can it can definitely dig into the ROI, pretty quickly. Alright. So we've talked about all the bad things, that can happen and and the negative impact. So I wanna go back to really, you know, from a perspective. Everybody's got a great perspective here. But for a perspective, you know, being focused on the shipping software aspect of this, I talked about, you know, different deployment models, and their trade offs. And, really, there are two primary ways to deploy carrier compliance technology. Again, you could just sign up for the carrier APIs. All the carriers or most of the the large carriers offer a public online web API that you can use to get a rate quote, print a shipping label, ship according to those carriers' rules, get your transit time commitments and all of that, or you could use a solution that's completely on the platform of the shipping shipping software. And there are advantages and disadvantages to either. The advantage of the of the APIs is that they're easy to sign up for. You go on to the carrier's website, get some credentials, plug them into your shipping software, and then boom, all of a sudden, you've got access to your negotiated rate, carrier compliance rules, and labels. The disadvantages, though, have to do a lot with the performance and reliability of those APIs. They tend to be slow, so sometimes take seconds to return a shipping label, which a second or two seconds is is critical, when you're dealing with automation equipment and print and apply, and you've only got a certain window to get a response back from your shipping software. They tend to be less reliable, and, really, this is the, you know, the crux of, the decision in which of these technologies to deploy. Because if you're planning for high availability, you're planning for disaster recovery, You know, what happens if your connection to that external API no longer exists because that carrier's technology has gone down? Some other disadvantages of the carrier APIs, they may not have all the carrier services available. Certain contractual services may not be present, and they behave differently doing things like a ship to hold or an automated consolidation. Some of those things just aren't possible with carrier APIs. Now with the platform engine, you've got, you know, proprietary carrier compliance that lives self contained in the shipping software and doesn't rely on those carrier APIs. And the advantage there is that it's fast. We're typically talking about labels per second rather than seconds per label. It's more reliable, gives you more control over the architecture. So a better general deployment model for high availability disaster recovery considerations. If your objective is to minimize the chance of one of these disruptions, you've got more control over the system. Now the disadvantages is it may take more configuration. There may be, rate files you need to load so you can get local rates, get your negotiated rate. There may be other configuration parameter. That there's not always a single universal deployment model. You may have a hybrid solution. So for example, by location, it may make sense for ship to store to use the carrier API because you may have dozens or hundreds of store need to register for a carrier API and get quick. You you wanna use the the platform engine or maybe by function. Accessing your rates for rate shopping through the carrier API to get easy access to those negotiated rates, but then maybe downstream at that critical label printing function, use the platform engine. So there's some options there, and all these things we've been talking about in terms of, using the, making decisions on carrier deployment technologies to minimize disruption, this is a critical a critical, decision to make. And I know, Julian, you've looked at both of these technologies. You've got experience with them. You've used different deployment architectures as a consumer. How has your thinking evolved around this discussion? Yeah. That's a great question. You know, in we implemented ProShip in 2022. Prior to that, we were using UPS Connexhip to generate labels. Our biggest concern when we first implemented ProShip was to get fully baked accurate costs for every package. Right? Connect Ship was notoriously using base rates and fuel and had no accessorials factored in for UPS, which have had have obviously become more of a factor in your costs, right, if you know anything about it. So in in that time frame, I wanted to use APIs as much as possible for across all my carriers because my number one priority was to have fully baked cost within my rate shop to make sure we understood what we were gonna pay for that label. Right? Now we're working on a project right now to kind of update that methodology. One of the reasons being our automation requiring a sub three second response time and things like the UPS or the FedEx API don't work for an hour or two hours and then you're kinda waiting on it to come back, and so you're kinda stuck not processing for that amount of time. There are API outages that that happen at the carrier level, and as you introduce more carriers, you're gonna introduce more room for error. So, You know, how do you in my mind, it's more of a hybrid using the APIs to bring in rates your contractual rates to a local server and then using that local server to actually rate shop and print labels. And it's all about configuration and making sure that, you know, the rates you're bringing in are accurate, you're correctly calculating fuel and some of those fluctuating accessorials. So it, you know, I would say that, you know, everyone has every shipper is gonna have different needs, under you know, understanding your needs and what your costs are and what's what's important to you is is super important when you're looking at a configuration. And just, again, going back to my earlier point, make sure you maintain some flexibility with whatever setup you go with to be able to, you know, to have some agility in changing rules as carriers move the goalpost. Excellent points. So I have cut my video as I, have been told that my audio was was chopping up a bit. But, let me point to Alex. And, Alex, what are your thoughts, as well on, you know, the different shipping Sure. technology options for deployment in an automation environment? Sure. Yeah. When when we're, as you mentioned before, one of the things that our automation depends on and, you know, Julian touched on this a little bit is as most of our customers, tend to operate in real time. So we design the automation with within a set, amount of of, runway between the time that we induct, scan, weigh and dimension, send the request for a label, and expect the label to be ready. So if that's, you know, Julian, you said three seconds, we we we typically for for something like ProShip, we typically see one to three seconds, by the time that label is ready. And if someone wants to operate in a, you know, a high speed environment, we typically request that they they they verify what that response time is before we ever get to the point that we're gonna implement something. There's only so much we can do, if the response time isn't isn't gonna be within the the spec. So we we typically will put plenty of buffer so that that we know that label is always gonna be ready. But if it's not, there's not much we can do, other than put an error label on it. Do that in a couple, you know, a couple in a row and then pause the line or give them some sort of an alert, a fault, you know, so that not everything goes to jackpot. But, you know, the other thing we do is we try to when when we're implementing, automation system, we try to give our IT, you know, stakeholders options on how they're gonna implement. So we we try to give the customer as much control as we possibly can. So we'll say, here's our guide, our standard API implementation guides. You can choose these these these as long as it as long as these fields are passed between your multi carrier and our software. You you mister and missus IT person have all the control so that when something is not working right, it's all in your power to fix it. So you don't have to call us and say, oh, what happened with our, you know, interface? That's you own the keys to all that. So that that's one way we try to mitigate some of this stuff. Yeah. There's a lot, there's a lot happening in the in the automation equipment. You know, we're we're generally told there's a a window of time, to process, you know, from the the scan tunnel to the the print and apply, three seconds or five seconds. And, we've even been told in the past that that might be the window, but you don't get all that time because we're doing. a lot of other stuff in that space. There's business rules. There's data exchange, and things of that nature. So, you know, speed speed is certainly a factor there in, in getting a getting a response back to, to retrieve a label. Cameron, I'll I'll I'll ask for your thoughts on this as well as a as a contributor. Yeah. I think it's just you know, what is what is your situation? You know? It's like, you know, what does your IT infrastructure look like? You know, do you have servers that are that are, you know, nearby? Are they on premise? You know, can you function in the cloud? Do you have a reliable Internet connection? Like, you know, what is what is your set of circumstances? You know, and then just like Alex had mentioned, like Julian had mentioned, it's like, okay. That's your happy path. You know? So you're gonna solve for the most efficient way, you know, for you to operate on any given day. And then what happens when something, you know, unexpected happens? How do you, you know, how do you pivot off of that? And do you have the flexibility within, you know, within the system that you've created in order to do that? Excellent. Let's move on to to the next, next idea here, around building building automation for resilience. And, you know, Cameron, I'm gonna ask you to continue continue that thought because I think it leads perfectly into, this question. You know, if someone's going to make a major automation investment, what's one question they absolutely should be asking before they sign off on the project? Yeah. I think, you know, to to build off the last response, it's just like, what are what are you going to do, you know, when when you need to move to plan b? And can you do that efficiently? You know, and then also just what's the overall reliability and what's the reputation of of the provider that you're working with. So if you've got someone that is known for stability and they can, you know, demonstrate and and will, you know, write SLAs into their agreement that, stands behind their equipment performance or their software performance or what have you, you know, then, you know, make make those choices. But it's always, okay. That's that's the happy path, and that's when the waters are calm, you know, when everyone's happy. And, you know, it always these these problems always seem to rear their head, you know, when when you need them, you know, to when you need everything to go right, whether it's Pete or whether it's Julian, you know, on Black Friday. It's like, you know, there's there's nothing worse than, you know, you not having a plan or not having a good cutover plan or maybe making the wrong decision because because you chose the wrong partner or the wrong technology that does not have, you know, that that does not have that redundancy and it doesn't have the resilience. And we think about that a lot more than, you know, really we ever have as we continue to get into larger and larger operations. Sure. Alex, what's the one question you would recommend that, someone ask before they invest in automation? Man, I mean, I can I can think of I'll think of two I've got two, but I'll wrap them up as as one, kind of blended together? One, it would be like, you know, first of all, before you implement some automation, do you have buy in from your IT and technical team? If you don't have buy in from your technical team, your automation project is going nowhere. I mean, Julian's laughing because you probably know it's true. But the first don't I call. yeah. If you don't have buy in from your technical team, then it's going nowhere. And, I mean, we know that just because on the on our side of things, when we're trying to work with clients, unless we get a call from at some point in the sales process, unless we get a call from an IT, expert, we know that we're not gonna get a PO and we're just not gonna get the project, because their buy in is so critical to the success. So if you're if you know that, then you probably should have a very robust plan on how how they're gonna implement this this from a software and IT perspective as well. So that that would be my advice and and, you know, really that all comes down to understanding where all of your ROI is located. A lot of times people don't see that, you know, that they don't take into account and and it's a little selfish in in some regard and you think, well, of course, you wanna know where all the money is at so we can charge all the money for the automation. But if we if you don't understand where all the levers are in your business, you probably are gonna under invest. in the project, and that's gonna result in unintended consequences down the road. So if you under invest in the the project and the automation, you might turn cut corners in areas that are critical in the ROI even making sense to pay off the project. You know, I think of things like if you if you don't have a robust multi carrier platform, how are you gonna do, you know, that sortation you wanna do down the line? You don't have multi carrier set up real well, so everything's sourced to the UPS plane. Why'd you put in the hardware if you didn't have all the rules in place to sort them by carrier in in the first place? So little things like that that people just don't think about. And and so that would be my advice. Find all the ROI that you possibly can so you fully understand your project. Good advice. And then, Julian, based on your experience, what should prospective purchasers of automation projects consider? Yeah. First, completely agree with with Cameron and Alex. I think reliability over speed from somebody that works in operations is definitely more important. And, you know, we see when we get customer feedback, is it reliability in getting package getting their packages to them is more important than how fast we did it. And then, yeah, understand your ROI, understand your business, know where you need flexibility, where you can get ROI. But my biggest thing would be, you know, when you're looking at an investment project, how does the automation help you win with your customers. is the biggest thing. Right? As someone that, you know overall, my goal is to support an organization that is trying to sell as much gear as possible. We wanna get everybody skiing, everybody biking, everybody outside. Right? And how do I do that to the best of my ability, and how does how does how does the this automation that we're gonna invest in help us win with our customers? Perfect. So we've covered a lot of ground here. We are we're coming up here on the end of our time for this webinar. I think those are actually good, good pieces of final advice as well. Let's go ahead and and jump to the q and a portion here so we make sure we've got, got time for that. So, again, if you've got questions, feel free to submit them, via the the q and a feature in the, in the webinar tool. We'd be glad here the last few minutes that we've got, to, to address any questions that you've got about the topic. Don't be shy. And, I'll, I'll take a a question here In terms of, you know, within the next three to five years, do you expect most organizations to move towards API, on premise, or hybrid environments? And my answer to that, would be, certainly more hybrid. We are seeing we're seeing a lot of shippers make the plunge ongoing full carrier API and then immediately regretting that because of all the hidden, pitfalls, involved as I've as I've mentioned. I really think that whether you use, you know, API or or a premise or platform engine, It's a consultative decision with your vendors, but, ultimately, as as Julian has said, you know, flexibility is key, and there may be no single right path. It may be, a combination of those things. And I think what we're seeing more of and will continue to see more of is a hybrid deployment method. I don't know if any of the other panelists have a have a prediction on that, but that would be my perspective. Julian, I thought your comment about how you guys are looking to be more of, on prem and have some options was pretty interesting where you can say, look, if if this site goes offline because I don't know the Internet goes out there, power outage, you can transfer orders to the other site, or even if the the carrier API goes out in a particular location, you can still either run there or you can run at your other site. That's pretty cool. Gives you the flexibility. Yeah. I mean, you know, flexibility is the biggest thing I would say from a shipping standpoint. Right? Is it it's not just among your current carriers if you add a new carrier, if FedEx changes the DIM rules all of a sudden. Right? And everything from point one up rounds up like they did last October, FedEx and UPS. Right? How can you how can you, you know, day of and usually, they don't give you a thirty day heads up. They're like, hey. This is changing in two days. So you have two days to make adjustments on your part. Right? And to try and mitigate some of that additional cost. So that's why I always harp on flexibility. You know, I think it is more tedious to manage some of that on prem stuff as far as, like, you know, managing the rules and things like that, but the control that it gives you, I think, pays for itself. Yeah. And I I think that's a a good point. Just in general, like, you know, Julian, you've you've hit it a lot. It's flexibility, flexibility, flexibility. You know? And and I think that everyone can, you know, kinda feel it in their daily life is that, you know, there is the world has never been, you know, more unpredictable. Right? And you don't know what is going to happen. And you you can do your best, and you can you can take your best, your best guess and, you know, and and lay the the best plan that you can you can think of and try to think of all the contingencies until something comes randomly out of out of left field. You know? And that's, that's a that's a kind of world that we need to live in, you know? And it's like you can't just get, you know, locked into fear. It's just like, alright. Let's, you know, let's let's let's just have a plan b, you know, and then let's also have a plan c because a and b might both go south on you. And and but your customers are still gonna rely on you. They're still waiting. You know? They've they've paid their hard earned money, and, really, they don't care. You know? They don't they don't care what the excuse is. They don't care what's happened. So yeah. 100%. Alright. Next question. What is the first thing you should test against operational risk in a highly automated fulfillment center? The first thing you should test against. I mean, I I don't know if this is the first thing, but I know this is something that we do is what happens if we dump quadruple the amount of orders or the amount of volume that we see on a daily basis into the system. Right? Give it a stress test because question. because what, you know, what we do every day is easy breezy. No problem. When Black Friday comes around, we're gonna have basically unlimited orders, right, is the way I always think of it. And, like, how do you get through as many of those of that you're you're never gonna ship all of them in one day. How do you do the most that you can, and can your system handle it? Because, I mean, in years you know, three years ago, our system went down for two hours on Black Friday, and it was a nightmare. Right? It's terrible. it's, like, one of the worst days in the six years I've been here. You know, rescheduling trucks, all all the fun stuff that comes along with that. So it's, you know, stress to I would say stress test your systems and make sure that what you have built can handle, you know, those those peak situations. Yeah. That's. a great, great point. I mean, we we do this when we implement and commission systems in the field, some of the biggest red flags are when our when our, project engineers come home and we say, hey, how did that go? How did that new system go? Went great. We ran, you know, they usually run a couple thousand orders a day, but we were commissioning it by Friday. They only had, like, 200. We ran all 200 and they went fine. So it seems like it's going good. Then Monday rolls around, and they run their their their stress test their normal volume, and something goes wrong. It's like, well, we could have seen that coming. We didn't commission it with enough to stress test the system and, so it we see that a lot. So we we try to instruct customers to hold hold back enough orders so that you can run, like, high volume through this thing, when it comes time. So Yeah. And and for me, I mean, my suggestion would be to, you know, break break things on purpose. Right? And make sure that your teams that are that are there and that you rely on to keep you moving, make sure they know how to find out where the problems lie. Because sometimes that's half of the battle. Right? It's like, okay. This thing you know, this this one system is not working. Usually, it's not that system. It's the system that is feeding the information, you know, in into that. Right? Just like if Alex has a slam line, you know, it's like and and, you know, his it's not that his, you know, machine stopped being able to produce labels and, you know, and and the vacuum line went down and all these things. It's like no. It's like, usually, something else has gone wrong. So, you know, as you're going into commissioning as you're as you're preparing for go live, it's like just just break something on purpose and and let. your team put it out and find it because it's gonna teach them about how the system works, and that's going to make them think critically. And, you know, hopefully, that will, you know, result in them being able to be more self sufficient So that's not always a call up to the provider or you don't need to pay for someone to come out. It's like, no. Stand on your own two feet, figure it out, and, you know, solve the problems. It's what Julian does all day. Right? I would I would add to that. It's an example from today. Make sure you understand how your system works and its decision making tree. We found something today that everyone thought they knew how it worked, including our senior VP of operations and people that have been in this building for fifteen years. And today, some one of our supervisors dug into the actual code and decision making and was like, hey, guys. This doesn't work the way we actually thought it worked. So, you know, ask questions and, you know, go go for don't don't just the old you know, it's the old, well, this is the way we've always done it. Right? Don't don't don't accept that answer. Go go figure out how how it actually works and make sure that you understand how the decision making process is functioning within the automation. So we got time just for maybe, you know, a thirty second discussion of, another question that's come in here. What challenges have customers experienced after growing beyond their original deployment Glenn, do you wanna take a run at that one? architecture? Well, yeah, certainly. I mean, it's it's, speed, is certainly one of them. We get calls all the time. You know, my my solution is not able to keep up with where we've grown. And it's time to look at the processing speed of the software as well as potential for, reengineering on the automation. Those are a couple of things that, that we look at. But, certainly, being able to keep up, with, with, the demands of of higher growth is one that I would add. Yep. I mean, I would agree. When when when people outgrow their automation system, we typically see them start throwing labor back at things or maybe extend the time that they're open or second shift or something, and then they need to revisit, more. Yeah. Right. Kinda right back where they started. Yeah. Right. Yeah. So think we're go ahead, Julian, if you had something just gonna. say, hopefully, you've already, you know, you're in in one you're in a you're in a good situation probably. It's like, hopefully, you already got the ROI out of your old equipment. because it's all you've grown. Or you grew so you grew so fast that you're in a great spot and you can make some cool decisions. Yeah. It's a good problem to have. So at the end of our time, we're going to wrap. Thank you everybody for attending the session today. Thank you to our panelists for taking their time to share their insights. We hope the discussions helped you better understand how shipping technologies and architectures influenced automation performance and operational resilience, ultimately, the ROI of your warehouse investments. So go out there with this knowledge. Do great things. Any additional questions, feel free to follow-up with us. But we thank you again for attending. Have a great day, everyone. Thank you. Thanks.