Debsan blog

Why AI Lead Scoring Fails Without Clean CRM Data First

sal@debsan.co (Sal Brucculeri) — Fri, 11 Sep 2026 12:15:02 GMT

An AI lead scoring model cannot know what your sales team already knows by instinct. It can only know what somebody bothered to enter into the CRM, and in most companies that is a very different thing.

This is why so many AI lead scoring rollouts produce a ranked list nobody trusts. The team keeps working leads the old way, off gut feel and tribal memory, while the score sits in a column nobody opens. Not because the team is stubborn. Because the score is lying to them, and they can tell.

The tool is not usually the problem. The nine months of CRM history it was trained on is.

AI lead scoring does not fix bad data, it just multiplies it faster

A scoring model is a pattern matcher. It looks at closed deals, finds what they had in common, and applies that pattern to open leads.

If the fields it is learning from are wrong, stale, or missing on half the records, the model does not correct for that. It learns the wrong pattern with total confidence and applies it at scale.

That is the actual failure mode. Not a bad algorithm. A confident algorithm trained on a CRM nobody has kept honest.

The trust gap is why most CRMs fail before AI ever touches them

Debsan calls this the trust gap: the distance between the data a company has and the data it will actually act on.

Every CRM in the mid-market has thousands of fields filled in. Lifecycle stage, lead source, last activity date, deal owner. The trust gap is not about whether the fields exist. It is about whether a salesperson would bet a real decision on what's in them.

Ask any sales leader whether they trust their own pipeline data and watch the pause before they answer. That pause is the trust gap, and it existed long before anyone mentioned AI.

Three specific breakdowns make lead scores untrustworthy

Each of these looks like a data hygiene issue on the surface. Underneath, each one is a habit nobody was ever asked to change, so it kept happening quietly until a model made it visible.

The first is stage drift. Reps move deals forward to look productive in a pipeline review, not because the deal actually advanced. A model trained on stage transitions learns from movement that never reflected reality, and it treats that fake progress as a real signal of buyer intent.

The second is ownership rot. Leads sit assigned to reps who left the company months ago, or to a queue nobody checks. The model treats an abandoned lead the same as an actively worked one, because nothing in the data tells it otherwise, so dead leads keep scoring as warm.

The third is missing negative signal. Most CRMs log what a lead did. Very few log what a lead was offered and ignored. A model that only sees positive activity cannot tell the difference between genuine interest and a rep who logged a call that went nowhere just to hit an activity quota.

None of these are AI problems. They are process problems that AI makes visible, usually for the first time anyone has looked closely.

A distrusted score becomes an extra decision, not a shortcut

The whole promise of lead scoring is that it removes a decision from a rep's morning. Work the top of the list, skip the rest.

When the score is wrong often enough, reps stop trusting it within a few weeks. They do not tell anyone. They just quietly go back to working leads the old way, off memory and instinct, while the score keeps running in the background for no one.

Now the company is paying for two systems instead of one. The CRM, and the informal judgment every rep is still using because the CRM never earned their trust. That is a worse position than not having a model at all, because leadership believes a decision is being automated when it is not.

Cleaning the data once will not hold, ownership has to change

Most companies respond to a bad scoring rollout with a data cleanup sprint. Someone spends two weeks fixing lifecycle stages and deduping records.

Months later the CRM looks exactly the way it did before the sprint. Nothing about who enters data, when, or why was actually changed, so the same decay returns on the same schedule.

The fix that holds is a named field owner and a rule for what triggers a correction, not a one time scrub. If nobody owns a field, nobody is accountable when it drifts, and it will drift again. A field with an owner gets fixed in days. A field with no owner gets fixed once a year, right before the next tool purchase.

An AI Forward Deployed Engineer treats the CRM as the target system, not an afterthought

This is where most AI vendors and most internal AI initiatives quietly give up. They will build a scoring model against whatever data exists, then hand over a dashboard and call it done.

An AI Forward Deployed Engineer works inside your ERP, CRM, and financial systems to deploy AI where it reduces coordination cost or decision latency, rather than delivering a generic product or a demo from a distance. For lead scoring, that means going into the actual CRM, mapping which fields are structurally unreliable, and fixing the input problem before the model is ever trusted with a decision.

That is slower than plugging in a vendor tool. It is also the only version that produces a score sales actually acts on, because the people entering the underlying data were part of fixing it.

Sequencing determines whether a lead score ever earns trust

Scoring should be the last thing you automate in a sales pipeline, not the first. It depends on clean stage data, honest ownership, and activity logging that already works.

The same principle shows up from a different angle in how AI should actually sit inside a sales pipeline: AI belongs at the handoff points where a human would otherwise have to carry information by hand, not layered on top of data nobody has verified.

Fix the pipeline mechanics first. Let the score come after, once there is something honest underneath it to learn from.

What CEOs actually ask about this

Should we buy a better lead scoring tool or fix our CRM data first? Fix the data first. A better model trained on the same unreliable fields will just be confidently wrong instead of vaguely wrong, and confidently wrong is harder for a sales team to catch.

How do we know if our CRM data is clean enough for AI? Pull ten closed-won and ten closed-lost deals and check whether the stage history and activity log actually match what your reps remember happening. If they don't, the data isn't ready.

Who should own data quality, sales ops or the vendor? Neither, by default. Someone inside the company needs to own each critical field, with a rule for what triggers a fix, or the decay comes back regardless of who built the model.

Will fixing the data delay our AI rollout? It will delay the launch date and shorten the time to a score people actually use. A model shipped on bad data still has a launch date, it just also has a quiet failure date a few weeks later.

What's the fastest way to find out if our lead scores can be trusted? Ask three reps if they use the score to prioritize their day. If the honest answer is no, the model already told you everything you need to know.

A lead score is only worth what the data under it can support. Fix that first, and the score finally has something true to say.

How AI Should Actually Sit Inside Your Sales Pipeline

sal@debsan.co (Sal Brucculeri) — Thu, 10 Sep 2026 17:49:57 GMT

Most sales teams do not have an AI problem. They have a CRM nobody fully trusts, and a chatbot bolted on top of it that cannot see the pipeline any better than the reps can.

Leadership asks for "AI in sales" and gets a summarizer. It writes a nice recap of a call. It cannot move a deal, flag a stall, or update a stage. Everyone nods at the demo, then goes back to doing the actual work by hand.

Most AI sales tools get added beside the pipeline, not inside it

A summarizer, a call transcriber, a chatbot that drafts follow up emails. All useful. None of them sit inside the pipeline itself.

They sit next to it, in a separate tab, producing output a rep still has to carry over by hand. You already know this pattern if you read what we wrote about the relay gap. Sales is where it costs the most, because a pipeline is not a document. It is a live sequence of decisions, and every one of them has a deadline attached whether anyone wrote it down or not.

A pipeline is a sequence of decisions with an owner, not a list of deals

Every stage a deal sits in represents a decision someone is supposed to make. Qualify or disqualify. Escalate or wait. Discount or hold the line.

Most CRMs record the decision after a human already made it. That is bookkeeping, not intelligence. An AI tool that only summarizes what already happened is doing the same job the CRM already does, just with better sentences.

The right question is not where to add AI. It is which stage transition AI is allowed to make.

Ask a sales leader where they want AI in the pipeline and you usually get a wish list: better forecasting, smarter scoring, faster follow up. None of that is a placement decision.

The actual question is narrower. At which specific stage transition does the AI have enough reliable information to act, not just suggest? Get that placement wrong and you have built an expensive summarizer. Get it right and you have removed a bottleneck that was quietly costing deals every week.

An AI operator acts at the handoff points. A copilot only narrates them.

An AI operator is an AI system with write access inside a company's systems of record, positioned to execute the next step itself instead of surfacing a suggestion for a person to relay by hand. Inside a sales pipeline, the handoff points are exactly where this distinction shows up first.

A lead crosses a scoring threshold. A deal sits untouched past its normal stage velocity. A contract needs a specific approval routed to a specific person. A copilot can describe all three. An operator moves the lead, flags the stall to the actual owner, and routes the contract, because it has permission to act inside the CRM rather than talk about it from outside.

Picture the same stalled deal handled two different ways

A deal has sat in "proposal sent" for eleven days with no activity logged. A copilot notices this in its weekly digest and tells the rep's manager in a summary email nobody opens until Friday.

An operator notices it the moment it crosses the stall threshold, checks the last three touchpoints for context, drafts a specific next action based on what actually happened in those touchpoints, and assigns it to the rep with a deadline, inside the CRM, where the rep already works.

Same information. Same tool budget, most of the time. Completely different outcome, because one of them closes the loop and the other one reports on it.

Multiply that gap across a pipeline with four hundred open deals and it stops being a small inefficiency. It becomes the reason forecasts are consistently wrong in the same direction, because the deals quietly stalling behind a missed handoff never show up as a number until they are already lost.

This is where the relay gap costs the most in a sales org

The relay gap is the distance between where an AI tool produces an answer and the system of record where that answer has to end up, closed only by a person copying it over by hand. In sales, every day that gap stays open is a day a deal moves slower than it should have.

A forecast call that requires a rep to manually reconcile three tools before a Monday pipeline review is not a forecasting problem. It is a relay gap with a meeting attached to it. Fixing the meeting cadence will not fix it. Closing the gap will.

An AI Forward Deployed Engineer builds this inside your actual CRM, not beside it

An AI Forward Deployed Engineer works inside a client's actual ERP, CRM, and financial systems to deploy AI where it reduces coordination cost or decision latency, rather than delivering a generic product or a demo from a distance. Inside a sales org, that means going into the actual pipeline stages, the actual scoring logic, the actual routing rules your team has half documented and half remembered, and building the write access an operator needs at the specific handoffs that matter.

It is slower to build than a chatbot demo. It is also the only version that survives past the first quarter, because it was built against how your pipeline actually moves deals, not a generic template of how pipelines are supposed to work.

Your scoring model has exceptions your CRM vendor never anticipated. Your routing rules have a version that exists only in your ops manager's head. None of that shows up in a generic AI sales tool's configuration screen, and all of it has to be understood before an operator can safely be given write access to act on its own.

Most AI sales failures are placement failures, not intelligence failures

Nobody's AI tool got dumber between the pilot and the rollout. What usually happened is that leadership picked the easiest place to bolt AI on, not the place where a decision was actually bottlenecked.

The fix is not a smarter model. It is moving the same capability to the handoff point where a rep, a manager, or a deal was actually waiting on something.

Most sales leaders can name their biggest pipeline bottleneck without looking at a single report. The harder question is whether anything in their stack is actually allowed to act on it.

What CEOs actually ask about this

Where should we put AI in our sales pipeline first?

Start at the stage transition with the clearest rule and the most deals stuck behind it, usually stalled proposals or unscored leads. That is where an operator earns trust fastest.

Should we replace our sales reps with AI?

No. The goal is removing the handoffs that waste a rep's time, not the rep. Reps close relationships. AI should close the gap between a decision and the system that records it.

Our AI tool already summarizes deals well. Why isn't that enough?

Because a good summary that still requires a human to act on it has not removed any work. It has just made the work easier to read before someone does it manually.

How is this different from sales automation we already tried?

Most sales automation runs on fixed rules and breaks the moment a deal does not fit the pattern. An AI operator works from context at the handoff point, which is why it holds up on the deals that do not follow the script.

A pipeline does not need a smarter observer. It needs fewer places where a decision sits waiting for someone to notice it.

Why Most Internal AI Tools Die in a Browser Tab

sal@debsan.co (Sal Brucculeri) — Thu, 10 Sep 2026 16:14:36 GMT

Somewhere in your company is a Slack channel or a bookmark folder full of AI tools nobody opens anymore. Not because they were bad. Because using them meant doing extra work, not less.

Six months ago someone rolled one out with real excitement. A chatbot trained on your docs. A copilot inside your CRM. An assistant that summarizes calls. Usage spiked in week one. By week eight it was three people, then it was nobody.

Every company that adopts AI eventually has a tool nobody uses anymore

The graveyard is not a mystery. It is the most predictable outcome in enterprise software, and AI tools are dying in it faster than any category before them.

The reason is almost never the model. Whatever your vendor shipped last quarter is good enough to be useful. Good enough was never the problem.

The tool did not fail. The last step did.

Open the tool. Ask the question. Read the answer. Now do something with it.

That fourth step is where adoption actually dies. The answer lives in a chat window. The work lives somewhere else, in the CRM, the ERP, the ticketing system, the spreadsheet the team actually runs on. Someone has to carry the answer from one place to the other, by hand, every single time.

That person is not lazy. They are running a cost benefit calculation they never wrote down: is retyping this answer into the system faster than just doing the task the old way. Most days, it is not.

This gap has a name: the relay gap

The relay gap is the distance between where an AI tool produces an answer and the system of record where that answer has to end up, closed only by a person copying it over by hand. Every generic AI chatbot bolted onto a company has one. Most companies never measure it because it does not show up as a bug. It shows up as declining usage, which everyone quietly blames on the users.

It is not a training problem. Training makes people faster at the relay. It does not remove it.

Picture a normal Tuesday, not a demo

A support rep asks an internal AI tool to summarize a customer's last three tickets before a renewal call. The summary is good. Now the rep has to open the CRM in a second tab, find the account, and retype the summary into a notes field so the account manager can see it later.

A finance analyst asks an AI tool to reconcile a vendor statement against the ledger. It flags two mismatches correctly. Now someone has to open the accounting system, find the matching entries, and make the correction by hand, because the tool that found the problem has no way to fix it.

Neither tool was wrong. Neither answer was bad. In both cases the work was not finished when the AI finished. It was finished when a person did the part the AI could not reach.

The relay gap is a tax, and it compounds like one

One relay step feels trivial. Copy an answer, paste it into a field, move on. Multiply that by every rep, every day, every ticket, and the tax adds up to real hours that never show up on anyone's calendar.

Worse, the tax is not flat. It grows with adoption. The more people you get to try the tool, the more relay steps the organization is quietly absorbing, which means the tools that look most successful in a pilot are often the ones about to collapse under their own usage.

A copilot cannot close its own relay gap

Most of what gets sold as AI for your business is a copilot: something that suggests an answer and waits for a person to act on it. Copilots are genuinely good at suggesting. They are structurally incapable of closing the relay gap, because closing it requires taking the next step inside the system of record, not describing it in a chat window.

That is the actual distinction between an AI copilot and an AI operator. An operator has write access inside the systems people already work in and takes the next step itself. A copilot, no matter how well it writes, hands the relay back to a human every time.

Closing the relay gap is systems work, not prompt work

Better prompts make the copy better. They do not remove the copying. Fixing the relay gap means going into the CRM, the ERP, and the ticketing tool, and building the connective tissue that lets an AI system act where the answer needs to land, not just where the question was asked.

That is deliberately harder than shipping a chatbot. It means touching permissions, API scopes, and whatever undocumented logic your team built up over the years to keep the current system working at all. It is also the only version of the fix that survives past the first month.

The relay gap is also one of the clearest, most measurable sources of coordination cost inside a company: the time and effort a company spends moving information from where it exists to where a decision needs it, separate from the cost of the decision itself. A tool that produces a good answer nobody can act on without retyping it has not reduced coordination cost. It has relocated it, from before the answer to after it.

This is exactly the work an AI Forward Deployed Engineer does

An AI Forward Deployed Engineer works inside a client's actual ERP, CRM, and financial systems to deploy AI where it reduces coordination cost or decision latency, rather than delivering a generic product or a demo from a distance. Closing the relay gap is one of the clearest examples of that work in practice. It is not a new tool. It is removing the seam between the tool and the system that was already going to eat its usage.

Most internal AI rollouts skip this because it is slower and less demo-able than a chatbot launch. The companies getting real, durable usage out of AI are almost always the ones who did the unglamorous integration work first.

Nobody notices a relay gap until they measure it

Ask your team how many times a day they copy something out of an AI tool and paste it somewhere else. Most leaders have never asked, and would be surprised by the answer.

It is worth asking before you fund the next pilot.

What CEOs actually ask about this

Why did our AI chatbot get so much attention at launch and then go quiet?

Because the excitement covered the extra step for a few weeks. Once the novelty wore off, the relay gap was still there, and it quietly won.

Is the fix a better AI model?

No. Every mainstream model available today is good enough to be useful. The gap is in the wiring between the tool and the system your team actually works in, not the model's intelligence.

How do we know if we have a relay gap problem right now?

Ask how many manual copy and paste steps sit between your AI tools and your systems of record. If the honest answer is more than zero for a task done daily, you have one.

Should we build this ourselves or bring someone in?

It depends on whether your internal team already has write level access to your CRM, ERP, and financial systems, and the time to build against them safely. Most mid-market companies do not, which is the specific gap an AI Forward Deployed Engineer is built to close.

The relay gap does not show up on a roadmap. It shows up as a tool nobody opens anymore.

The Difference Between an AI Copilot and an AI Operator

sal@debsan.co (Sal Brucculeri) — Wed, 09 Sep 2026 16:15:52 GMT

Sal sat through a demo last month where the AI tool did something genuinely impressive. It read a support ticket, drafted a response, flagged the account as at risk, and suggested three next steps to the account manager.

The account manager still had to open the CRM, find the ticket, copy the flag over, and manually type the next step into the deal record. The AI did the thinking. A person did the moving.

Nobody in the room seemed to notice the gap, because the demo was genuinely good. The output was smart, well written, and correct. It just never actually touched the system where the account manager's real work lives.

That gap between the thinking and the moving is the whole difference between a copilot and an operator, and almost nobody selling AI wants to draw the line clearly, because most of what gets sold is a copilot wearing an operator's marketing.

A copilot suggests an action inside a chat window. An operator takes the action inside the system of record itself.

A copilot lives beside your systems. It reads context, generates a recommendation, and hands that recommendation back to a person who still has to go do something with it in the CRM, the ERP, or the spreadsheet where the real record lives.

An operator lives inside the system. It has the access and the permission to make the update itself: change the deal stage, adjust the forecast line, route the ticket, close the loop. Nobody has to relay the output anywhere.

Most companies think they have deployed AI broadly because employees have a chat window open in a dozen places. Almost none of that is operator work. Almost all of it is a very articulate suggestion box.

This is not a preference question. It is a coordination cost question.

We have written before about coordination cost: the time and effort a company spends moving information from where it exists to where a decision needs it, separate from the cost of the decision itself.

A copilot removes the cost of generating the recommendation and leaves the coordination cost fully intact. Someone still has to notice the suggestion, trust it, and carry it into the system that actually runs the business. That relay step is where most AI copilots quietly die.

Add up enough of those relay steps across a company and the AI subscription becomes a second job nobody asked for. The tool did not save time. It moved the work from typing to reviewing, and reviewing still has to happen on somebody's calendar.

An AI operator is defined by where it sits, not by how smart its output is.

An AI operator is an AI system with write access inside a company's systems of record, positioned to execute the next step itself instead of surfacing a suggestion for a person to relay by hand.

That single sentence is the whole distinction. It has nothing to do with model quality, prompt engineering, or which vendor's logo is on the tool. It is entirely about access and placement.

The same distinction shows up in every function, not just support tickets.

In sales, a copilot recommends which deal to call today. An operator updates the deal stage itself once the criteria for that stage are actually met, and only flags the calls that need a human read.

In finance, a copilot flags a transaction that looks like it might not reconcile. An operator reconciles the ninety percent of transactions where the match is unambiguous and escalates only the genuine exceptions.

In marketing, a copilot suggests which campaign is underperforming. An operator reallocates spend inside the approved range and reports what it did, rather than waiting for someone to read a dashboard and act on it three days later.

Systems of record are not equally forgiving, so the operator line should move at different speeds in different places.

An internal scheduling tool can tolerate a wrong move far better than a general ledger can. Handing an operator write access to a task calendar is a low stakes decision. Handing it write access to customer invoicing is not, and treating those two decisions the same way is how companies end up with a story they tell at conferences about the time AI broke something expensive.

The right sequence puts operators to work first on internal, reversible, easily checked tasks, and only extends into customer facing or financially binding systems once the pattern of being right has been established somewhere lower stakes.

Most companies buy copilots because operators are harder to justify and scarier to approve.

A copilot is an easy purchase. It sits in a browser tab, a Slack channel, or a sidebar, and if it says something wrong, a person catches it before anything happens downstream.

An operator requires someone to answer a harder question first: what happens the one time it is wrong inside a live system. Companies that cannot answer that question yet are not ready for an operator, whatever the sales deck promises.

This is exactly the gap an AI forward deployed engineer is built to close.

An AI forward deployed engineer works inside a client's actual ERP, CRM, and financial systems to deploy AI where it reduces coordination cost or decision latency, rather than delivering a generic product or a demo from a distance.

Moving something from copilot to operator is not a settings toggle. It requires someone who understands the specific system well enough to know which actions are safe to hand over first, and which ones still need a person in the loop for another six months.

The move from copilot to operator should happen one narrow task at a time, never all at once.

The companies that get burned by AI operators are the ones that skip the narrow step and grant broad write access on day one, because the copilot phase felt safe and they assumed the operator phase would feel the same.

It does not. The first time an operator makes an unsupervised change inside a system a customer or a bank statement touches, it will get everyone's full attention, and it should. Start with one task, prove it, then expand.

A good first task has three properties: the correct outcome is checkable against existing data, the cost of a mistake is low and recoverable, and the volume is high enough that a person reviewing every instance was never a good use of their time anyway.

The right question is not copilot or operator. It is which task, in which system, is ready for which one.

Some tasks should never leave copilot status. A recommendation on how to phrase a difficult customer email should probably always pass through a person first, because tone and judgment are exactly what a person is still better at.

Other tasks, like updating a CRM field with a value the AI can verify against three other data points, are wasting money every day they stay stuck at the copilot stage, generating a suggestion nobody has time to act on.

What CEOs ask us about this

Is an operator just a more advanced copilot?
No. The difference is access, not intelligence. A copilot can be extremely capable and still be a copilot if it has no write access to the system where the work actually happens.

How do we know which tasks are ready to move from copilot to operator?
Start with tasks where the correct answer can be checked against existing data automatically. If a person cannot quickly verify whether the AI got it right, it is not ready for operator status yet.

Isn't giving AI write access into our CRM or ERP risky?
Yes, which is why it should be scoped narrowly and expanded only after the narrow version has run cleanly for a real stretch of time, not a demo period.

Why do most AI tools stay copilots forever?
Because moving to operator status requires someone who understands the specific system deeply enough to define what safe looks like, and that work is slower and less visible than shipping another chat interface.

Where AI Actually Reduces Coordination Cost Inside a Company

sal@debsan.co (Sal Brucculeri) — Wed, 09 Sep 2026 12:14:47 GMT

Most of the time inside a growing company does not go to doing the work. It goes to finding out who already has the information you need to do the work.

Ask a VP how long a pricing exception actually takes and they will describe the approval. Ask how long it takes for the exception to actually clear and you get a different number, usually three or four times larger, because most of it was spent waiting for someone to notice the request existed.

That gap has a name. We call it coordination cost, and it is the single most common place we find AI actually earning its budget, well ahead of anything flashier.

Coordination cost is what a company pays to move information from where it exists to where a decision needs it, separate from the cost of the decision itself.

Every company already knows how to make its core decisions. Approve the discount, reroute the shipment, escalate the ticket. Nobody is confused about the logic once the right information reaches the right person.

The expensive part is everything before that. A rep waiting on an inventory answer nobody has pulled yet. A manager approving something an hour after it stopped being urgent. An operations lead reconstructing a customer's history from four systems that do not talk to each other, before they can even start solving the actual problem.

Coordination cost hides inside headcount, not inside a line item, which is why leadership usually underestimates it.

Nobody has a budget line called coordination. It shows up instead as an extra person hired to keep three systems in sync, a standing meeting that exists only to relay status, or a manager who has become a full time router of other people's questions.

If you asked your team what percentage of a normal day goes to relaying information rather than acting on it, most leaders guess low. Most employees, asked privately, guess a lot higher.

This is why coordination cost survives budget reviews for years. It never appears as a single number worth cutting. It appears as a hundred small delays everyone has learned to work around.

AI reduces coordination cost by closing the gap between something happening and someone finding out, not by making anyone type faster.

The useful version of AI inside a company is not a chatbot that answers questions if someone remembers to ask it. It is a system that already knows a decision is waiting and already knows who owns it, before a human has to notice.

An AI forward deployed engineer builds exactly that connective layer, inside your actual CRM, ERP, and financial systems, because the value only exists once it is wired into the systems where the waiting actually happens. That is the whole job, not a generic tool bought off a shelf and pointed at your data after the fact.

The clearest signal that coordination cost is high is a manager whose calendar is full of meetings where nothing gets decided.

A status meeting exists because the information does not move on its own. Someone has to physically gather the room to find out what everyone else already knows, then repeat that gathering next week because nothing changed about how the information travels between meetings.

Cut the meeting without fixing the underlying information flow and you have not solved anything. You have just made the coordination cost invisible again, right up until something breaks that a status meeting would have caught.

The companies that get this wrong try to automate the decision first, when the actual leverage is in automating the notice.

We regularly see companies buy an AI tool that promises to make a decision, a pricing recommendation, a lead score, a forecast, before they have fixed the much cheaper problem of getting the right person the right information at the right time.

Automating a decision nobody trusts yet is a fast way to get the decision reversed and the tool abandoned. Automating the notice, so the right person sees the right thing at the right moment, builds trust first and earns the harder automation later.

The best place to start is the handoff that crosses the most systems, not the process that involves the most people.

Coordination cost concentrates wherever a process crosses a system boundary, because every boundary is a place information has to be carried by hand instead of passed automatically. A quote that starts in the CRM, needs a pricing exception approved in the ERP, and then a credit check pulled from a finance system has crossed three boundaries before anyone has actually made a decision.

Each boundary is a place a person currently does the carrying, which means each boundary is also a place AI can close the gap, once someone has mapped exactly what needs to cross it and in what form. This is usually a better place to start than the process that touches the most people, because headcount is visible on an org chart and boundary crossings are not.

This only works once someone has mapped where the waiting actually happens, which is a diagnostic problem before it is a technical one.

You cannot wire a notification layer around a delay you have not located. Most companies know coordination feels expensive without being able to point to the three or four handoffs actually causing it.

That mapping work is unglamorous and it is also the part that determines whether the AI layer built on top of it actually reduces coordination cost or just adds a new system to check. We have written elsewhere about why this has to happen inside the real systems and not from a slide deck describing them.

Reducing coordination cost does not mean fewer people. It means fewer people spending their day being a router for someone else's information.

The goal is not headcount reduction dressed up as innovation. It is putting the people you already have back on the work only they can do, instead of the relay work a system should have been doing for them.

A company that gets this right does not feel faster because everyone is typing quicker. It feels faster because fewer things sit waiting on someone to notice them.

What CEOs ask us about this

How do we know if coordination cost is actually a problem for us?
Look at how many decisions get made in a scheduled meeting instead of the moment the information became available. That gap is coordination cost, and it usually shows up first in your slowest recurring process.

Is this just a fancy word for better software?
No. Software can carry the information, but somebody still has to diagnose where it currently gets stuck and design the specific handoff that closes the gap. That diagnostic work is the actual job.

Where should we start?
Start with the process where the delay between something happening and someone finding out is longest and most expensive, usually somewhere in fulfillment, collections, or exception handling. Do not start with the process that is merely most visible.

Does this require replacing our current systems?
Rarely. Most of this work happens inside the ERP, CRM, and financial systems you already run. The problem is almost never the system itself, it is that nothing inside it is watching for the moment a decision starts waiting.

AI Adoption Is an Implementation Problem, Not a Software One

sal@debsan.co (Sal Brucculeri) — Tue, 08 Sep 2026 16:14:40 GMT

Every AI vendor pitch starts the same way. They show you the tool, the interface looks clean, the demo answers a canned question in eight seconds, and the room nods.

Then the deal closes, the tool gets deployed, and six months later it is quietly ignored by the people who were supposed to use it.

That is not a failure of the software. The software worked exactly as demoed.

It is a failure of the thing nobody bought: the work of making the tool function inside a specific company's specific mess of systems, data, and decision rights.

The software already exists. That was never the hard part.

Every category of AI a mid market company might want, forecasting, lead scoring, financial anomaly detection, document processing, already has a dozen credible vendors selling it.

The technology question was settled years ago. What was never settled is how that technology behaves once it touches a real company's real ERP, a CRM with eight years of inconsistent field entry, and a finance team that keeps its own private spreadsheet because it does not trust the system of record.

Buying software solves a technology problem. Getting value out of it solves an implementation problem, and those are not the same project.

An implementation problem is a coordination problem wearing a technical costume.

Ask why an AI pilot stalled and the answer is rarely "the model was wrong." It is usually something closer to: nobody agreed on which system holds the source of truth, or the data the AI needed lived in three tools that do not talk to each other, or the team that would use the output was never asked what output they actually needed.

Those are not software defects. They are the same coordination failures that show up everywhere else complexity has outgrown structure, just wearing an AI costume this time.

A company that cannot get finance and sales to agree on a single pipeline number will not magically agree once an AI model is summarizing that number for them. It will just get a faster, more confident version of the same disagreement.

Buying the tool and deploying the tool are two different projects with two different failure rates.

Buying rarely fails. There is a budget line, a vendor with a sales team, a signature, and a login. Everyone involved is professionally motivated to get to yes.

Deploying fails constantly, and it fails quietly, because there is usually no single owner accountable for the gap between "we bought the tool" and "the tool is producing a decision someone actually trusts and acts on."

That gap is where an AI Forward Deployed Engineer works: an AI implementer who works inside a client's actual ERP, CRM, and financial systems to deploy AI where it reduces coordination cost or decision latency, rather than delivering a generic product or a demo from a distance.

The clearest sign of an unowned implementation gap is a dashboard nobody opens.

Walk into most companies six months after an AI pilot and you will find a dashboard, a summary email, or a scoring model running quietly in the background. It is technically live.

Ask the manager it was built for whether they actually check it and the answer is usually some version of "not really," followed by a reason that has nothing to do with the technology: the numbers do not match what they see in their own pipeline, nobody explained how the score gets calculated, or it flags things they already knew without telling them anything new.

None of that is a software defect. It is what happens when a capability gets deployed onto a company's systems without anyone doing the harder work of making it match how that company actually makes decisions.

The role exists because someone has to own the space between the vendor and the org chart.

Vendors are incentivized to close the sale and move to the next account. Internal teams are usually stretched too thin to spend the months it takes to reconcile a new AI capability against years of system sprawl.

Neither side is positioned to do the unglamorous work: mapping which fields in the CRM are actually trustworthy, deciding which process the AI should touch first, and building the narrow, checkable use case that earns the organization's trust before anything gets wider authority.

Read The AI Forward Deployed Engineer, Defined for the full breakdown of what that role owns and where its authority starts and stops.

Software problems get solved by a vendor. Implementation problems get solved by someone inside the system.

A software problem has a clean shape: a feature is missing, or broken, or too slow, and a vendor fixes it on their own timeline with their own engineers.

An implementation problem has a messier shape. The technology works, but the organization around it was never restructured to use what it now has.

That restructuring is not something a vendor can sell you, because it is not a product. It is an ongoing act of translation between what the AI can do and what your company's actual processes will let it do.

See What an AI Forward Deployed Engineer Actually Does for how that translation work plays out day to day, inside a real ERP and a real CRM.

The company that treats this as a software decision usually buys twice.

The first purchase is the tool. The second purchase, six to eighteen months later, is either a replacement tool bought on the theory that the first one "did not work," or the implementation work that should have happened the first time, now more expensive because there is a failed rollout to unwind first.

Neither purchase is really about the software. Both are the same unaddressed implementation problem, showing up twice on the budget.

Nobody puts "unresolved implementation problem" on a budget line. It gets relabeled as a new tool instead, and the cycle repeats.

The fastest way to tell which problem you actually have is to look at what happens after go-live.

A software problem shows up immediately: the tool errors, or the feature is missing, or it cannot connect to a system it was promised to connect to. Support tickets get filed. Someone at the vendor responds.

An implementation problem shows up slowly. The tool works. Nobody complains. It also quietly stops being used, because the people expected to act on its output never had a reason to trust it, and nobody owned closing that gap.

What CEOs ask us about this

Isn't this just a fancy word for change management?
Partially. Change management is about people adapting to something new. This also includes the technical work of making the AI function against your real systems, which change management alone does not cover.

Can't our internal IT team just do this?
Sometimes, if they have both the bandwidth and the standing to make decisions that touch sales, finance, and operations at once. Most internal IT teams are already fully committed to keeping current systems running.

How do we know if we have a software problem or an implementation problem?
If the tool is doing exactly what it was built to do and still is not producing decisions people trust or act on, that is an implementation problem, not a software one.

Where should this work actually start?
On one narrow, well bounded process where the AI's output can be checked against a known right answer, not on a company wide rollout.

The AI Forward Deployed Engineer, Defined

sal@debsan.co (Sal Brucculeri) — Tue, 08 Sep 2026 12:16:19 GMT

Most companies buy AI the same way they buy a treadmill. Excited in month one. Ignored by month three. Still sitting there in month six, technically owned, doing nothing.

That is not an AI adoption problem. It is a deployment problem. And the industry has spent two years selling companies demos instead of deployment.

Here is the distinction that actually matters, and the term we use for the person who closes the gap.

What Is an AI Forward Deployed Engineer?

An AI Forward Deployed Engineer is an AI implementer who works inside a client's actual ERP, CRM, and financial systems to deploy AI where it reduces coordination cost or decision latency, rather than delivering a generic product or a demo from a distance.

Read that sentence twice. The important word is not AI. It is inside.

Most AI vendors sell you something that sits beside your systems. A chatbot layered on top of your CRM. A dashboard that summarizes your ERP without touching it. A tool that lives in a browser tab your team opens twice and forgets. An AI Forward Deployed Engineer does not build beside the system. They open the system, understand how work actually moves through it, and place AI at the specific point where a human is currently the bottleneck.

Why Did This Term Need Defining Again?

We introduced this concept in an earlier post, What an AI Forward Deployed Engineer Actually Does. That post described the behavior. This one names the category and locks the definition, because a firm cannot be an authority on a concept it defines differently in every post.

This is now Debsan's flagship AI concept. Every AI post we publish from here forward roots back to this definition. If we ever use the term loosely, that is a mistake, not a style choice.

Why Does the Work Have to Happen Inside the System?

Because coordination cost and decision latency do not live in a slide deck. They live in the actual workflow. The actual approval chain. The actual handoff between the person who closes a deal and the person who provisions the account.

You cannot see a coordination problem from outside a system. You can only infer it. An AI Forward Deployed Engineer does not infer it. They watch the deal move through the CRM, watch the invoice move through the ERP, and watch the decision sit in someone's inbox for four days waiting on a person who was never actually required to be the approver. Then they build the fix where the friction is, not where it is easiest to build.

How Is This Different From a Traditional AI Consultant?

A traditional AI consultant produces a strategy document. Sometimes a proof of concept. Almost never a change to how the real system behaves on a Tuesday afternoon when nobody is watching.

An AI Forward Deployed Engineer produces a working change inside the ERP, the CRM, or the financial close, measured by whether a specific decision now happens faster or a specific handoff no longer requires a human to remember it. One of these approaches produces a report. The other produces a system that behaves differently. Only one of them is worth paying for.

What Does This Person Actually Work On?

Four functions, in practice: internal operations, sales, marketing, and financial analysis. Each has its own failure pattern, which is why we are covering each separately in the posts that follow this one.

Internal operations is where AI removes the manual handoffs that currently require a person to notice something and tell another person. Sales is where AI either sits inside the pipeline and improves what is already true, or sits beside it and produces confident guesses about data nobody trusts. Marketing is where AI is mistaken for a content machine when its actual value is decision intelligence. Financial analysis is where AI has the least room for error and the most upside, if it is sequenced correctly against the close.

We will define each of those precisely, function by function, rather than gesture at all four in generalities. Generalities are how AI content became worthless in the first place.

Notice also what is missing from that list. It is not "customer service chatbot" or "internal search tool." Those are common AI purchases and they are rarely where the coordination cost actually lives. An AI Forward Deployed Engineer starts from the operating model, not from the AI product catalog, which is why the starting point often looks less exciting than what a vendor would have pitched.

Why Do Most Companies Get This Backwards?

They start with the tool. They ask, "what can this AI product do," and then go looking for a place to point it. That is the demo mindset, and it produces demo results. Impressive in a meeting. Dead within a quarter.

The correct starting question is different: where in this company does a decision wait on a person longer than it should, or does information move slower than the business now requires? That question has nothing to do with AI. It is an operations question. AI is just the tool that happens to be capable of answering it now, at a cost that was not available five years ago.

Picture the pattern generically, because it repeats everywhere. A deal closes in the CRM. The account still needs to be set up in the ERP before work can start. Right now that handoff depends on someone remembering to flag it, and someone else remembering to check for the flag. No AI product fixes that by sitting beside either system. An AI Forward Deployed Engineer fixes it by making the handoff fire automatically, inside the systems that already hold the truth, with a human only in the loop for the exceptions that actually need judgment.

How Does This Connect to the Scaling Ceiling?

This is where the AI conversation stops being a technology conversation and becomes a Debsan conversation. What built the company is rarely what scales the company. That sentence was true before AI existed and it is still true now.

Bolting a generic AI tool onto an entrepreneurial operating model does not scale the model. It just makes the informal system move faster toward the same ceiling it was already heading for. The companies that get real leverage from AI are the ones that treat it as an operating model decision first and a tooling decision second. That is the entire premise of forward deployed AI work, and it is why the role has to be defined precisely instead of marketed loosely.

This is also, plainly, the work we do. Debsan does not sell AI licenses. We place people inside a client's actual systems to find the specific point where AI reduces coordination cost, and we build it there. That is the whole model. It is not more complicated than that, on purpose.

What Should a CEO Actually Take From This?

Is my company ready for an AI Forward Deployed Engineer, or do we need to fix something else first?
If your processes are not documented anywhere outside someone's head, AI implementation will just make that dependency faster, not safer. Fix the process ownership question first.

How is this different from just hiring a data scientist or an AI vendor?
A data scientist optimizes models. A vendor sells a product. An AI Forward Deployed Engineer is accountable for a specific operational outcome inside your actual systems, which is a different job than either of those.

Which function should we start with: sales, marketing, operations, or finance?
Start wherever a decision currently takes the longest to make relative to how much money is riding on it. That is almost never the function leadership assumes.

How do we know if an AI pilot is real progress or just theater?
A real deployment changes a measurable behavior inside a system your team already uses every day. A pilot that only lives in a demo environment is theater, no matter how good the demo looks.

The term is defined now. Everything else we publish on AI builds on it.

The Real Benefit of HubSpot Is What It Lets You Forget

sal@debsan.co (Sal Brucculeri) — Mon, 07 Sep 2026 21:47:14 GMT

Ask a founder what they like about their CRM and they will usually mention a report, a pipeline view, something visual. Ask what actually changed after they implemented it and, if they are honest, the real answer is smaller and less exciting: fewer things fell through the cracks because a human forgot to do them.

That is the actual benefit. Not the dashboard. The forgetting.

Every business runs on a set of steps that someone has to remember to do. Automation is what happens when the system remembers instead.

A lead comes in. Someone has to notice it, route it, follow up, follow up again, and eventually either close it or disqualify it and move on. None of that requires judgment. All of it requires memory and consistency, which are exactly the things individual humans are worst at under pressure.

When that sequence lives in someone's head, it survives exactly as long as that person's attention span, workload, and tenure at the company. When it lives in the system, it runs whether that person is focused, overloaded, or on vacation.

This sounds obvious written down. It is remarkable how few companies have actually done it for their own core processes, as opposed to just having the tool that could do it.

Process dependency is not just a documentation problem. It is what happens when automation was never built in the first place.

We defined process dependency as processes that exist in an individual's memory instead of in the system, measured by what breaks if a named person leaves. Automation is the most direct fix available, because it moves the sequence out of memory and into something that runs regardless of who is watching.

The follow-up email that only gets sent when someone remembers to send it. The internal handoff that only happens because one coordinator tracks it in a notebook. The renewal reminder that lives in someone's calendar instead of the system of record. Every one of these is a small, unautomated dependency waiting to become a real problem the day that person is out sick during the exact week it mattered.

HubSpot's workflow engine is not exciting to look at, which is exactly why it works.

Workflows in HubSpot are not artificial intelligence and nobody should market them as such. They are conditional logic: when this happens, do that, unless this other thing is also true. It is the least glamorous part of the platform and the part that actually changes how a company runs day to day.

A lead that meets certain criteria gets routed to the right rep automatically instead of sitting in a shared inbox. A deal that has not moved in two weeks triggers a reminder instead of quietly aging out. A customer who has not been contacted in ninety days gets flagged before the relationship goes cold, not after a renewal is already lost.

None of this requires anyone to be smarter. It requires someone to sit down once and actually define the sequence, which is the same underlying work as fixing process dependency anywhere else in the business.

The mistake most companies make is automating a broken process faster.

Automation amplifies whatever is already happening. If the underlying process is sound, automation makes it faster and more consistent. If the underlying process is broken, automation just breaks it faster and more consistently, and now it looks official because a system is doing it.

We always fix the sequence first: who owns each step, what triggers the next one, what counts as done. Only after that gets defined does it make sense to build the automation, because otherwise you are encoding confusion into software and calling it progress.

We have inherited more than one workflow setup where the automation was technically flawless and functionally useless, because it faithfully executed a process nobody had actually agreed on. The build was not the problem. The design conversation that never happened before the build was.

Reducing information lag is the underrated benefit nobody puts in the sales deck.

Information lag is the elapsed time between something going wrong and leadership finding out. Automated alerts and triggers are one of the few tools that directly shrink that gap without requiring a person to notice and report the problem manually.

A deal stalled for three weeks. A customer who went quiet after years of regular contact. A support ticket that has not been touched in two days. These are the early signals leadership usually hears about only once they have become expensive. Automated triggers surface them while they are still cheap to fix.

Decision concentration shows up in automation too, just in a quieter form.

We usually find one person, often in operations or sales leadership, who is the only one who understands how the workflows are actually built. Every change routes through them, every new automation waits on their availability, and the company has quietly recreated the exact bottleneck it was trying to remove from the sales process.

The fix is the same fix as everywhere else decision concentration shows up: document ownership explicitly, cross train at least one other person, and treat the automation build itself as a process that should not depend on a single irreplaceable person.

Companies that skip this step end up with workflows nobody dares touch, because the one person who understood them left eighteen months ago and took the institutional knowledge with them. The automation still runs. Nobody can safely change it anymore.

The benefit was never the software. It was what the software lets the company stop having to remember.

Every automated step is one less thing riding on someone's attention on a busy Tuesday. Multiply that across a growing company and it adds up to something that looks, from the outside, like the team suddenly got more reliable.

They did not get more reliable. The system started remembering for them.

That is a small thing to say out loud and a large thing to actually build. Most companies never get past wanting it, because it requires sitting down and writing out a process precisely enough for a system to run it, which is more work than it sounds like from the outside.

What CEOs ask us about this

Isn't automation just AI now?
No, and conflating the two causes real confusion. Most valuable automation is simple conditional logic that has existed for years. AI adds judgment on top of that; automation still has to exist first.

Where should we automate first?
Wherever a human is currently the only reason a routine step happens reliably. That is the highest-risk, highest-payoff place to start, and it is usually smaller and less glamorous than leadership expects.

Will automation replace the need for a good sales process?
No. Automation makes a good process run more consistently and makes a bad process fail faster. It never substitutes for actually defining the process in the first place.

How do we know if we are already too dependent on manual follow-up?
If a deal or a customer relationship visibly suffers whenever one specific person is out for a week, that dependency already exists. Automation is one of the fastest ways to close it.

What Operational Transformation Actually Delivers

sal@debsan.co (Sal Brucculeri) — Mon, 07 Sep 2026 16:15:36 GMT

Ask a CEO what operational transformation means and you will usually get a pause, then a guess involving software, or a reorg, or something vaguely about being more efficient. Ask five CEOs and you will get five different answers, and none of them will match.

That vagueness is not an accident. Most firms selling operational transformation have never actually defined it, because a vague deliverable is easier to sell and harder to be held accountable for. We think that is backwards, and we think it is part of why so many transformation engagements produce a deck instead of a different company.

Operational transformation is not a rebrand, a reorg, or a software rollout.

Those three are the usual substitutes, and each one is a real activity that can matter on its own. None of them is the thing itself.

A rebrand changes how the company talks about itself. It does not change who makes which decision on a Tuesday afternoon. A reorg changes the boxes on a chart, and an operating model is not an org chart, so redrawing one rarely touches the actual mechanism running the company. A software rollout, an ERP, a CRM, a new reporting tool, gives the company a new place to store the same broken process, faster.

If any of those three fixed the underlying problem, most companies would have fixed it years ago. Most of the CEOs we talk to have tried all three, some of them more than once.

The deliverable is a rebuilt operating model, not a document.

What actually gets delivered, when transformation is done correctly, is a scalable operating model: an operating model that runs on structure, decisions owned by outcome owners, process that lives in the system rather than in individuals.

That is not a binder and it is not a slide deck with a maturity curve on it. It is a company where, months after the engagement ends, decisions get made by the right person without you in the room, and the business does not visibly slow down when you take a real vacation.

Most companies below the scaling ceiling never needed this in the first place. The scaling ceiling is the point at which the complexity of a business exceeds the capacity of the informal system running it, set by operational complexity rather than revenue. That is exactly the point where an entrepreneurial operating model, one that runs on proximity, fast, no overhead, hard ceiling, stops being sufficient. Transformation is the deliberate act of replacing it with something built for the size the company has actually become.

Below that ceiling, transformation is usually the wrong purchase. A company that has not yet outgrown proximity does not need a rebuilt operating model, it needs someone to stop confusing normal growing pains with structural failure. Part of our job is telling a CEO that they do not need us yet, which is a harder sentence to say out loud than it sounds.

The work starts with decision rights, not with systems.

Every transformation engagement we have seen fail started somewhere other than decision rights. Usually it started with software, because software has a demo and a decision rights exercise does not.

Decision concentration, decisions queuing behind one person because they are the only one permitted to make them and not the only one capable, is the first thing that has to change. It has to change before anything else, because you cannot install a system on top of a decision structure that does not exist yet. There is nothing there for the system to enforce.

This part of the work looks unglamorous from the outside. It is a category by category list of decisions, an owner assigned to each one, and a leadership team willing to let that owner get a decision wrong occasionally rather than take it back. That last part is the one most executives underestimate going in.

This is also usually where a founder has to choose between being the owner or the expert, the forced choice between doing the work and building the thing that does the work, since you cannot hand off a decision category and keep making the calls yourself out of habit. Most of the mechanical work in a transformation engagement is downstream of that one choice.

Process comes second, and it has to live in the system, not in people.

Once decision rights are real, the next deliverable is process that survives a departure. Process dependency, processes that exist in individuals' memory rather than in the system, measured by what breaks if a named person leaves, is what transformation is directly trying to eliminate.

Documenting a process is not the same as building one that actually lives in the system. A written procedure that only one person follows is process dependency with better paperwork. The test is the same one we use for decision rights. Does it survive that person taking a different job next month.

This is also where most of the actual hours in an engagement go, and it is the least visible part of the work to anyone outside the company. Nobody notices process that works. Everybody notices process that breaks.

Systems and reporting come last, and only after the first two are real.

CRM, ERP, dashboards, and automation belong at the end of transformation, not the start, because a system can only enforce a structure that already exists. Buy the system first and you get an expensive way to store the same chaos, now with a login.

This is the order we hold clients to even when it is uncomfortable. A CEO who wants a new CRM in month one usually has a decision rights problem wearing a software costume, and installing the software first just gives that problem a longer runway before anyone diagnoses it correctly. We would rather lose that piece of business than sell a system into a structure that is not ready to use it.

Once decision rights and process are real, systems become genuinely powerful, because they are finally enforcing something true. That is the order operational transformation runs in, every time, regardless of industry.

You know transformation happened when the company runs without you in the room.

The actual test is not a document, a signed off framework, or a new chart on the wall. It is whether decisions still route through you out of habit, or whether they route to the person who now actually owns that outcome.

Take a real week off, not a working vacation with your phone on the nightstand, and watch what happens. If the business runs at the same pace it does when you are there, the operating model has actually changed. If it visibly slows down, the transformation produced artifacts, not the thing itself.

What built the company got you here. It will not get you through this.

That is not an insult to what you built. The entrepreneurial operating model was the right tool for the company you had, and most of what got you this far worked for real reasons.

Operational transformation is the deliberate, unglamorous work of building the thing that replaces it, in the right order, with a result you can actually test.

What CEOs ask us about this

What is the actual deliverable of an operational transformation engagement?
A working operating model: decision rights assigned by category, process that lives in the system instead of in people, and reporting that enforces both. Not a strategy document. A company that runs differently by the end.

How is this different from hiring someone to fix one broken process?
Fixing one process treats a symptom. Operational transformation rebuilds the mechanism, starting with decision rights, that produced the broken process in the first place, so the same failure does not reappear somewhere else six months later.

Do we need new software to go through this?
Usually not at the start, and sometimes not at all. Systems come last in the sequence, after decision rights and process are real, because a system can only enforce a structure that already exists.

How long does operational transformation actually take?
Long enough that anyone promising a fast fix is selling you a document, not a result. The honest answer depends on how many decision categories and processes are actually broken, but the sequence itself, rights first, then process, then systems, does not get shorter.

An Operating Model Is Not an Org Chart

sal@debsan.co (Sal Brucculeri) — Mon, 07 Sep 2026 12:17:01 GMT

Ask ten CEOs what their operating model is and eight of them will pull up an org chart. The other two will show you a process map nobody has opened since the day it was drawn. Neither one is an operating model, and the gap between what they think they have and what they actually have is bigger than most of them realize.

This is not a semantic argument. A company can have a clean org chart, a fully documented set of processes, and still have no functioning operating model at all. We see it constantly. The paperwork exists. The behavior it is supposed to describe does not.

That confusion is not free. Companies buy software, hire consultants, and redraw boxes on a chart to fix a problem that was never a structure problem in the first place.

An operating model is how decisions get made and information moves, nothing else.

Strip away the consulting language and an operating model is simple. It is the actual mechanism by which a decision gets made, who is allowed to make it, and how the people who need to know find out. That is the entire definition.

Everything else, the org chart, the process documentation, the software stack, is an artifact that describes or supports that mechanism. None of those artifacts is the mechanism itself. You can change every box on an org chart and leave the way decisions actually get made completely untouched.

This is why reorganizations so often change nothing that matters. The names on the boxes moved. The way a decision actually travels through the company did not.

An org chart tells you who reports to whom. It does not tell you who decides.

An org chart answers one question: who is whose boss. It does not answer who can approve a discount, who can greenlight a hire, or who gets consulted before a customer commitment changes.

Those are the questions that actually determine whether a company runs well. A manager can sit three boxes up from the front line on a chart and still have zero real authority, because every meaningful call still routes to the owner's desk before it becomes final.

That is decision concentration, decisions queuing behind one person because they are the only one permitted to make them, not the only one capable of making them. It shows up on no org chart anywhere, because an org chart was never designed to capture it.

A process map documents steps. It does not say who is allowed to change them.

A process map is a snapshot of how work is supposed to flow on a good day. It is genuinely useful for training and for spotting obvious bottlenecks. It was never built to answer the harder question underneath it.

Who owns this process. Who can change it when it stops working. What happens when two departments each think they own the same handoff and both are technically right.

A process map without a named owner just becomes a historical document, accurate on the day someone drew it and quietly wrong six months later. Nobody updates it because updating it was never anyone's job. That is process dependency in a different costume, processes that exist in individuals' memory rather than in the system, measured by what breaks if a named person leaves. A document does not fix that. It just moves the same fragility somewhere less visible.

Every company runs on one of two operating models, whether anyone chose it or not.

The first is what we call an entrepreneurial operating model, an operating model that runs on proximity. Information moves because everyone can see everything. It is fast, it carries no overhead, and it has a hard ceiling.

Small companies run on this by default, and it works well for exactly as long as one person can hold the whole business in their head. Nobody designed it. It is just what happens naturally when a handful of people sit near each other and talk constantly.

The second is a scalable operating model, an operating model that runs on structure, decisions owned by outcome owners, process that lives in the system rather than in individuals. Nobody drifts into this one by accident. It has to be built on purpose, which is precisely why most companies never get past the first model even after they have badly outgrown it.

You can diagnose which model you are actually running in one afternoon.

Pick five decisions that happened in the company last week. For each one, ask who actually made the call and how the people affected by it found out. Not who was supposed to, according to the chart. Who actually did.

If the honest answer keeps landing on the same one or two names regardless of what the org chart says, you are running an entrepreneurial operating model with a scalable operating model's paperwork sitting on top of it for appearances. That mismatch is more common than either version running cleanly on its own.

Most leadership teams find this exercise more uncomfortable than they expect. The chart says one thing. The actual behavior of the company says another. Only one of those two is true.

Fixing the mismatch starts with decision rights, not with a new chart.

The instinct, once a company sees this clearly, is to redraw the org chart or rewrite the process documentation. That treats the artifact as the problem. The artifact was never the problem. It was just the thing that made the real problem visible.

The actual fix is naming, category by category, who owns which decisions, the same discipline behind moving a founder from owner or expert into actually building the thing that decides, and building the reporting and cadence that lets them own it without routing back through the founder for approval. This is most of what an engagement with us actually looks like, and it is also the part almost nobody wants to do first, because a new chart feels like progress and reassigning real authority feels like risk.

Once decision rights exist on paper and in practice, the org chart and the process map become useful again. They describe a mechanism that is actually running the way they say it is, instead of describing an intention nobody enforces.

The chart was never lying to you. It was just never the thing you needed to fix.

None of this makes an org chart or a process map worthless. Both are useful artifacts once the actual mechanism underneath them is real.

They just were never going to fix anything on their own, because they were never the thing that was broken.

What CEOs ask us about this

Isn't an operating model just another word for our processes?
No. Processes describe steps. An operating model describes who decides, who owns the outcome, and how information reaches the people who need it. A company can have excellent process documentation and a completely broken operating model.

How do I know if my operating model is entrepreneurial or scalable?
Trace five real decisions from last week back to the person who actually made the call, not the person the chart says should have. If it keeps landing on you or one other person regardless of the org chart, you are still running an entrepreneurial model.

Do I need to redesign my org chart to fix this?
Usually not first. Redesign decision rights first, then let the chart and the process documentation catch up to reflect what is actually true. A new chart on top of the old decision pattern just relabels the same bottleneck.

Can a small company have a scalable operating model?
Yes, and the ones that build it early scale further before they hit real trouble. Size determines when the entrepreneurial model stops working. It does not determine when you are allowed to start building the one that replaces it.