713-936-9339
Insights

You'd notice a bad hire in a month. Would you notice a bad bot?

Most operations don't break all at once. They drift.

Crystal LaShay Crystal LaShayPrincipal, CorporateLounge, 7 minute read

A step gets skipped here. A workaround becomes the real process there. Nobody notices for months because a person is still in the loop, catching the small things before they become big ones.

Automation can remove that safety net faster than most organizations realize.

It doesn't notice when something looks wrong. It doesn't pause. It doesn't ask a colleague, "How do we normally handle this?"

It does what it was built to do. At full speed.

If the job was never properly defined in the first place, automation won't figure that out for you.

You wouldn't hire this way. Why deploy this way?

Bringing on a new employee requires some basic discipline.

  • A defined role
  • Someone accountable for the work
  • Deliberate access to systems and information
  • Clear boundaries around what the person can decide
  • A way to tell whether the work is being done well

Now imagine skipping all of that. The person shows up, gets broad system access on day one, and starts making decisions without anyone being quite sure what they are actually authorized to do.

No serious organization would operate that way. Yet it is surprisingly close to how some automations enter operations today.

Connected first. Defined later. If ever.

A new employee will usually recognize when something doesn't make sense. They ask a question. They flag an exception. They escalate uncertainty.

Automation won't. It will execute the process it was given, including the parts nobody bothered to fix. It can do that consistently, quickly, and for months before anyone realizes something is wrong.

That is why I believe there should be a simple standard for automation.

An automation should hold no more authority than you would give a person doing the same job.

That is the standard.

The same discipline, applied to a new risk

The fundamentals haven't changed. Standardize before you automate. Control the work as it moves. Know where it slows down. Define who owns it from beginning to end.

This is the same operating discipline we have applied across process engagements for years. What has changed is what we are applying that discipline to.

Before moving forward with automation, I want straightforward answers to a few basic questions.

  1. 01Is there actually a defined job to automate?
  2. 02Who owns the outcome?
  3. 03Can the system reliably access the information required to do the work?
  4. 04What is the automation allowed to decide on its own?
  5. 05Who supervises it?
  6. 06Who answers when it gets something wrong?
  7. 07Would anyone notice if it quietly started doing the job badly?

That last question deserves more attention. Automation doesn't have to fail spectacularly to create risk. It can simply be wrong in small ways, repeatedly, without anyone watching closely enough to notice.

That is a very different risk profile from having a person in the process.

Readiness is not an enterprise-wide score

I don't believe automation readiness should be treated as a single organizational grade. A company can be ready to automate one process and completely unprepared to automate the process sitting next to it.

Readiness is a condition of the work, not a label for the organization.

That thinking led us to develop the Automation Fitness Review™. We evaluate one process at a time and answer one question. Is this process fit to be automated? The verdict is deliberately simple.

  • FITThe process has the operating conditions required to move forward.
  • CONDITIONALLY FITThe process may be a good candidate, but specific conditions need to be addressed first.
  • NOT FITAutomation should not move forward for this process in its current state.

A Conditionally Fit finding isn't a failure. It may be the most valuable answer.

Think about hiring. If you want to hire someone for a role that hasn't been defined, the answer isn't to hire faster.

Define the job first. Then hire. Automation deserves the same discipline.

The recommendation is the product

The purpose of the Automation Fitness Review™ isn't to produce another maturity score that looks impressive in a presentation but doesn't tell anyone what to do next. The purpose is to make a decision.

For the process being evaluated, leaders should walk away knowing three things.

  • Whether the process is fit for automation
  • What evidence supports that conclusion
  • What needs to change before automation should move forward, if anything

The recommendation should be able to stand up to leadership, board, audit or compliance scrutiny.

We don't build the automation. We don't sell a platform. We don't recommend a vendor.

That is deliberate. If the process isn't ready, there is no upside for us in telling you that it is.

What this looks like in practice

Consider a hypothetical public agency evaluating automation for incoming service requests.

Receive the requestDetermine where it belongsRoute it to the right department

The process looks automatable. It isn't ready.

Look underneath the workflow

  1. The employee currently handling those requests has been making judgment calls for years based on experience, not documented rules. Her exceptions aren't written down.
  2. No one else can fully explain how she makes those decisions.
  3. No one has been formally identified as accountable when a request is misrouted.
  4. The system feeding the proposed automation doesn't consistently contain accurate data.

Automating it wouldn't solve those problems. It would remove the human judgment currently compensating for them and execute against the weaknesses at scale.

The right verdict is

CONDITIONALLY FIT

The work required to change that verdict might be straightforward

  • Assign process ownership.
  • Establish accountability for errors.
  • Document the decision rules and exceptions.
  • Improve the reliability of the underlying data.
  • Reassess the process for automation.

Six months later, that same process may be Fit. Readiness isn't permanent. It is a condition of the work.

The risk looks different depending on where you sit

  • Public sector and higher educationGovernment agencies and higher education institutions don't get to quietly walk back a public misstep. A flawed automated decision can become a finding, a complaint or a headline. Public trust is on the line.
  • NonprofitsTeams are lean, resources are constrained, and one bad automated decision can land directly against the mission.
  • Corporate and enterpriseCorporate and enterprise organizations carry their own version of the risk through customers, regulators, boards and leadership.

Different environments. Same underlying question.

Before this goes live, can you say exactly what the automation is allowed to do and exactly who is accountable when it doesn't do it correctly?

If the answer isn't clear, the technology isn't the problem. The operating environment isn't ready.

Where to start

You don't need a fully formed AI strategy to start this conversation. If an automation or AI proposal is already sitting on your desk, start there. Ask whether the process is actually ready for what you're about to automate.

Or start with one process you've already been considering.

One process. One evaluation. One decision. That's enough.

Because automation readiness isn't about being "AI mature." It is about knowing whether the work is ready to be trusted to a machine. That is a much more useful question.

Don't automate what you haven't learned to operate

This isn't an argument for slowing down automation. It is an argument for being disciplined about what you automate.

Automation doesn't create operational reliability. It reveals whether it was there in the first place.

If the process is strong, automation can extend its reach. If the process is broken, automation can make the brokenness faster, more consistent and much harder to see.

So before you ask, "Can we automate this?", ask the more important question. "Would we trust a new employee to do this job on their own?"

If the answer is no, don't give the bot the job yet.

Is this process actually ready for what you're about to automate?

The Automation Fitness Review™ evaluates one process and gives you a verdict you can defend, in two to three weeks.

Related