Episodes / #92

Does Your Company Already Have An AI Champion?

28:15

Most companies fail at AI because nobody owns the messy middle. Armando explains why every business needs an internal AI champion and what the role looks like.

Hosted by Armando J. Perez-Carreno

Show Notes

Armando J. Perez-Carreno argues that most companies are not failing at AI because the tools are weak. They are failing because nobody owns the messy middle between having access to AI and changing how the work actually gets done.

In this solo episode he explains why every small and medium business needs an internal AI champion, what that role really looks like day to day, and how to build a repeatable adoption muscle inside the company. If your AI effort keeps stalling, the gap might be ownership.

Topics Covered

  • Why AI projects stall in the messy middle
  • What an internal AI champion actually does
  • How to pick the right person for the role
  • Building a repeatable AI adoption habit
  • Why ownership matters more than the tool
**[00:00:00]** Most small companies do not need a full AI department, but they do need an internal AI champion. That is the person inside the business who can look at the daily work and say, "This workflow is a good candidate for automation." Or, "This should stay human." Or, "This could use AI, but not yet, because the process is still too messy." Or, "We do not need another tool. We need to document the way this work actually happens." That role is becoming more important than many business owners realize, because AI adoption inside many companies is scattered right now. One person uses ChatGPT to write emails. Another uses Claude to summarize meetings. Someone in finance uses it to clean up spreadsheet formulas across hundreds or thousands of cells. Someone in marketing uses it for first drafts. A manager tried an AI tool after seeing a demo. The founder is asking why the company's not using more AI. And it's just experimentation everywhere, which is okay, but no one owns the system. No one is mapping the workflows. No one is deciding which use cases matter most. No one is writing clear automation briefs. No one is checking whether the outputs are safe, useful, and adopted. No one is turning the best experiments into repeatable company processes or even scale those that these tools can use. And that just creates a strange situation. The company is using AI, but it is not building an AI capability. It is just collecting a bunch of experiments. While some of them might be good, they don't automatically compound. And for AI to compound inside a business, someone has to turn scattered activity into shared learning. That is the internal AI champion. Now, let's define the role carefully. An **[00:02:00]** internal AI champion is not necessarily a programmer. They do not need to be the most technical person in the company. They do not even need to build every automation themselves. They don't need to know every model, every tool, every API, every new feature, and every dramatic headline from X. In fact, if they spend all their time, and this happens chasing new tools, they might be actually worse at the job. The best AI champion is usually someone who understands the work. They know how the business actually operates. So, you might be surprised who this person ends up being. They know where the time is wasted. They know which handoffs break. They know which data is unreliable cuz they see it every day. They know which tasks people hate because they are repetitive and annoying. They know which decisions require judgment. They know which processes are fragile because one experienced person is the one holding them together. They know where the customer feels the delays. They also know where the team is doing manual glue work between systems. And that understanding is more important than being obsessed with tools. Because AI implementation is not a tool problem, and we talked about this. It is a deployment problem. Deployment is the space between having access to AI and actually changing how work gets done. So, most companies have access now. They'll have ChatGPT or Claude or Grok or Gemini or all of them. They'll have AI inside the software they use. They'll have note-takers. They'll have document tools, writing assistants, automation platforms. But access does not equal deployment. Deployment means a workflow changes. A process becomes faster, clearer, safer, or easier to manage. A team knows when to use the AI **[00:04:00]** system and when not to. There's an owner. There are rules. There's a review point. There is a way to measure whether it worked. That is where the AI champion matters. They are the bridge between the business and the technology. And without that bridge, AI stays random. With that bridge, AI can become a repeatable capability. This is not just a nice idea. It solves a real adoption problem. I think it was IBM that reported that limited AI skills and the expertise are top barrier to AI adoption. Accenture reported that 82% of workers said their organizations had not provided training on using generative AI. That is a huge gap. Companies are telling people AI is important, but many are not training anyone to own AI as well. They are experimenting. They're expecting adoption to happen by enthusiasm. And while enthusiasm helps, it is not an operating model. If you want AI to actually improve a business, someone has to own the messy middle. The messy middle is where the tool meets the workflow. It is where the demo meets the real data, like we talked about in the last video. It is where the prompt meets the customer exception. It is where the automation meets the person who says, "That is not how we actually do it." The champion lives in the middle. So, what does that an internal AI champion actually do? First, they'll be the ones to spot automatable workflows. Not every annoying task should be automa- my my automated, mind you. It's I mean, it's a very important to see this. There are places in your stack, in your processes that just should not be automated. Some tasks are annoying because the policy is unclear. Some tasks are annoying because **[00:06:00]** the team lacks training. Some tasks are annoying because the company has just has too many tools. Some tasks are annoying because leadership has not made a decision, and AI does not fix those automatically. The champion has to know how to look for the right kind of opportunity. When is it a good opportunity to use AI? A good first AI workflow is usually usually repetitive. It's something that happens often enough to matter. It has clear inputs and clear outputs. It has a manageable risk. It has a human review point. It saves time or improves quality in a visible and measurable way. It is close enough to a real business value that people actually care. Sales follow-up can be a good candidate. Client onboarding can be a good candidate. Support triage can be a good candidate. Proposal creation can be a good candidate. Weekly reporting can definitely be a good candidate, and internal knowledge search can also be a good candidate. But, the champion should not just say, "Let's use AI for sales." That's just too vague. They should say, "When a new lead comes in, we can summarize the request, check it against our qualification rules, draft the first reply, create the CRM record, and assign a follow-up task. A human should approve the first response before it goes out." That's much better. That is a workflow. Second, the champion maps the workflow before choosing tools. This is one of the most important habits. Tool first thinking, we discussed this in the past video, sounds like this. We bought an AI platform, what should we use it for? Workflow thinking sounds like this. This process wastes 6 hours every week, what is the simplest way to improve it safely? The champion should protect the **[00:08:00]** company from tool first thinking. They're right there in the trenches. They should ask basic questions. Where does this work start? Where does it end? Who owns it? What information is needed for this workflow? Which systems or tools are involved? What gets copied or rewritten or moved? Where do people wait? Where do mistakes typically happen? Which of the decisions repeat? And very important, what does a good output look like? Even what does a bad output look like? What should AI never do here? What requires human approval? Those questions might not be the most glamorous or fun, but they are useful. And useful in this context wins. Third, the champion helps the company become legible. We talked about this in the previous video as well. You want a company to be legible for the AI. And because this is where many of the AI projects get stuck. The company wants AI to write better follow up, but the qualification rules live in the founder's head. AI doesn't know about it. The company wants AI to answer support questions, but the support policies are outdated. AI doesn't know about it. The company wants to AI to help with onboarding, but the process only works because one coordinator remembers every step. The AI doesn't know about it. The company wants the AI to draft proposals, but the best examples are scattered across old folders and not how those which machine and the AI does not know about them. The champion is the one that should notice that. They should ask, "What does this AI need to do the job well?" Similar as if you got a new intern or a new hire, what would they need to be able to do the job well? Then, the champion can help capture it. They'll collect examples, they'll document the rules, they'll be on the ground, they'll ask questions, they'll **[00:10:00]** record decisions, they'll turn repeated questions into reusable answers. They turn expert judgment into checklists. They'll help build the company brain. And the company brain is not a magical all-knowing system, it is just your business knowledge organized so people and AI can use it. Your playbooks, standard operating procedures, policies, examples, the context of your customers, the rules for decisions, your workflows, what you've learned, lessons learned, your standards for what good work looks like. The AI champion does not have to build the whole company brain at once, that would just be asking too much. They rather start with the knowledge needed for the first few workflows. That is practical, just start with that. Fourth, the champion writes clear automation briefs. This is a very underrated skill. A vague AI idea is very hard to build. A clear brief is much easier. And you probably noticed if you've ever tried AI, if you've ever tried prompting. If you give it something very vague, it may or may not give you something close to what you want. But if you're very clear on the expectations, what's going to be the input and the output, and who's going to see it, and how you want to represent it, it's going to do a very decent job of creating what you asked it for. A good explanation explains the workflow. It names the owner. it'll list the trigger, it'll define the inputs, it will describe the outputs, it'll explain the rules, it'll include examples, it will name the tools that are involved, it will include edge cases, we're just doing that this morning, super important. It defines what the AI can do automatically, it defines what the human must approve, it explains how success will be measured, and that brief turns a fuzzy idea into an implementable project. Without the **[00:12:00]** brief, the company is basically saying, "Can someone put AI on this?" That's not enough. The champion's job is to make the request buildable. Fifth, the champion tests the system in the real world. A demo is not deployment. A system is not successful because it worked one with cleaned inputs. It's not the same thing. A real test is whether it works during normal weeks with a normal mess. How does it handle missing information? Does it route the right cases? What to do with edge cases? Does it produce drafts that the team would actually use? Does it create more work or remove work? I just heard this in a comment to one of our posts. Someone said, "Yeah, now I'm stuck going through and rereading all the things that the AI did because it wasn't prompted properly at the beginning or it wasn't given the right context." And we see this time and time again. If companies just start using it and they don't lay the foundation as we're talking about today, it can make more mess and more work for you than what you're trying to remove. Does it break when a field changes? Does it confuse people? And this happens as well, especially ChatGPT. I mean, I'm I'm particular to Claude for some things. I like I understand the way it talks to me. Um my Gemini is fine, too. I hear a lot of people that love Grok, as well. ChatGPT is very good for some things, but when I've asked it certain more complex items, not complex of because of difficulty, because but more when it spans multiple documents and knowledge bases, sometimes the output it creates as what it tells you as an answer is just ridiculous. It overcomplicates the response to make it sound more important or something. And it just doesn't make sense. It is just 10 words **[00:14:00]** to say what could have been said in four. So, you have to also make sure that is not happening so that people reading the documents, someone just told me yesterday some of their teams are using AI now, and then he asked for something, and then they come back with a 38-page document, and now he's he's another AI to parse those 38 pages into something reasonable and easy to understand. So, AI should not be used to confuse or overcomplicate, but rather to simplify. That's the whole point. Now, does it create risk? Does the team trust it? The champion should be close enough to the work to answer those questions honestly. They should not be dazzled by the fact that something used AI. The question is not, is this impressive? The question is, does this make the workflow better? Sixth, the champion helps roll it out. And again, this is where many projects fail. The system exists, but the team does not change the behavior. People keep doing the things the old way. And if you've ever implemented a SaaS or an ERP or something like that, you know this happens. They don't know when to use a new workflow. They don't trust the output. They're afraid of making a mistake. They were never trained. They think this is one more tool to check, and maybe they'll use it, and maybe they don't. So, adoption just quietly dies. The champion helps prevent that. They explain what changed. They train the team. Again, they're on the ground. They show examples. They define when to use the system. They define when to override it. They collect feedback. If people don't like it, if it's not doing what it's supposed to, they improve the workflow. That is change management in plain language. It's not a corporate buzzword. It's just making sure that people actually use the thing that you built. Seventh, the champion measures adoption **[00:16:00]** and results. Did people use it? Did it actually save time? Did it reduce errors? Did it improve response time? Did it make records more complete? Did it reduce repeated questions? Did it make the process easier to manage as expected? Did it create new problems? If the answer is not clear, the project is not finished. AI projects need score cards. Otherwise, people judge by vibes. And the problem with vibes, apart from them being a terrible way to run operations, is that you just recall the most recent ones or the highest experience, whether that's good or bad. You will have the recollection of the one that impacted you the most. And if that's a good thing, you'll love it. And if it's a bad thing, you'll hate it. And if you go by that, then maybe you had an 85-90% success rate, but then you had a very impactful s- little one that made you then think, "Oh, no, it didn't really work out for us." Now, who should be the AI champion? That's an excellent question, and there's no single perfect profile. But, there are some traits to look for. They should be genuinely curious. They should like improving systems and not just computer systems, just systems in general. They should understand the business for sure. They should be trusted by the team. They should be able to communicate clearly. They should be willing to document things. They should be practical, not just excited. And they should care about risk. They should be able to say no to a bad idea. They should be able to work outside with outside experts if the company needs help. And they should be close enough to the operations to see the real pain. Sometimes this person is an operations manager. Sometimes it's a department manager. Sometimes it's a **[00:18:00]** project manager. Sometimes it is a technically curious employee who already is the internal problem solver. Sometimes it is a founder for a short period, but I would be careful with that because founders often start as their champions just because they care about business and they're motivated, but if every AI decision depends on the founder, then the company has not really been built for capacity, and it will become a bigger problem down the line. A better pattern is for the founder to sponsor AI adoption and appoint an internal champion to own the day-to-day process. The founder can set the priorities, and then the champion can map the workflows. The team can provide examples, and then outside experts can help design or build when needed cuz a lot of times you can, with what you've learned, just continue doing things in-house. Then you can, of course, bring in experts and help you with more complex things, but then you're back to doing your own thing. You don't need to depend on a third party for everything because everyone learns from the first and second and third deployment. That's a much healthier model. Now, what should the champion not be expected to do? Well, they should not become the full engineering team overnight. They should not be responsible for every security decision and alone, especially security-wise. If your company or enterprise has specific security guidelines, which they should, talk to a security expert or a security company or because there's there's that part if you have anything privacy-related with health information, you should bring an expert in to help with that part. So, even if you have people internally to help you and create things and not necessarily depend on third parties, you should still be careful with your posture as with any other system. Now, a champion should also not be asked **[00:20:00]** to automate broken profits processes without authority to change them. It might seem simple because they might get access to do some things, but still be mindful, and they should understand the risks involved in automating certain things. So, if they don't have the authority to work with that data normally, then they shouldn't have the authority to operate or automate on that data either. They should not be handed vague goals like "Make us more AI-enabled." They should not be evaluated how about how many tools they have tried. They should be evaluated by whether the workflows improved. That's an important distinction. Trying tools is not the same as building capability. We could just try tools all day, every day, or every week, and we would get no further than we are now. So, the goal is not to have a champion who can name 50 AI products. The goal is to have a champion who can help the company choose the right first few workflows, improve them, and create a repeatable pattern that they can apply in multiple departments. And here's a simple 30-day plan for a new AI champion. Week one, inventory the pain. Talk to team leads. Ask what work is repetitive. Ask where the hand-offs break. Ask what gets copied between tools. Ask which reports take too long. Ask which customer questions are constantly repeating. Ask which decisions depend on one person's memory. Do not collect AI ideas first. Collect workflow pain. Then on week two, you can choose three initial candidate workflows. You can score them on repetition, value, risk, clarity, data availability, and team willingness. Look for a workflow that is painful but still manageable. Do not start with the highest risk process in the company. That'll get you nowhere fast. Start with the **[00:22:00]** visible win. On week three, map the best workflow. Write the steps from start to finish. Name the owner. List the tools. List the inputs. List the outputs. The good inputs, the bad inputs, the bad outputs. Collect examples. Define what good looks like. Define what better looks like. Find out how to measure things. Define whether a human should be required to do any approval. And then on week four, you can write the automation brief. And then, decide the simplest solution. Maybe it's a simple automation. Maybe it doesn't require AI. Maybe it's an AI-assisted drafting workflow. Maybe it is a searchable knowledge base. Maybe it is training. Maybe it is a custom agent later, but not yet. The point is to turn AI adoption into a clear process. And once a company has done up for once, then the second project becomes easier. The champion learns what information is needed. And the team learns how to provide proper examples for this to work. And of course, leadership now learns how to evaluate value, and the company starts building a repeatable AI adoption muscle. That's the real advantage. It's not the tools that matter. It's not an impressive demo that matters. It's a company that knows how to keep finding and deploying the right workflows. Now, this is speaking of medium and large and enterprise companies when I talk about timelines because of all the moving parts and because everyone is busy and getting all the feedback from people might take a little longer. But, this time frame can be compressed dramatically the the smaller the business is or the more documented or legible the company is, especially in a small business or medium business, you might get away with compressing all this into a single week or a couple of weeks where you get the right data, you automate a process, you get the deliverable, maybe the next week you **[00:24:00]** measure, and then you can continue with the next process. So, it doesn't have to take long. Actually, this is all very fast. The problem is people are typically already very busy, and to assume that everything's just going to work and everyone's just going to stop and do what you asked them is is not being necessarily practical your choices. So, just consider that. In some cases, you may have veto power and be able to get everyone to just work, and that's perfect. You can do this in a much smaller time frame because remember AI, once you tell it what you want it to do, it's just going to take seconds or minutes to actually build the thing. It doesn't take days or months. That's the change from when you had to bring an engineering or development team into your company to build something. So, you do not need an AI giant huge transformation program, and you don't need to hire a large internal AI team right away either. You do not need to chase every new platform. Every day there's new ones, trust me. I hear them every day. We're in this and still every day there's three, four, five different platforms, updates and models and everything. If you keep chasing them, you'll never get anything done. But you do need ownership. Without ownership, AI becomes random. With ownership, AI becomes work improvement. So if you're founder or operator, ask yourself this. Who inside our company is responsible for turning AI from experiments into workflows? Who is mapping that deployment gap? Who is helping make our company knowledge legible to the AI? Who is deciding which automations are worth building? Who is writing the brief? Who is training the team? Who is measuring adoption? And I have to stress this a little bit because many times people think this falls on the IT department and that is not **[00:26:00]** necessarily the case because the IT department, while they're extremely necessary for any integrations and APIs and connections to your different tooling and security posture, etc., they have to be in the mix, but the AI champion does not have to be part of your security of your IT department, but rather they have to be the ones close to the action that know what actually is happening day-to-day in the business. So if you do not know who that person is right now, then you have to start figuring out who it is or if you have to bring someone in to become that person. And if you are the person inside your company who already sees these opportunities, this may be your role. You do not have to know everything. You do not need to be an expert in all these things, but they do need to learn to ask the right questions. You do need to understand workflows, and you do need to care about practical value. You need to help the company move from random experimentation to repeatable deployment. That is what an AI champion does. They turn curiosity into capability. They turn tools into workflows. They turn hidden knowledge into usable context that the AI can use. And of course, they turn all these scattered experiments into a system that the company can improve over time. If you want to know whether the company has the right person for that role, check our website to see if we already have the champion readiness quiz. It will help you identify who should own AI internally, what skills they already have, and what they need to learn next. And if that quiz is not yet live, take our AI automation opportunity map, which will show you which workflows are worth improving first, where your team may need training, and where AI adoption is likely to get stuck. Because **[00:28:00]** the future of AI in small businesses does not belong to the company that tries the most tools. It belongs to the company that has someone who can turn tools into repeatable work.

Follow the show

New episodes land here first. Subscribe on the platform you already use so you do not miss the next one.

More episodes like this