Listen Now!
Spotify Apple
In this episode of Supply Chain Connections, Brian Glick sits down with Dan Bailey—co-founder of Nexcade and former COO at Sedna—to talk about:
- Why freight forwarders need automation that adapts to messy, real-world workflows
- What “forward-deployed engineering” actually means—and why it matters for AI
- Lessons from Sedna on change management, user adoption, and the limits of top-down process design
- How Nexcade is approaching high-friction tasks like spot quoting, rate procurement, and order entry
- Why deterministic software breaks in a non-deterministic industry like logistics
A must-listen for anyone building or buying logistics tech in the age of AI.
Listen Now!
SpotifyAppleEpisode Transcript
[00:00:00] Brian Glick: Welcome to Supply Chain Connections. I'm Brian Glick, founder and CEO at Chain.io. On this episode, we are chatting with Dan Bailey. Dan is a co-founder at Nexcade, which is a young company working in AI automation inside the logistics space. I first met Dan when he was at Sedna building, uh, email automation.
[00:00:23] Capabilities inside this, uh, industry and have been very excited to see his enthusiasm for our industry grow. And we're gonna chat about that as he comes from a non-traditional background, as in he isn't born into it. So I hope you enjoy the episode.
[00:00:43] Dan, welcome to the show.
[00:00:45] Dan Bailey: Brian. Thanks for having me. Delighted to be here.
[00:00:48] Brian Glick: So let's start off, you have a non-traditional journey into this space, so I'm very curious how you got into this business, 'cause we have about three canned answers that we hear from everybody and you are not gonna give one of them.
[00:01:01] So tell me, tell us how you got into the business and then I'm even more curious why you decided to stick around for another go at it.
[00:01:08] Dan Bailey: Yeah, my background, I started out, I grew up in the northwest of England in a small village. Came down towards London, studied economics, and ended up joining Deutsche Bank in investment banking.
[00:01:19] And yeah, very far from supply chain. But I was, while I was there I learned a lot of things, but got burnt out a little quickly by I think the detachment of what we did from reality, you know, reducing these enormous transactions and the companies that we work with, which were incredibly rich and interesting companies, down to a set of numbers on a spreadsheet, really didn't jive with me.
[00:01:39] And so left investment banking after a couple of years, joined venture capital and was where I got my first foray at the intersection of supply chain. So I started, we were investing in early stage technology companies across the UK and Europe, and started to dip my toe in a little bit by, just started looking at investing across the digital freight forwarder landscape, some of the early supply chain technology landscape between 2015 and 2020.
[00:02:04] Ultimately, did not get as excited by one or two of those propositions as the company that I ended up joining, which was Sedna. I joined in 2020 building supply chain communication software. So we worked across the supply chain landscape. Any companies that were struggling with high volumes of email and tremendous volumes of communication, which turns out to be almost every company in the supply chain.
[00:02:26] I started off as chief of staff, ended up becoming Chief Operating Officer, and stayed there for four years before leaving to start Nexcade.
[00:02:33] Brian Glick: So what about this led to you and well, I do want to hear about what Nexcadeis doing 'cause you guys just just launched. But before we get into that, what about, this was interesting enough at Sedna that you were like.
[00:02:49] I'm gonna do another one. I'm not gonna go down the email collaboration path or the generic things you learned about startups from being in a venture backed company, but the specific, I wanna work with these same customers again and I wanna work in this universe.
[00:03:05] Dan Bailey: Mm-hmm.
[00:03:06] Brian Glick: Why?
[00:03:07] Dan Bailey: Yeah. Well, it's funny, actually at Sedna we had a similar thing that you tended to, we hired a bunch of, like, we hired about a hundred people in the time I was there.
[00:03:15] Uh, a bunch from some supply chain backgrounds, some from outside supply chain, and those that came from outside supply chain tended to have a kind of immune response one way or the other, which was they were either kind of in and out after 18 months, never to work in supply chain again or a handful of people who you know now have stayed Sedna a long time, but we've got now colleagues across the industry on both the kind of maritime shipping side, but also across the freight forwarding and logistics side across the industry.
[00:03:42] And I think there's, I think people have a sort of one type of response for another. For me, logistics has this kind of, it's just this like wonderfully fascinating problem space with a wonderful set of people. So you have this constant need to both, you know, you are optimizing the supply chain, which is an enormous system, but in a hyper-local fashion often.
[00:04:04] So you have individual people who are trying to make the best decisions on a single cargo or in a single office while it's at scale. We are trying to ultimately impact how the world gets clothed, fed, heated. This interplay between the micro decisions that stack up to this macro optimization is just an incredibly fascinating problem set to tackle every day and to do our little bit to potentially make it 1% better.
[00:04:29] And you could combine that with a set of people who just, I think. They fall. You know, the people in this industry tend to be in it for years and years. They fall in love with a set of problems as well. And so I think it's a kind of intoxicating space to end up.
[00:04:43] Brian Glick: Well, congratulations. You're officially a freight nerd now, um, sorry to inform you if you didn't know that, but you're in.
[00:04:50] So tell us, just for context, give us a little bit about what you guys are doing, what you just launched and what the vision is.
[00:04:57] Dan Bailey: Hmm. So at Nexcade we build intelligent automation for forwarders and sowhat that looks like is we build end-to-end products that forwarders can deploy in like critical workflows within the shipment life cycle.
[00:05:10] Today we focus a lot around rate life cycle, so our three products are initially focused on rate procurement. Spot quotations and booking and order entry, and we build tooling that allows a forwarder to deploy that into their existing workflow, whether that sits in email, in chats integrated into their online portals, and to bridge the gap between the unstructured, bringing that team in when necessary, but also all of the structured data that they have access to perhaps across many fragmented systems.
[00:05:40] Brian Glick: So I would imagine, actually I’m certain 'cause I also do software, that one of the great challenges when you're going into something like the rate business process is there are existing processes and even more so than processes, people who have to change. And I know at Sedna you had a similar thing because you are literally taking away someone's most precious thing in the world, their outlook.
[00:06:08] Right? And you're saying you're gonna do this differently. What did you learn about change management and how's that informing what you guys are doing?
[00:06:17] Dan Bailey: Yeah, I think one thing that Bill, the founder used to say is often to make a process better, you have to capture it first. And so I think one of the things that we have seen limitations of other software is just a very heavy-handed approach to change management where you don't appreciate the nuances of why a process is done in this sometimes byzantine way that when you, if you're not as familiar with the problem as the person on a pricing desk or an account manager, it can seem sometimes irrational, but the closer you get to the problem, the more you really.
[00:06:48] Goes to it by acting in a very rational way. It just perhaps doesn't scale. So the way we take, um, a very, what we call forward deployed approach, and my co-founder is ex Palantir and we spend a lot of time with our customers really understanding all of the nuances of how they tackle the problem today.
[00:07:06] And then we go through this exercise of understanding which of those behaviors do we still want to capture and enable, and which of those behaviors, perhaps they're actually done differently by different team members on the desk, but not for a specific reason, but because that's the way that they were taught or that's the way that they learn the business.
[00:07:21] And so we try to be as thoughtful as possible in identifying actually which of those nuance behaviors are important to replicate, and which of those can actually be part of a transformation process. And then you have to spend a lot of time actually getting the team on board that you're working with, like understanding the wants and the nuances of the different team members who are gonna come on and position to them that this is something that
[00:07:43] can help elevate them in their role and uh, can enable them to do more and often to do more of the type of work they want to be doing, which is speaking and spending time with customers, being on the phone, being in the field rather than manually rekeying data and pulling together spreadsheets and emails.
[00:07:58] Brian Glick: So I'm going to double back on the term forward deployed for a second.
[00:08:04] Dan Bailey: Yeah.
[00:08:04] Brian Glick: Because that is a hot topic in the B2B AI space, but not something that most of your customers or our customers, they don't even know what that term is, and sometimes they're experiencing it now without even being able to label it, but explain what forward deployed means and why.
[00:08:29] Why we need it now, and we didn't necessarily need it for other products, or maybe we just didn't know.
[00:08:34] Dan Bailey: Yeah, I think a bit of both is a very trendy term now, partly because the Palantir stock is ripping so much, but Palantir are a large US AI and data company that popularized the role. What we mean by forward deployed is that our leading and our best engineers and our team come out in the field with our customer facing team members to spend time on the desk with our customer and understand it.
[00:08:58] So the prior abstraction where you might have a customer success or implementation person writing up a set of specs and trying to deliver that either with the tools that they have available, or asking engineer, creating a couple of tickets, their engineers creates this dissonance and abstraction between what happens in the field and what the people who are actually building the software really understand.
[00:09:19] And by going forward deployed, we try to completely collapse that process and build both a level of understanding, but a level of empathy with our customer among our engineering org. And I think what that allows you to do is build a much richer, more relevant, more accurate set of products. But why is this more common now?
[00:09:38] I think in the era of AI, we've shifted from a world in which the AI doesn't do all the work, but it is doing an increasing amount of the work on behalf of our user. And as a result, we're not necessarily building tools with the perception of, you know, here is my abstract persona of a user who uses my tool in this way, and it could be a monday.com or a Microsoft product, or a supply chain product.
[00:10:01] We're now thinking about how does this user execute this piece of work so that when we send them a quote to review, or we have extracted data from a document that the AI can do it as well as the best person on your team. And in order to do that, our end user and our product needs to understand the nuances of your workflow just as well.
[00:10:22] And so I think collapsing that distance between engineering and customer is incredibly important in this era.
[00:10:28] Brian Glick: So if I was a skeptical investor who didn't know the Palantir stock price or I was say a CIO at a freight company and going, Salesforce didn't need to send people into my building, and I'm like, what makes this scale?
[00:10:50] Like, is this a short term problem while the AI tools are getting better and we can productize them, or do you think this is a groundswell kind of shift in the way that software is delivered? Sorry to go at the hard ones.
[00:11:05] Dan Bailey: No, I think you're right because we think about it a lot in terms of how we can scale our company and.
[00:11:11] I would argue that actually with Agent Force, Salesforce are gonna be deploying FD forwarddeployed engineers in the field before long. But one of the reasons it works at Palantir is their average contract is about $2 million, and so you can amortize the cost of a couple of bright but young engineers going into the field, if you're going to build software.
[00:11:29] It is more accessible for a wider audience of customers. Ultimately, you've got an economic problem of how do you rationalize the cost of a very expensive engineer spending a lot of time in your customer's offices. For us, each customer and even every office might have their own nuances about how they handle a particular freight workflow.
[00:11:48] These are often unique and novel combinations of understood concepts as opposed to this person has created this entirely new way of executing a workflow. And so for us, that may be specifically how you handle non-stackable cargo or hazardous cargo. We've seen, you know, a handful of half a dozen, a dozen different ways based on different SOPs and different requirements around your agent or your supplier network.
[00:12:16] But that requires some level of customization. But each time we're building, we're thinking about how do we rationalize this back into a core concept so that the N+1, the next customer can benefit from that in a faster and more effective way. When we think about configuring these key concepts, I think if you're not building software with that in mind and you're taking a very horizontal, unopinionated platform approach.
[00:12:40] And you're using forward deployed engineering to deploy all of the industry context, all of the nuance into your software from scratch every time. I probably don't think that will scale unless you can get to those million dollar plus contracts off the bat. And so I think we think about it as being a tool in an era in which we need 10x more domain understanding to build great software.
[00:13:01] It is a sort of a mechanism for us to fast track deeply understanding all of our configuration options in the future. And maybe that will get to 20, 30, 40 for lots of these little workflows that we can eventually bring together much, much more quickly. But for us, it's a tool to build great software faster, but we think it will scale over a long course of time.
[00:13:22] Brian Glick: So if I was a CIO who wasn't used to this and I needed to quickly develop a bullshit detector for people coming in and pitching me. Would it be fair to say, just to kind of summarize this, that the difference, I could look at two companies and try to figure out whether one is a consulting shop who is trying to build software, and one is a software company who's using forward deployed engineers.
[00:13:49] And the kind of distinction would be to ask about how much of what you’re building out of this is going to go into a general product release and how much of it is just going to sit in a folder called my company name and not loop back into the core product?
[00:14:11] Dan Bailey: Yeah.
[00:14:11] Brian Glick: Is that kind of the scale that you put things on both sides of?
[00:14:15] Dan Bailey: That is definitely one area to dig into because if your provider, your vendor is not doing that, then the code or whatever they produce for you as the CIO, it's not gonna scale. They're not going to put as much love in it in six months or 12 months or 18 months time, and so you're going to have the same typical problems that you got from custom built software for the last 20 years.
[00:14:36] The other way that I would turn my bullshit detector on is if you're working with a vendor who knows your use case, ask them how they've handled similar problems to the ones that you might face. Take a nuanced approach to pull preferences within their customers, or handling hazardous or non gen, non stack, or other types of out of gauge cargo.
[00:14:56] Ask them how they've handled it with their other customers in the past and how that turns up into software. They may be building some kind of customization or adjustment for you, but if they can't clearly articulate how they've done that in the past, it probably means that they haven't actually looked to that problem at all.
[00:15:12] Brian Glick: That's fair. Couple of things that happened this year as we're getting to the end of it at Chain that I think are interesting corollaries. One of the things we did around the springtime was we made an internal statement or I made an internal statement. I said, code is no longer sacred. So instead of building forward deployed engineers and calling them that, what we actually did was we took the role that was our business analysts and we said, you are now allowed to write the code instead of the spec.
[00:15:43] Right. Which I think is effectively, like we came at it from a legacy perspective. We had this role, this business analyst role, and the big change we made was saying, you are not allowed as a business analyst to go into the core processing engine of Chain because you don't have enough engineering training.
[00:16:00] Dan Bailey: Mm-hmm.
[00:16:00] Brian Glick: But with the combination of AI assisted code and what have you, if you realize that we need six more fields mapped or that the way that we're handling carton combinations in relation to the items inside of them in a plugin to system that is different. Then just code it and then document what you coded as opposed to writing a document and then asking someone to code it and they'll get it probably equally wrong as you're gonna get it on the first try, so you might as well just do it yourself.
[00:16:31] Um, that was kind of the legacy math into that, and I think for a lot of internal IT groups at forwarders and what have you, they would potentially benefit from internally taking that mentality that we just sort of came up with. This term code is not sacred, but this isn't a thing to be guarded anymore.
[00:16:51] Dan Bailey: Yeah, look, I think the entire generational shift in AI is incredibly empowering for up and down the stack for your fully non-technical user who may not get something into production, but they can potentially try new tools to be able to kinda express themselves in a way to their internal IT org in a way that they couldn't before because they can go and use Lovable or BOLT or any of these coding tools and they can get something that looks reasonably plausible and can work in a way that they can then hand that off to someone which has a level of richness they never had before.
[00:17:23] Or you have a semi-technical folks who are now equipped to be able to, as you say, kind of shift from writing specs into writing code all the way down to, I'd say you know, and we've hired, we've had the benefit of hiring in a kind of AI first era from the start, but your kind of highest and best engineers are now more leveraged for me ever have been before, to be able to write more code and execute in a way that was never previously possible.
[00:17:49] Brian Glick: So I think one of the things that would be scary for me if I had come through the pure engineering path is there's a cliche, at least in my generation of engineers, that I gotta go talk to the customer today. Right? And now that's the job, right? Like the really good engineers, and I think Amazon actually.
[00:18:11] With AWS sort of pioneered a lot of this because they always made their products and continue to make their product teams available to the customers.
[00:18:19] Dan Bailey: Mm-hmm.
[00:18:20] Brian Glick: But in that case, it was often programmers, talking programmers, but now it's, oh my God, you are gonna be in the room with the CFO and the CCO.
[00:18:28] Dan Bailey: Yeah.
[00:18:29] Brian Glick: Kind of coding on the fly while they're talking. Not hopefully, literally. But you know, I have seen that happen. But you know, this idea that. Soft skills and all of that, like how does that go into your thinking about hiring?
[00:18:44] Dan Bailey: Yeah, so I think we have probably a very different interview process to lots of other companies.
[00:18:48] As a result, we actually lean into hiring like very strong senior generalists. And so I'd say the composition of our engineering org would've looked very different if I was building a company from scratch three years ago in terms of seniority. But also we have. I would say generalists who can work across the entire stack that spike in one of three areas for us.
[00:19:09] That's platform. So they build out an underlying tool set, both from an infrastructure perspective and for the tools for our product engineers. And then we have AI and products as two separate skill sets. But within each of those, we have two technical based interviews. One is a coding interview, but the second is of equal weighting is a problem solving interview, which actually involves zero code and we give them a very abstract problem.
[00:19:34] Sometimes a supply chain problem, sometimes something that's in a slightly different domain, but we give them like a problem statement delivered by a customer and actually they have an hour to get to a solution to that problem. And we spend five to 10 minutes in the end discussing how they would implement that technically.
[00:19:50] But we really gear up like relative indexing on their ability to problem solve, ask good questions, and get to the heart of an issue they've never heard about within 45 minutes to an hour. And I think the traditional software engineering process would do nothing like that.
[00:20:05] Brian Glick: So you guys are release stage, right?
[00:20:08] And you just, just launched a few weeks back from at least from more. Recording this, and so you have the luxury of being able to answer this question without 150 or 200 customers getting mad at you and thinking you're talking about them, but knowing what you're headed into from having dealt with this customer base before, what do you wish buyers in logistics.
[00:20:29] Would do better? What is annoying about the customers that they could improve on that's going to make it hard for you?
[00:20:36] Dan Bailey: That's a really good question. I would say probably the first one that both makes it hard on us, but makes it hard on them is understand their buying process before they start purchasing software.
[00:20:47] And so understand who in their organization needs to be involved in this process. What are you trying to achieve by buying it? How are you going to evidence that in your decision making process and what timelines are you making decisions on? I think this is just the basics of buying software, but in an industry where perhaps software change is not as frequent, and sometimes if you are an operational leader or a commercial leader and proposing a change, this is not your day-to-day, and by no means are you or should you be an expert in it.
[00:21:23] But all of those things can both hold you back, but also can be challenging for a vendor when you don't have understanding of that process upfront. So I'd say that's probably one part, and it often leads to friction both internally and externally when either requirements change or timelines or understanding of what success means might change.
[00:21:43] Brian Glick: couldn't agree with you any more. Yeah, it was interesting 'cause coming from being a CIO into the software space, when we first brought in external investors who were not from the space, they started asking me some questions about buying cycles and personas and decision making processes at the customer.
[00:22:05] And they were asking me to draw out the map of the buying cycle and decision making process at a freight forwarder and I was then CIO, and I had no idea how to explain it to 'em. I was like, I don't know. They're like, well, you know, is it an end of the year discretionary spend or like, where does this get put into the planning cycle?
[00:22:25] I, you know, from my experience at mid-size and small, you know, I never worked at a, you know, a Maersk or DSV, but like, it was like, Nope. Stuff just sort of comes up and then we decide whether we're gonna buy it or not, and who's involved. It kind of depends on who's in the room and who's mad at who that day. And it is actually, I agree with you, and for anyone who's listening, knowing your process is so unbelievably valuable to being able to either decide to buy something or decide not to buy it quickly.
[00:22:58] Dan Bailey: Mm-hmm.
[00:22:58] Brian Glick: Because, oh my God, these software vendors hate the fact that you don't know that you actually need your CFO to sign that piece of paper.
[00:23:04] Dan Bailey: Yeah.
[00:23:05] Brian Glick: Right. And then really you're not engaging them at the beginning.
[00:23:08] Dan Bailey: Sure. And look, I think the very best trained account executives and sales reps can help customers on this journey.
[00:23:14] Uh, without a doubt, the very well-trained, uh, reps and they, and. Some of those we worked with at Sedna were incredibly helpful in helping their customers think about how they structure that process, what sort of analysis they wanted to do internally, what analysis they wanted to do externally, and give them a path to a mutual close.
[00:23:35] But sometimes buyers have a resistance to being pushed one way or another by a vendor with good reason. And other times, you know, you are busy. I'm a busy founder and you can't always coach every person you're working through the process. And so. Yeah, I think that would be hugely beneficial. And I think then the flip side is, it's kind of the same with, you know, what does a great implementation look like?
[00:23:54] And for us it's not just getting people over the line of purchase, but you know, we're extremely customer centric at Sedna. And that is a hard and sometimes overwhelming change management process. But ensuring you put as much effort into the change process in the implementation process as you do into the buying consideration is super important.
[00:24:12] When we're hopefully talking about 5, 10 year decisions and investments.
[00:24:17] Brian Glick: So what has you most excited about the future? What really got you getting out of bed in the morning?
[00:24:23] Dan Bailey: I think in one sense the share pace of change in this industry, but across the entire AI space, I think I've probably seen more willingness of the freight industry and logistics industry to engage in new software in the last couple of years.
[00:24:38] And in the last decade that I saw both looking at it from an investing and from an operating perspective, and then the sort of tools that are at our fingertips to attack a set of problems that were just previously just too gnarly. They were too challenging because the kinda sets of technology available to us into the more traditional regex and data extractions and deterministic workflows.
[00:25:00] Just did not work for an industry. As networks as sometimes unstructured and as real time as the supply chain is, you now have this approach that you can deal with both a lot of what you guys focus on at Chain of bringing together a lot of structured data and integrating and bringing together a lot of fragmented systems, but being able to both execute that centrally, but execute the edge because you can now be in someone's inbox and help them handle on a sort of individual scale some of those decisions and pull the right data.
[00:25:28] At runtime at the time of a decision and not have to have all of your systems implemented in order to do so. I think it makes the opportunity and kind of the potential of some of the technology we spent so long working on to actually get implemented so much greater.
[00:25:41] Brian Glick: So I'm gonna try to distill that.
[00:25:43] Dan Bailey: Sorry. Yeah. I,
[00:25:44] Brian Glick: no, no, no, no. It's a complicated set of concepts, but, you know, a picture just popped into my head of the watchmaker, like a watchmaker does not get to have a non-deterministic world. Right? Like they, you know, the, we will picture the old man sitting in Switzerland in the workshop, all the little gears and pieces, and that watch is going to operate for a hundred years based on exactly how he assembles it with no changes the day that that watch goes out the door.
[00:26:18] Dan Bailey: Hmm.
[00:26:18] Brian Glick: Right. And so that's how we have built and sold software in the past in this industry very specifically, and we wrote SOPs to make sure that no variation ever happened that would make the watch break, right? Like you can't put the watch in water and you can't use the watch, you know, under these pressure circumstances.
[00:26:39] And, and don't shake the watch too much and all of these rules for people so that the watch is gonna work because we cannot open the watch case and change the gears in the watch ever. And now we're saying is we're not really going to have, the watch case itself becomes malleable all the time, right?
[00:26:59] This is where the analogy breaks. But this idea of deterministic and non-deterministic in our industry is probably much deeper than a lot of others because the reality is we never lived in the watchmakers world, like banking lives in the watchmakers world. Because I define what the mortgage form looks like, I give it to the customer, they are required to fill out the form, and I get the form back.
[00:27:23] And I have a set of regulations that define the world in which the form operates. And all of this, well, we're all in the freight business, right? So there is no, we can't tell the world to work the way we want. The watchmaker designed the world, the environment. Is that a, I know it's a, I've now turned my summary into its own rant, but are we, are we honing in on something here that is a mental shift in the industry?
[00:27:46] Dan Bailey: I think so, yeah. I think we're heading to a technology paradigm that actually more closely reflects the real world that we've lived with. We've spent sort of 25 years trying to condense what people do in the field and every day into a set of milestones and a set of structured data and a set of SOPs.
[00:28:06] Everyone in the knowledge that sometimes you vary from that and sometimes there's this exception and sometimes adds up and it ends up being an awful lot of the time, and that we now have the ability to take those SOPs and combine them with sort of incredible amounts of potentially context. To more replicate that in a computer than simply to take your watch analogy, X must equal Y and if it doesn't, it breaks.
[00:28:30] And if you build software that breaks when there's an exception, I think that is ultimately flawed when you're dealing with something like supply chain.
[00:28:36] Brian Glick: That's, uh, I think a great summary there. So tell everyone where they can find out more about what you guys are working on and, and we'll wrap up with that.
[00:28:45] Dan Bailey: Yeah, so we're, our website is www.nexcade.ai. You can find me on LinkedIn and not very much an X these days. So dljbailey on LinkedIn.
[00:28:58] Brian Glick: I appreciate you opening it to www. You don't hear that all that much anymore, so. Cool. Well, thanks so much for being on, it's, it's really exciting.
[00:29:06] I'm very enthused to see what you guys are building next,
[00:29:10] Dan Bailey: Cheers, Brian,
[00:29:16] Brian Glick: Thanks again to Dan. It's always fun to chat with a friend and we'll have a link to Nexcade down the show notes as well. Make sure that you're checking out Chain.io on LinkedIn and on our blog. We've got some really interesting things coming out. Again, AI is a buzzword, but it's also a product feature, and we're launching some really interesting things specifically for dealing with those huge spreadsheets that you still have people searching through manually every day to find exceptions.
[00:29:46] So keep an eye out for some new product releases in that space and hope you enjoyed the episode, and I'll catch you again next time. I'm Brian Glick and thank you for listening.