# How to Run the Perfect AI Implementation
Canonical: https://social-archive.org/tgroenwals/5MmuWPd1OC
Original URL: https://x.com/lukepierceops/status/2093413799646896231
Author: Luke Pierce
Platform: x
Share mode: full
## Content
Running an AI implementation is one of the most overwhelming projects a company can take on. It's also nearly impossible to fail if you follow the right process. That sounds like a contradiction, but after four years and more than 90 automation and ai implementations, I can tell you the overwhelm and the failure both come from the same place: attempting the project without a process. This article lays out ours in full. For context, I'm the founder and CEO of @boomautomations. We build custom AI operating systems for companies ranging from $2M service businesses to $100M+ operations, and everything below reflects how we actually run these engagements, including the terminology we use internally and the details most providers don't publish. Last week I did 14 consultations with companies interested in working with us, and almost every conversation followed the same pattern. Here's what those calls sounded like. The founder or CEO gets on the call already convinced that AI matters. A few people on their team use ChatGPT for emails and summaries, someone pushed for an AI strategy six months ago that produced a document and nothing else, and the company is running somewhere between 15 and 25 software tools. The real operational truth of the business lives in a spreadsheet one person maintains, a CRM that's roughly 60% accurate, and the memories of two or three employees who can never take vacation at the same time. Meanwhile, their best people spend 8 to 15 hours a week re-entering data, chasing statuses, and rebuilding the same reports. When I ask what they want to build, the answer is almost always some version of "we don't know, that's why we're talking to you." That answer reveals the actual problem. These companies don't have a building problem. They have a knowing-what-to-build problem, and the reason they can't answer the question is structural. It's buried in how their operation stores and moves information, which brings me to the first concept you need to understand. ## Data silos: why nobody can answer "what should we automate?" A data silo is any place where operational information lives that other systems can't see. Your CRM is a silo, your project management tool is a silo, and the spreadsheet your ops manager built in 2021 that the whole company quietly depends on is usually the biggest silo of all. Silos don't form because anyone made a bad decision. They form because every department solved its own problem with its own tool at a different point in the company's growth. Sales bought a CRM in year two, operations adopted a project management tool in year three, and finance has run its own system from the beginning. Each purchase made sense in isolation. Five years later, the same client exists in six systems with six slightly different versions of the truth, and no one ever decided that on purpose. The cost of this shows up in four patterns we find in nearly every assessment we run. The first is re-entry. The same information gets typed by hand into two, three, or four systems, and every entry is an opportunity for a typo that becomes a downstream problem someone spends an hour untangling. The second is version conflict. When two systems disagree about a client's status, a person has to stop what they're doing and determine which one is correct, and that reconciliation work repeats across every client, every week. The third is reporting lag. Leadership questions that should take thirty seconds to answer take two days, because answering them requires someone to manually pull from four sources and reconcile the differences. The fourth is tribal knowledge. The most important system in the company turns out to be the memory of a few tenured employees, which means the operation stalls when they're out and breaks when they leave. Here's why this matters for AI specifically: AI makes silos more dangerous rather than less. An AI agent operating on partial context won't tell you it only has a third of the picture. It will produce a fluent, confident answer built on a third of the picture, and fragmented data fed into AI generates polished mistakes at scale. In some ways that's worse than the manual chaos you started with, because the manual version at least announced itself. This is why you can't skip straight to the interesting AI work. The silos have to be found, mapped, and consolidated first, and that's exactly what the first phase of a proper implementation exists to do. ## Phase 1: The Current State Assessment Every engagement starts with what we call the Current State Assessment. It takes a minimum of two weeks, and there is no way around it. Any provider who tells you otherwise is planning to build the wrong thing. The reason it's non-negotiable comes down to a simple reality: you cannot design a system for an operation you don't understand, and no founder fully understands their own operation. That has held true at every company we've ever assessed, and it isn't a criticism of founders. Every business has two maps. There's the founder's map, which describes how the business is supposed to run, and there's the floor map, which describes how the work actually gets done, including every workaround, every unofficial spreadsheet, and every extra step that exists because of something that broke in 2022. Systems designed from the founder's map struggle with adoption because the team can feel the mismatch immediately, while systems designed from the floor map get used, because they match the work as it actually happens. The only way to get the floor map is to go collect it, and here's how we do that. Stakeholder interviews We interview across the company for 60 to 90 minutes per person, with a minimum of one person per function. Critically, we interview the people who do the work and never limit ourselves to the people who manage it. The ops manager and the coordinator underneath them will describe the same process differently, and the coordinator's version is the accurate one. The interview runs as a walkthrough rather than a survey. The core questions we work through: - Walk me through this process from the very beginning to the very end, including the steps that feel too small to mention. - Where does information come from when you start, and where do you send it when you're done? - What do you type or copy by hand more than once? - Where does work sit and wait, and who is it waiting on? - What do you double-check before you trust a number in a system? - What workaround have you built that nobody officially knows about? - If volume doubled next quarter, what would break first? That last question consistently produces the most valuable answer of the interview, because people know precisely what would break first. They work next to that weakness every day, and in most cases no one has ever asked them about it. The live interviews are followed by asynchronous follow-ups, because people reliably remember the important details two days later: the step they forgot, the spreadsheet they didn't mention, or the exception that happens "only sometimes" and turns out to represent 20% of cases. The silo inventory In parallel with the interviews, we catalog every place data lives. That means every tool, every spreadsheet, every shared drive folder, and every inbox that quietly functions as a database. For each one we document what it holds, who writes to it, who reads from it, what it overlaps with, and what it costs per month. Companies are consistently surprised by two numbers here: the total count, which typically lands between 15 and 25 tools, and the monthly spend, which routinely runs into the thousands, with a meaningful share of it going to software used by one person or by no one at all. Pain quantification Every bottleneck we identify gets a number attached to it, and never an industry average. We use their numbers, pulled from their operation. The math itself is straightforward. Hours per week spent on the manual work, multiplied by the loaded cost of the people doing it, multiplied by 52, gives the annual labor cost. On top of that we add the error side, meaning what a mistake costs when it happens multiplied by how often it happens, and the throughput side, meaning the deals that stalled, the projects that were delayed, and the capacity the team couldn't take on. Once a bottleneck carries a verified dollar figure, prioritization stops being a debate. When leadership sees that a single re-entry loop is costing $40,000 a year in labor, the conversation about what to fix first tends to resolve itself. The blueprint The deliverable at the end of the assessment is a single document containing, in order: the full process maps showing the current state visually with every step and handoff, the silo inventory, the quantified pain list, the automation and AI opportunities ranked by projected ROI against build complexity, the proposed future-state architecture, and a phased implementation plan with budget ranges. The ranking matters more than the raw list. Generating forty automation ideas is easy, and the actual value lies in knowing which six matter, which three come first, and which ten sound impressive but would return very little. Two things happen during this phase that matter more than the document itself. The first is that the company sees its own operation clearly, in most cases for the first time. Very few executives have ever looked at a visual map of how their business actually runs, and the near-universal reaction is some version of "I didn't realize we did it that way." That moment alone tends to justify the assessment fee. The second is that we measure what we call engagement signal, and it predicts everything that follows. How a company behaves during the assessment is how it will behave during the build. Strong signal looks like stakeholders arriving at interviews prepared, follow-ups answered within a day, and people volunteering pain points without prompting. Weak signal looks like rescheduled interviews, one-line answers, and a founder who wants to skip ahead to a demo. We've learned to treat weak signal as a disqualifier, because engagement during the assessment is the single best predictor of whether a company will adopt what gets built, and a company that treats the assessment as a formality will let a $50,000 system sit unused regardless of how well it's engineered. One more point on this phase. If a provider offers to audit your business in a single 45-minute call, what you're receiving is a sales presentation. A meaningful assessment of a company's operations cannot be completed in that window, and the two-week minimum exists because the interviews, follow-ups, and mapping genuinely require it. ## Phase 2: Solution Architecture Once the current state is mapped, we design the future state, completely and on paper, before anything gets built. This phase is where implementations are won or lost, and it's also the phase most providers skip, because architecture is invisible work that never gets screenshotted. It is, however, the difference between a system that lasts three or more years and one that quietly degrades within a few months. The data model comes first Before screens, before automations, and before agents, we design the schema. That means identifying the core entities of the business, whether those are clients, projects, orders, jobs, properties, or patients, then defining what fields each carries and how they relate to one another. Then we apply the rule that eliminates silos permanently: one write path per entity. Every piece of data has exactly one place where it gets created and one path through which it gets updated, and everything else in the system reads from that source. The moment two systems can both write the same record, you've rebuilt the exact problem you paid to solve, just on newer software. Deciding between automations, agents, and humans Adding AI indiscriminately is a common failure pattern, so every piece of work in the future state gets classified into one of three categories. Deterministic work gets an automation. If the rule can be written down completely, such as "when a form comes in, create the record, assign the owner, and notify the channel," it belongs in an automation with no AI involved, because none is needed and adding it would introduce cost and unpredictability into something that should run identically every time. Judgment work gets an agent. Reading an inbound email and determining what kind of request it contains, drafting a document from context, answering a question against the company's knowledge base, and similar tasks involving interpretation or generation belong to agents. Decision work stays with humans, with the system doing the preparation. Approving a quote, accepting a client, and pricing an exception remain human calls, but the system assembles everything needed to make the decision and presents it, which turns a forty-minute research exercise into a one-minute review. A meaningful share of what companies assume requires AI turns out to be deterministic, and that discovery alone frequently reduces the projected complexity of a build by a third. The Implementation Decision Tree Implementation is widely misunderstood as synonymous with building from scratch, and it isn't. Every tool and process from the silo inventory runs through a decision tree with three possible outcomes. The first outcome is absorb. The tool performs a function the new system should own, so that function gets rebuilt into the operating system and the tool gets cancelled. Project management tools, form builders, internal trackers, reporting add-ons, and most software purchased to bridge a gap land in this category, and it's where the bulk of the SaaS consolidation savings come from. The second outcome is keep. The tool is genuinely excellent at its job and worth connecting to rather than replacing. Accounting software almost always stays, as do email, calendars, and industry-specific systems that carry regulatory weight. The operating system integrates with these and becomes the layer that makes them behave like one system. The third outcome is kill. The tool is redundant, barely used, or duplicating something else, so it gets cancelled with no rebuild required, and in our experience no one notices its absence. Running every tool through that tree effectively scopes the build on its own. Companies frequently arrive expecting a scorched-earth rebuild and leave relieved, because a well-designed implementation deletes more than it creates. Gated sequencing The final piece of architecture is sequencing. The build plan is structured as a series of gated phases, where each phase has a defined completion standard and the next phase doesn't begin until the previous one meets it. The database doesn't get automations layered onto it until the schema is stable, and agents don't go live until the workflows they depend on run cleanly. This approach looks slower on paper and proves dramatically faster in practice, because the team never builds on top of something that's still moving. ## Phase 3: The Build The build runs on a set of principles refined across more than 90 implementations, and they don't bend. Foundations come first. The opening weeks belong to the database: tables, relationships, permissions, views, and the single source of truth. This is the least visually impressive stretch of the project and the most important one, because everything else depends on it. Clients understandably want to see agents in week one, but durable systems begin with schema in week one. Workflows come before intelligence. Automations follow the database, covering intake, routing, approvals, notifications, and status changes, which together form the plumbing that moves information without human involvement. Agents come last, deployed on top of clean workflows and clean data. An agent reading from a well-structured database with defined workflows behaves reliably, while the same agent placed on top of a disorganized operation produces fluent output built on incomplete information. The one-write-path rule gets enforced in code. Every automation that writes data validates against the schema, which means bad data gets rejected at the point of entry rather than discovered and cleaned up at the point of reporting. Progress stays visible daily. Every active build has a shared channel where the client sees working demonstrations every single day, whether that's a functioning form, a new view, or an automation running on real test data. We show working items rather than status updates, because this practice eliminates the classic agency failure mode in which the client pays, hears nothing for six weeks, and receives a big reveal that misses the mark. When the client watches the system grow daily, course corrections happen within hours and confidence builds steadily over the length of the project. Check-ins run on a defined structure. On top of the daily demonstrations, we hold structured calls on a set cadence, and the calls themselves follow a process: an internal preparation session beforehand, an agenda sent the day before, a live call organized as recap, demonstration, feedback, and next steps, and a same-day written summary documenting decisions and owners. The structure is repetitive by design, and it's a large part of why clients trust us with the next department after the first one ships. Everything gets built for the handoff. Each system is constructed and documented as though someone else will manage it tomorrow, with naming conventions a stranger can follow, documentation written for a new hire, an administrator guide, and troubleshooting steps. A system that only works because the person who built it remains on call was not built correctly. QA runs against realistic conditions. Before anything ships, it gets tested across four categories. Technical integrity covers whether the workflows, triggers, and permissions do what they claim. Edge cases cover missing data, bad formats, duplicates, unusual inputs, and volume spikes. User experience covers whether a typical team member can operate the system without documentation open in another tab. AI behavior covers whether agent outputs are consistent, accurate, and properly structured, verified against a test set before real work depends on them. Systems rarely fail under normal conditions, so the unusual conditions are precisely what we test. ## Migration: the step everyone overthinks At some point the company has to move from the old way of working to the new one, and this transition ends more implementations than any technical problem does. Companies tend to fail here in one of two directions: they either commit to a heroic full migration nobody actually needed, or they never commit to a switch date and end up running two systems indefinitely. There are three viable paths, and the characteristics of your operation determine which one applies. The first is the full migration. Historical data gets cleaned, mapped to the new structures, and backfilled. The team then runs both systems in parallel for a defined window, typically a week, doing real work in the new system while the old one remains available as a safety net. After that comes a dated cutover, followed by a period of read-only access to the old system before it's retired. This is the right choice when historical data is operationally critical, such as client history a support team references daily, records that feed compliance requirements, or financials that drive reporting. It's also the most expensive path, and it gets chosen by default far more often than it should be. The second is the cutover date, which involves no mass migration at all. You pick a date, and every new project, client, or order from that date forward lives in the new system, while everything already in motion finishes out in the old system, which empties itself naturally and then gets cancelled. The logic becomes clear with real numbers. Suppose your average project runs 60 days. A full migration would mean weeks of cleaning old records and mapping them into new structures, and you'd be paying for that work on projects that will close within two months regardless. Setting a cutover date instead means that within a single project cycle, the old system holds nothing active and the new system holds everything, and the migration completed itself while everyone simply did their jobs. The third is the hybrid, which is what most companies actually need. Reference data migrates, meaning clients, contacts, vendors, and catalogs, since those records have a long useful life. Transactional history does not migrate, so old projects, tickets, and orders finish out in the old system or get archived with read-only access. This provides continuity where continuity matters while avoiding the expensive backfill where it doesn't. The decision comes down to two variables: how long your work cycles run, and how frequently your team genuinely reaches into historical records during daily work. Short cycles combined with rare lookups point to the cutover date, while long-lived records and daily lookups point to the full or hybrid approach. The choice gets made during the architecture phase, in writing, and never improvised in the middle of a build. Whichever path applies, two rules hold. The switch date gets communicated to the entire team weeks in advance, with training delivered before it arrives, so that no one gets surprised into a new system on a Monday morning. And the old tools actually get cancelled on schedule, because a backup spreadsheet that stays alive will quietly become a competing system within a month. ## Phase 4: Handoff and Adoption Rate A system nobody uses is worth nothing regardless of how well it was built, so this phase receives the same rigor as the build itself. The handoff includes a full walkthrough with leadership and role-based training, meaning the operations team gets trained on their workflows and the sales team on theirs, so that no one sits through two hours of features they'll never touch. Sessions get recorded so the training survives staff turnover, and the documentation and administrator guide assume the reader has never seen the system before. From there, we track one metric above everything else. Adoption Rate is the share of mapped workflows actually running through the new system, with the team working inside it rather than around it. High adoption has a recognizable character. Data flows without anyone chasing it, the old spreadsheets fade from neglect, and, most importantly, people begin trusting the system's answers. When someone has a question about a client or a project, they check the system, find it accurate, and check it again the next time, which is how confidence in a system accumulates. Low adoption has an equally recognizable signature, and the first 30 days after launch are when to watch for it: the shadow spreadsheet. Someone quietly maintains their old tracker as insurance, and if that goes unaddressed, within a quarter the shadow spreadsheet becomes the real system again and the build becomes an expensive interface sitting on top of it. We treat every shadow system as diagnostic information, because it means either the person wasn't adequately trained or the system genuinely doesn't handle their case, and both problems resolve quickly when caught in the first month. This is why we remain actively involved through the first month after launch, watching usage rather than disappearing the day after training. When adoption comes in low, the cause almost always traces upstream to a skipped or rushed assessment. A system designed around how someone assumed the business works, rather than how it actually works, produces a mismatch the team feels immediately, and they respond by routing around it. This is also why engagement signal in Phase 1 carries so much weight: adoption gets decided in the first two weeks of the engagement, when the team either becomes invested in the system or doesn't, long before handoff arrives. When Adoption Rate is high, the ROI takes care of itself. ## Phase 5: Maintenance, optimization, and feedback loops An operating system is a living thing. The business changes, volume grows, edge cases emerge, and the team turns over, and the system has to evolve alongside all of it. This phase is what separates systems that last three or more years from systems that quietly deteriorate. Ongoing optimization runs on four feedback loops, each with concrete mechanics behind it. The first is usage data. The system logs everything, which means we can see which workflows run cleanly, which ones produce errors, and which features get used daily versus ignored entirely. The ignored features carry information of their own, because anything the team routes around is something that doesn't fit how they actually work, and the data surfaces that long before anyone files a complaint. Actual usage is a far more reliable guide to improvement than anyone's opinion about the system. The second is error monitoring. Every automation writes a log, and when something fails, it fails visibly: an alert fires, a human sees it, and the issue gets resolved, in most cases before the client's team notices anything happened. The dangerous failure is the silent one, the automation that stopped running three weeks ago while everyone assumed it was working, and logged, monitored systems don't produce silent failures. The third is the review cycle, a recurring structured review held monthly or quarterly depending on the engagement, with a standing agenda covering what ran cleanly, what produced errors, what changed in the business, and what should be built next. This is where expansion originates. The first system proves itself in one department, and the review is where the next department, the next workflow, and the next agent get scoped. Every multi-year account we hold began as a single build paired with a review cadence. The fourth is team feedback. The people working inside the system every day notice friction before any dashboard can, and a standing channel for reporting small annoyances is one of the highest-return mechanisms in the entire engagement. Minor irritations, fixed quickly, are what keep adoption high in month eight, long after the energy of launch has faded. One thing deserves to be stated plainly: we don't sell maintenance on day one. Ongoing work gets earned through results. The system goes live, adoption climbs, the numbers materialize, and then the company asks what comes next. That sequence matters, and any provider pushing a substantial retainer before delivering anything is showing you where their incentives sit. ## Why implementations fail After 90+ builds of our own and a fair number of post-mortems on projects other providers delivered, the failures cluster into five patterns. The first is that the assessment got skipped or performed superficially. The system was designed from the founder's map, the people doing the work rejected it, and adoption never materialized. This is the most common cause of failure, and it gets decided before anything is built. The second is that a broken process got automated. Nobody fixed the underlying workflow first, so the new system simply executed the dysfunction at higher speed. The third is that tools got selected before any architecture existed. Someone chose the software stack first and bent the business to fit it, when the tools should be the final decision in the sequence rather than the first. The fourth is that the AI went in first instead of last. Agents got deployed onto fragmented data with no workflow layer beneath them, produced impressive demonstrations alongside unreliable work, and the team lost faith in the entire initiative. The order of operations matters: data, then workflows, then intelligence. The fifth is that nobody owned the switch. There was no migration strategy, no cutover date, and no accountable owner on the client side, so the new system launched into a vacuum while the old tools stayed alive, and organizational inertia did the rest. It's worth noticing that none of the five are technical. The technology has never been more capable or more accessible, and implementations fail on process, sequencing, and adoption, which is precisely why the process is the product. ## What 90 days actually looks like Pulling everything together, here is the shape of a typical engagement. Timelines flex with complexity, but the sequence never changes. Weeks 1 and 2 are the Current State Assessment: interviews, the silo inventory, workflow mapping, and pain quantification, with the blueprint delivered and walked through at the end of week 2. Weeks 3 and 4 cover architecture and foundations, where the data model gets finalized, the decision tree gets applied to the existing stack, the migration path gets chosen, and the build begins with the database. Weeks 5 through 8 are dedicated to workflows, with core automations built and tested on real data, department by department, and daily demonstrations throughout. Weeks 9 and 10 bring the intelligence layer, with agents deployed on top of stable workflows and tested against real cases before real work depends on them. Weeks 11 and 12 cover migration, training, and launch, with the switch executed on the chosen path, role-based training delivered, the cutover date honored, and the old tools cancelled. The first 30 days after launch are the adoption watch, with usage monitored, shadow systems caught and resolved, and friction addressed quickly. From there, the engagement runs on the feedback loops: monitoring, reviews, optimization, and expansion. ## The process is the product Anyone can build an automation right now. The tools have never been better and the technical barrier has never been lower, which is exactly why the process matters more than it ever has. The companies on those 14 calls didn't need someone who knows the tools. They needed someone who could assess the entire operation, find the silos, quantify the pain, design the architecture, decide what to absorb, keep, and kill, build in the correct order, migrate the correct way, and remain accountable to Adoption Rate long after launch. That is the actual work, and the code turns out to be the smallest part of it. If you know AI should be doing more for your business than a chatbot subscription, this is the process we would run with you. Book a call at boomautomations.com/apply and we'll start with the Current State Assessment.
## Media
1. image: https://social-archiver-api.social-archive.org/media/archives/tgroenwals/9lSf40sVwh/media/0.png