AI in Action
Welcome to AI in Action, where we explore the latest in artificial intelligence and what it means for your business. Each episode delivers sharp insights, breaking news, and real-world strategies to help you prepare for AI and put it to work.
AI in Action is brought to you by Fast Slow Motion. Our team helps growing businesses put AI to work with practical, scalable solutions. To learn more about how we can help you implement AI in your business, visit fastslowmotion.com/ai.
AI in Action
How AI Automates Invoice Processing in Salesforce
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
Many growing businesses hit a point where success creates new operational bottlenecks. In this episode, Eric Housh and Zack Terry break down the “scaling tax” and how AI can eliminate manual invoice processing inside Salesforce.
They walk through a real-world use case, including how Agentforce automates email intake, data extraction, validation, and record creation, plus practical steps leaders can take to identify similar opportunities in their own workflows.
Prefer to watch? Find the full episode on our website: https://loom.ly/x3x9-G0
AI in Action is brought to you by Fast Slow Motion. Our team helps growing businesses put AI to work with practical, scalable solutions. To learn more about how we can help you implement AI in your business, visit FastSlowmotion.comslash AI. Welcome back to AI in Action. I'm Eric Kush, joined as always by Zach Terry. Today we're talking about a classic growth challenge, the scaling tax. It's that point where a company's success actually starts to penalize them because their back office processes can't keep up with their front office growth.
SPEAKER_00That's right. I think this is a scenario that many business leaders or even just employees that work in a scaling business will recognize. And so in this sort of specific story that we'll talk about today, this business, an industrial logistics company, so already, I mean, you're talking about a lot of different things that they're tracking, right? And a lot of dependencies that they have to work with. They were looking to continue to grow and significantly increase their production capacity, but they had this major bottleneck, and that was their invoicing process. And I'm sure a lot of businesses out there will resonate with this, but that process was almost entirely manual. So you're talking about emails coming into people's inboxes that include attachments and having to look through those attachments and determine what's in there and probably go and extract that information and put it into a system of record. And so a lot of manual steps that go into that process. And they had spent a lot of time evaluating potential automation tools that could help them. They'd spent years sort of looking for the right tool and experimenting with different tools. Obviously, they'd spent money, not just time, but actual money experimenting with these tools. And they never really found a solution that worked for their specific invoicing workflow and the way that they happen to do business and communicate with their customers. And the breakthrough really happened when our team was able to connect the dots between that specific pain that they had and a solution that we had already proved internally.
SPEAKER_01I think it's worth staying there and highlighting that for just a moment about how this solution came together. This wasn't a case of a client saying, hey, we need XYZ AI tool. It was about our team being positioned to really identify and see this opportunity that maybe the client hadn't even considered yet.
SPEAKER_00For sure. I think it really comes down to a couple of things. One, our internal culture of documentation is really big. But then also our consultative approach at Fast Low Motion is to really listen and understand business problems and then to help align solutions to those problems, as opposed to taking a solution directly to a problem or trying to find problems that fit a solution. So in this scenario, talking about our process internally, our architect team is really good at creating blueprints of specific solutions. So anything that we're building or solutions we've built for clients, ways that we can essentially prevent having to reinvent the wheel when we experience something similar with another client down the road. So let's let's say an expense report agent that we built out to develop handling receipts. That was a really good blueprint for this specific problem with invoicing because it's doing something very similar. It's taking a file, extracting information from the file, and then automating the process from getting that information out of the file and into a system of record, in this case, the Salesforce CRM. So during this project, we had our lead architect, Brad. He really heard and understood the problem from the client's perspective. And of course, he's been embedded in this project for months, probably even years. This is a longtime client that we've worked very closely with for a long time. And it was sort of casually mentioned on a regular call, the frustration that they have had with this manual invoicing process. And because he was aware of some of the work that we had been doing with Agent Force and this specific solution that we had prototyped, which wasn't even really something that we had implemented directly with a client. It was sort of an internal working proof of concept that we used to say, can this be done? Okay, yes, it can. And here's exactly how to do it. He recognized that problem and he was able to translate it to the blueprint and adapt it to the specific business process. So he was able to say, hey, I think we can repurpose this logic, this blueprint to solve this exact problem. So it was, it was less about selling a feature and saying, hey, you need to buy this product and we can turn it into that. And it was more about saying, hey, I think we have a plan for exactly how we can tackle this. This is what it would look like. This is how we can recognize us as a potential solution to that problem, because it had already existed in our ecosystem and we already had essentially the framework to go out and tackle that so that it could help them with this whole invoicing process.
SPEAKER_01So let's stay there for just a minute, Zach, and talk more about that manual bottleneck. There's a lot of folks out there right now that probably have their antennas up going, wait a minute, this sounds vaguely familiar. Let's let's break down what that bottleneck looked like for them.
SPEAKER_00So at a high level, it's a high volume and repetitive cycle. So two sort of keywords there where AI can probably come in and help. And not just AI and automation in general, but anytime you have something that's really high volume and really repetitive, it's probably going to be a strain on your employees. It's going to be a strain on the amount of time that you have to spend doing something. And it's a really great opportunity for some kind of optimization. And so in this case, we have three specific pillars that we identified in this process. One is the inbox. So this is how they are actually receiving invoices. People are emailing them in. So they're receiving attachments inside of an email that contain files. And these can be PDFs, they can be doc files, they can be in different formats. They're not always the same because it's a client that is sending it in. They have their own format. And so it's different from client to client, right? So that's the first piece, the inbox. A lot of variability, a lot of attachments. So then the second piece is the extraction of that data. Somebody actually gets that email in their inbox. They recognize that the attachment is an invoice. Maybe the subject line says invoice, maybe it doesn't. So that's the whole piece with this manual review. You've got to go into the inbox, you got to open the email, you got to see what's actually in that email. And then if it has an invoice, a team member has to actually open up the attachment, see what's inside it, and then key that data into a system of record. So we're talking about Salesforce. And so in this case, it's okay, I've got to go ahead and take that information, got to get it into Salesforce so that we have record of it and so we can act on it, right? So that's the second piece. And then the third piece is actually validating that the information is correct. So cross-referencing the data in the invoice against what the actual shipment records say, the information about the customer, about the client, making sure that everything is up to speed and entered accurately. And so all of that combines for multiple minutes for any given email that contains an invoice that a user is having to go through and actually spend time processing and entering this data into the system.
SPEAKER_01So the company's very successful, they're growing, but that growth is coming now with a linear path that is manual effort to handle these business processes. Uh, how did AgentForce help with that?
SPEAKER_00I love what you said. I mean, to be clear, it's a good problem to have, right? You want to be getting more and more and more invoices, right? That's a really great sign that the business is growing. But yes, it's a bottleneck, it's a problem. You've got to create systems and processes that can help streamline that, which is where we were at with this customer, right? This was their pain point. So what we recognized is that this specific solution that we had proved previously and documented in our own process was a really great candidate to solve this solution. So, so or to solve this problem, I should say. So, what was the solution? It is an agent force agent that has the ability to do essentially three things, but there's more to it when you get into the process. Um, but the agent itself is going to take an invoice file, it's going to send that information off to a large language model with specific instructions on what to do. The instructions are going to be to extract the key data points from that file and then map it to a structured output that we can use to reliably update that data in Salesforce. And so what it really looks like is an email comes in. Some process has to understand when an email is an invoice. It has to understand if there is an attachment. It has to take that attachment and it has to write it to somewhere inside the CRM. And then we have to be able to pick up the fact that we received an invoice. And then that agent has to pick it up, analyze the file, extract the information, have the large language model process it, put it into a structured output. Then we have to take that structured output and we have to analyze it and take the individual pieces of data. In this case, it's JSON. And so we have a structured JSON format with specific key value pairs. We're taking all of that and using deterministic automation, in this case, an Apex class, that can reliably parse that information and then create records from it. So it's identifying that there is an invoice, it's extracting the data from that invoice, it's mapping the output in a structured format directly into Salesforce records. And then it is validating that the invoice information is correct against the information that we have in the system. And so it's really that entire process that you would have to run in a manual motion when you receive the email for the first time and automating it all the way from beginning to end. How we automated it is a mix of deterministic automation and large language models. And it's kind of a large language model that's bookended by two deterministic processes. One is the automatic routing of the email and identifying and loading that document into the right place. And then at the other end of it, it's taking a structured output and creating something from that structured output.
SPEAKER_01Zach, I hear you and the smart guys at FSM caution all the time about over-engineering solutions. How did our team approach this implementation?
SPEAKER_00I mentioned it a little bit at the beginning, but this was a problem-first approach over anything else. So first and foremost, this was us having the ears to listen and understand the problem from the experience of our client. And so this wasn't us going and looking for a specific opportunity to insert a technology. It was us listening and hearing and understanding that there was a pain point and then saying, hey, I think I have a way to solve this. And we've done it before. Let's let's experiment, let's explore, let's see if this would be valuable. And so if we kind of strip it back, the very first thing we had to do even before we understood this problem from the client is we had to develop a prototype. We had to actually have this proof of concept in place so that our team was aware of it and then would be able to identify when that solution aligned to a specific problem, right? And so because we had that proof of concept, not only the idea of it, but the actual documentation on how to replicate it, our architect Brad was able to recognize the opportunity to actually solve a problem using this solution. So then we kind of move into the integration phase. We proved that this actually worked. We, with the client's permission, moved into a proof of concept phase to take our sort of skeleton and prototype and adapt it to their specific problem in their specific business context. And we didn't build the whole solution. We didn't build the email automation and the parsing or any of that. What we did first was we said, okay, let's assume that everything's in place. We've got the file in Salesforce, and we're ready to have an LLM go and extract it and produce an output. That's the piece that we built to prove that it could work, right? And so then what we were able to do is demo that solution to the client using some example invoice records and say, hey, check this out. Like if we have this, here's what can happen when you get an invoice and here's the output that you can get. And they loved it, right? Once they were happy with just the proof of concept, they could see the potential of automating the entire solution end to end. And so only once we had proved that this AI-based solution could actually give them the results that they wanted in an ideal scenario, then we started thinking about the automation on either side of the large language model. So that's where we were able to connect the ability to route the email to the right place and extract the file, and then the ability to take the structured output and actually write that to actual records and data inside the CRM. So the main sort of takeaway there is we were able to start small and prove the solution first in a sort of a microcosm way, right? Just prove that it will actually do what you want if everything else is aligned. And then because the client was able to see the value, then we were able to move past this sort of proof of concept stage into an actual development cycle and create a full end-to-end automated solution with AI in the middle.
SPEAKER_01Zach, for those leaders out there listening to this episode, thinking about their own manual processes that they should be uh considering some AI solutions for, what's kind of their next step here?
SPEAKER_00We've mentioned this before, uh, but it's really about recognizing those repetitive, redundant, high volume processes. And in some cases, just thinking about the things that either you or your employees probably dread doing. I don't think anybody wants to scan an inbox 20 or 30 times a day to go and find these invoices and manually key that information in, right? Not only is it a bottleneck, but it's also just not enjoyable. It's grunt work, it's things that you don't really want to do, right? And so if you kind of think about that as uh the human middleware problem, where do we have to have people act as a bridge between some beginning and some end? It's not right for everything, right? But if you've got this highly repetitive, high-volume process that AI can essentially take the place of that middleware and run that process for you. In this scenario, we had a few opportunities. The inbox is a huge piece of that opportunity. You spend hours and hours downloading, rekeying that info. That's a great starting point for this process, right? We're able to say, okay, if if we're able to just identify this when it comes in, as opposed to having to have somebody scan their inbox and do the right thing when they've identified it. Let's take that sort of variable out. And let's just say, okay, you know what? I've I've now got a dedicated place where we know when an invoice comes in and we flag it and we recognize it, and then it automatically gets put into the right place. That's a huge opportunity in and of itself. Even if you still had to have someone go and go into Salesforce and key the information in, you've already cut that process in half, which is going and trying to grab it from the inbox and then translate it over to the CRM. But then you go beyond that and you say, okay, how can I take the process from needing somebody to read that invoice and manually key the information and have AI do that for us with a process at the end that automates the entire process? That's a huge value add. So then the other piece of this is thinking about just the value of having the right people in the room when these problems surface. And so in this case, it's the value of an architect. An architect being someone who really understands the technology and the platform and the systems and how everything works together and having the opportunity to understand a problem and then think about how that architecture can be essentially crafted in a way to meet that specific problem, right? You really have to have that systems thinking in place to map the entire workflow. Because it really is kind of a complicated workflow when you really think about all of the automation and everything that has to work together. And so that's really about having the right people on the team or a partner in this case, right? We were able to partner with this client to identify this particular solution to this problem. And it's it's about going beyond just building what you're told. What we say is uh we aren't order takers, right? We're truly consultative. And so instead of saying, hey, I need to build this specific thing, it's really zooming out, taking a step back and saying, okay, let's look at the problem and then figure out the best architecture to solve that problem rather than jumping straight to what we think is the right solution. And this was a great example of having the right person in the room to map that specific problem to the right solution. And then the last piece here is designing for exceptions. And so not trying to build a system that's 100% hands-off. We talk about this as you know, having a human in the loop when we're talking about AI solutions, but uh really it's building something that allows you to handle 90%, and then the other 10% can be quality control. And so in this scenario, we have a full audit trail of every single thing that happens. And so not only are we accomplishing the workflow from email to file to extraction to writing data, but in addition to actually creating the records, we have an audit record that is created for every single transaction that says, this is what the input looked like, this is what the structured output looked like, this is what we mapped it to. It can identify exceptions in terms of, you know, we got this invoice, but we couldn't find a matching email address. Maybe this is a new customer. You can flag that for human review so that you can go and determine if maybe you're getting an RFP instead of an invoice. And so you need to do a little bit more, you know, work around the edges there. The important thing is identifying those exceptions when they happen, flagging them, reporting them, and giving your team the ability to go and act on those.
SPEAKER_01Awesome. Key learnings there. Let's talk about what those leaders can do this week. What are some few for a few practical steps they can take for work?
SPEAKER_00So, first is identify what we're calling the re-keying tax. Ask your team where they are manually moving data from an email or a document into the CRM. So it's any anytime where you're having to scan something visually and then mapping that information over. There's a lot of tools out there that can solve for this. But AI is a really great tool that's able to understand the context of what's going on, not only inside the document, but also in your business process so that it knows what it's looking for and how to extract it and where to map. Which leads into the second piece: map your workflows. Trace the data. Where does it come from? Where does it go? Where does the context live? Is this something that always requires a human judgment call? Or is it just somebody who is keying in the information? Is this a data entry job, or does it truly require strategic thinking? And if it's just data entry, it's a great opportunity to automate that process. And then the third piece here is to test that concept. So if we're talking about this document solution, take some of those documents, maybe anonymized examples, right? Before you send any data to an LLM, you know, obviously check your governance policies, have all of that in place. But assuming that you are following those policies, take an anonymized version of that document, you know, maybe three or four or five of those documents, run it through a tool like one of these LLMs and see what the output looks like. And then you can you can quickly validate if it's gonna be able to do what you need. And also experiment with different models, right? Uh a fast model like Google Gemini, a fast version is probably not gonna be as good as a pro version. So instead of using Flash, maybe we need to use a thinking model or we need to use Pro 3.1, whatever that may be, you're gonna get different results depending on the model. And so it's worth just testing to see. And also it's a cost consideration, too. Using the latest Pro 3.1, 3.2, whenever that comes out, that's going to be more expensive than using a Flash model or a quicker model. And so if you get the same or nearly the same results using the fast model at a fraction of the cost, that may be good enough to move you across the finish line, as opposed to spending a lot of money per transaction on the latest and greatest model.
SPEAKER_01Zach, the thing I love most about this project and this story is this is what happens when preparation meets opportunity, right? There's no magic tool, magic bullet out there. It's about having a team that's going to recognize the business need and then having the framework to be ready to jump in there and solve it. So for anybody out there listening, if you're feeling this, the scaling tax in your back office, or if you just know or have it have an inkling that your business could run more efficiently with tools like AI, we would love to help. We'd love to have a conversation. Visit us at fast slowmotion.com slash AI. Zach, any final thoughts?
SPEAKER_00Just focus on that problem first. Take that problem first approach. Identifying and fixing that problem should come before a solution. And then I think usually the solution reveals itself, right? And especially when you talk about preparation meeting opportunity. If you've prepared by validating concepts and creating proofs of concept that you can use later on, that's when you can identify a problem and map it to a specific solution. Thanks a lot, Zach. Thank you, everyone. See you next time.