Is AI In Your TMS Helping Or Risking Everything | Final Mile 142

Nate Cross & Ben Kowalski answer your freight brokering questions and discuss:

📄 Starting A Brokerage + Factoring Questions

🚛 Handling Carrier Deadhead Pay Requests

🤖 Using AI To Automate Brokerage Operations

Support Our Sponsors:

Togo: Click Here

OperFi: Click Here

QuikSkope - Get a Free Trial: Click Here

DAT One - Brokers & Carriers: Click Here to get 10% off your first year!

DAT Outgo Factoring for Carriers: Click Here

AscendTMS: Click Here and use promo code RA-freight360! to get AscendTMS FREE for 90 days!

Recommended Products: Click Here
Freight Broker Basics Course: Click Here
Join Our Facebook Group: Click Here
Check out all of our content online: Click Here

Transcript

Welcome And Listener Questions

SPEAKER_01 0:19

Welcome back for another edition of the final mile. We are up to 142. A lot of questions that we've been asked and that we're answering. So keep them coming our way. You can send us a question by leaving a comment on YouTube. You can email us info at freight360.net. There's also a contact form on our website. So make sure uh check out all the sponsors in the description box that helps support this channel. And uh let's get into it today, Ben. Our first one, and this comes from so we've got, I think, one from YouTube, one from Facebook, and one from Reddit today. So first one, here we go. I'm about to start my own brokerage due to one of my customers needing help finding carriers. So this is a um this is a motor carry that's gonna open up a brokerage. I've been working with this customer as a carrier for over a year now, always pays on time, but we agree on a rate in person or over the phone, and I just invoice them. I do, or how do I go about this? Oh no, I will be factoring with the brokerage. My question is about proof of the rate. How do I go about this situation? I would like it to be in writing to cover my butt, but does an email count as well? And do factoring companies prefer other methods? So they're basically saying, How do I get the proof of the agreed upon rate? Because I have seen, I've seen many situations where uh a customer gets invoiced and then they short pay us, and then we you know we go to the broker that handled it, and they're like, Oh, the customer said they were gonna pay this, and the customer's like, I never agree to that, right? Like, what's this charge for? And then you get this kind of back and forth dispute, and ultimately, like, if you don't have a paper trail, um, we don't have any concrete way to like say that like legally, yeah, you owe X amount of money. So that's why we always recommend get it in writing. It could be, you know, ideally like a load tender that has the rate listed on it or an email from them agreeing to it. I would usually say if you're uh, and then I'll kind of defer to you on the factoring side because I don't haven't really dealt with it a whole lot. But if you do agree to a rate or something over the phone, a quick follow-up email to that customer saying, Hey, just confirm it from our our phone call. Um, here's what we agreed on, here's the rate. Please, you know, please confirm. And then they can say, Yep, good to go. Now, on the factoring side, what's your experience been with this? What is a factoring company typically gonna require to get a uh do they tell you like, hey, we need an email from them? Or what how does that usually shake out?

SPEAKER_00 2:55

Yeah, I mean, as long as it's in writing, it's fine. To be honest, most factoring companies that I've worked with, like practically speaking, are pretty loose on what they need to compare it to. Um, as long as the POD and the rates confirm from the brokerage, they'll process it. Then what happens is the customer goes, uh, that's not good enough for me to pay you. Then the factoring company goes back to the broker and says, give me written proof. Yep. Or they take the money right back out of the bank account, is usually how it's done. So, like, just a good, I think, habit to be in is anytime you're negotiating a rate in person or over the phone or via text message, like you just send them a quick email. And this is the important part. You don't ask your customer to send you the load details and the rate because you're asking them to do work that you need done. They already told you what they need. You need to meet them where you need them, which is you email them, these are the load details. Here, here, this is what I'm picking up, this date from here to here, this is what you've told me over the phone. Please just confirm yes. And then you give them the rate that they told you over the phone. So you do all the work by putting in writing, send it right to your customer, and all they just were his reply, yes, confirmed. Save that email. That's your load tender, that's sufficient.

When Deadhead Pay Makes Sense

SPEAKER_01 4:11

Very good, straightforward. Yeah, I mean, with uh I kind of imagine that with a factoring company, like until a customer short pays or challenges or disputes a charge, they probably really don't care a whole lot about what you've, you know, how how you've um got your rate um documented, right? Um all right, our next question How should I handle a carrier that is requesting that I pay for their deadhead? My rates are posted and cover from location A to location B and they're already above market rates. Um well, I I would say that this just kind of depends on uh ultimately the the long story short is that you don't have to pay a carrier for a deadhead. You just don't have to load that carrier.

SPEAKER_00 5:00

You just might not get a truck, depends on where your load is. If your truck is, if your shipper is loading, and I did this with somebody this week on a carrier training, the carrier sales. I'm like, look at a map. If your load is picking up in the next closest city, and I use that term loosely, is like 250 miles away, and your load is picking up like in the middle of like the desert in Nevada or North Dakota, and you go look at search trucks and there's not a truck within 150 miles, you should probably be paying deadhead because there's literally aren't going to be trucks there.

SPEAKER_01 5:31

Expect to be, yeah.

SPEAKER_00 5:32

Yep. Yeah. And if you're posting a load out of Dallas and a truck wants deadhead money, like you could probably find a truck that's closer. So like it's kind of subjective, but kind of not. It really does depend on like what is the likelihood you actually need to pay deadhead, not just the fact that a driver's asking for it. If every driver you speak to on that load all day is asking for deadhead, look at a map, it'll probably confirm there's no trucks within 200 miles and the trucks are willing to pick it up because they have to drive past your place to where they wanted to go anyway. That's when this usually comes into play.

AI Versus Automation In Logistics

SPEAKER_01 6:03

Yeah, this just comes down to supply and demand, right? Like at the end of the day, if if the carrier wants my load but is asking for more than I am willing to pay, well, there's something's gotta give, right? I've either got to move on to another carrier, or if there isn't another option and the supply just isn't there, then that's how this, this is how this works, right? This is capitalism. I'm gonna, if I want to use that truck and that's what he or she is is is asking of me, then that's what you're left with, right? If you, if you if you want to use that truck and they're requiring deadhead or pay you pay them more, you're gonna have to pay them, right? Um, there's not like a industry standard of like, hey, because they have to drive X amount of miles, we have to pay this. Um, it's just if there's plenty of trucks available and one of them is further away and wants deadhead, probably not the best fit for that load. Vice versa, there's if they're the only one available and they're asking for deadhead, well, if you want them, you're gonna end up paying extra money to cover their empty miles. All right. Our last question, and I'm curious. This is a this is a good one with AI. So they said this came from Reddit, too. It was a bit of a longer one. I'm wondering how you guys are using utilizing AI at your companies. I spent Sunday after Mother's Day brunch using Claude to code an app that can now scrape my Outlook emails and enter and orders into our TMS via API. Works perfectly on quite a few of our larger accounts that I have predictable templates. I'm training it on all the different customers in dosyncrasies before I roll it out to the rest of them. What a good word.

SPEAKER_00 7:43

Idiosyncrasy.

SPEAKER_01 7:44

Oh, idi idiosyncrasies. I even read it wrong. Curious to see what other people might be doing. I've heard good things about open claw and got that set up yesterday. I haven't really figured out a use case for it yet, though, thinking maybe the ability to have it respond to customers' emails. All right, so AI in general. I want to up front say some people use that word or that phrase loosely and they just mean automation and it's not actually artificial intelligence. Here's what I've here's what I've seen with in my TMS search over the last year is if if a TMS is just connecting to your inbox and scraping data and pre-building orders for you, or you can drop a load tender or an email into it and it pre-builds the load. I'm not gonna call that artificial intelligence, I'm gonna call that automation. Where I've seen real AI kind of cool stuff is when it connects with your data, whether it's your email and other various things, and then it starts to learn based on how you tend to proceed when you get a certain kind of an email, or it when it truly is learning and evolving, I would call that AI. Um so I would use what I would personally say is start off with some basic automation. And I'm I'm curious on your personal uh thoughts here, but I would start off with some basic automation to simplify the task. This kind of goes back to what we were talking about with the Togo guys last week, but you know, the the little things that take up your time that don't allow you to sell more and service your customers more, start to offload those through some sort of automation. And then when it comes to true process efficiency, um, I would, if you're gonna implement AI and like this, this guy, like pretty impressive what he's what he said he's doing here. Um, make sure you fully understand what these tools are doing and the sometimes lack of limitations on what what they can do that you maybe aren't thinking about. Um like I've heard OpenClaw, for example. I listened to a podcast that kind of talked about like when you use a tool like that, that like it basically creates like an agent that has like full autonomy in your system, and you kind of just remove the guardrails of what you're gonna let it do. It could go in and like totally tweak and crash your system. So I would say like slow and steady until you fully understand what you're limited limiting its its uh capabilities on. Um, but I'm all about like process efficiency, right? If we can have a um you know some sort of process where we get a customer a response faster and it's accurate, I'm all for it, right? If we can get the load built faster, I'm all for it. If we can get rate information and market intelligence and um understand the the capacity in a certain region faster and easier, I'm all for it. What's your thought on implementing AI into your workflow and into your tech? Um and maybe even specifically to this guy's example.

SPEAKER_00 10:59

Carefully and slowly, they're very different things. They all, like you said, are commonly used under like one term, but they're very, very different when you get down to like use cases. Like agentic AI is pretty the common one, which is like you send in a prompt, whether it's Claude, Gemini, whatever Chat GPT, it's going back to the giant data set that it's learned on everything and giving you a response. When you're using agents to get them more accurate, you need like a decision tree, which is really a very long prompt to get it more accurate. So, like anyone that's used these just manually long enough will start to realize how you ask the question determines what you get back. Yeah. The longer and more specific you are with the question, the more accurate the answer becomes. So when you plug a lot of these tools directly into an AI model, you need a lot of architecture underneath it. So, for example, our new TMS has this that's plugged into an agent. So per customer, there's literally like a decision tree of prompts that says, when reading this load tender, this number here is not the BOL, it's the pickup number. This number here is actually referencing this. And then more specifically, do not put it anywhere because you're just telling it what to do, but also what not to do. And these get really long for them to actually get anywhere near accurate that they're usable. So the first is you need a person. And second, per customer, you do this over and over. But the big difference is like it's not actually learning. You are learning how to give it better directions until it gets more accurate. And it rarely will get to 100 unless your customer does it the exact same way with very easy and legible formats, which almost never happens. Now, the other category is like machine learning. That is where you have a model that is captive. Just think it's like literally in your company. So it's on your server or on the cloud, but like it's just your stuff. That is where you keep teaching it what not to do and what to do more of, and it learns how to do it better more like a person. So, like machine learning versus AI or agents are very different use cases. And how you connect them to your point very much matters, like guardrails for like a person. Like, I always kind of think of these more like people, because in my head, it's easier for me to picture. It's like this would be like giving a new employee very little instruction and going, you can do whatever you want in the company. Go make decisions as the CEO, the accountant, that broker, this dispatcher, compliance, and HR, have at it and just giving them connections to anything to just go in there and start doing things. You would never do that with a person. But in a computer, people just plug it in without thinking, like, what is it actually connected to? I know you only wanted it to do this, but if it's connected to everything, it might not know what not to do. So telling it what it can't do and what it can do and where and how you connect it very much matters in if it works and if it's creating a lot of unintended consequences and damage across everything. And there's so many articles that come out every week. If you just Google something close to this, you will see examples of large companies that are like, oh my lord, like we just lost all of our data, or oh my lord, like we just lost all of our payroll information, or we didn't realize we just got hacked because we plugged in some open source thing in the back with an agent and it just gave all of our code out to some website and we just didn't know it happened. This is happening everywhere at scale. Because the thing I always think about, the analogy is people go, oh, it's faster, it's better. Those are two different things. Like if you give an experienced driver a race car, he will get there faster and probably safer. If you give a 16-year-old a race car, he is just gonna drive it into a tree and something very bad's gonna happen. You need both of those things for fast to be effective and safe. And like most people are just like, oh, faster is better. Just plug it in everywhere and all this stuff gets done. It's like, no, like that is definitely not how you want to approach implementation of these. And you want to spend time with people that honestly do more of this all day. Like, I spend a lot of time reading about it, but I'm not coding. I can't write code, but like I work with engineers enough that I'm like, hey, explain to me how and what are the unintended consequences, what it can do, why we're doing this, what are the guardrails, what are we connecting it to? And then I'm working from like the person side of it mostly, and they're working from the tech side so that we're making sure it both does what it's supposed to and doesn't do what it's not supposed to do.

SPEAKER_01 15:27

Yeah, that's a good analysis. And I kind of like how you started off with like slow is uh is kind of the the best way to go about it, right? Don't just offload a bunch of tasks or things to something that you don't understand. So in the unit, it's gonna be a big part of the future.

SPEAKER_00 15:45

Big part. Yeah. But it really does remind me of like when you're a teenager and learning to drive a car. Cause like my one of my closest friends, like two doors up, like they were huge mechanics and had really fast cars. Like his dad built a Ferrari and some hot rods. And I'm like, even when I drove them in like a very close setting, like streets, right, where there's no traffic around down the middle of nowhere. Like, as soon as you put your foot on the gas, you start realizing like this is a lot more power than anything I've driven. It's like it scares you. But you don't notice that when you're doing tech because like there's not the physical change in like you moving. So it's it's deceptively more powerful than you probably think it is. And you're just thinking, like, oh, this will just work. And it's like, it's very similar to just a powerful tool of any kind, right? You just give a kid a chainsaw, you probably want to make sure it's a very responsible person, right? Because it can do a lot of help, safe, but a lot of damage in the same way, and you can definitely hurt yourself or your business.

Final Thoughts And Sign Off

SPEAKER_01 16:42

Yep. Good questions. Keep them coming our way, and we'll keep answering them. Final thoughts, Ben.

SPEAKER_00 16:48

Whether you believe you can or believe you can't, you're right. And until next time, go bills.