04 — AI & INTELLIGENT OPERATIONS

MULTIPLYING ORGANIZATIONAL CAPABILITY THROUGH TECHNOLOGY

Technology rarely fails because of the technology.

Across every transformation I've led, the software, the platform, or the monitoring tool was rarely the constraint. The constraint was that nobody had redesigned the workflow around it, equipped the people who had to use it, or challenged the assumption that made the original limitation feel permanent.

A remote-monitoring platform sat mostly unused for years — not because it didn't work, but because nobody had removed the one dependency creating customer hesitation, or taught the sales team to have the conversation that would resolve it. My focus is understanding where value already exists inside an organization, why it isn't being realized, and only then deciding what role technology should play in unlocking it.

PHILOSOPHY

Technology should amplify a well-designed operating model, not compensate for a poorly designed one. Business strategy, objectives, operating model, governance, process, and data all come before the technology decision — not after it.

Every system should have one clear purpose: the ERP manages accounting; it should not be forced to run operations.

And the highest return on a technology investment rarely comes from buying more of it — it comes from enabling people and fully using what the organization already owns.

MY APPROACH

The Latent Value Model

A practical sequence answering one recurring question: where does value already exist that the organization is failing to realize, and what has to change before technology can unlock it? Technology enters deliberately late.

  1. 01

    Identify where value already exists

    Look for capability the organization already owns — a monitoring platform, a licensed automation tool, historical data — before assuming something new is required.

  2. 02

    Identify why the value isn't being realized

    Diagnose the actual blocker: a missing workflow, an unaddressed objection, a skills gap, or an assumption nobody has tested recently.

  3. 03

    Challenge the assumption behind the constraint

    Ask whether the constraint is real or inherited. A rule that made sense once often has a much narrower actual cause than the story built around it.

  4. 04

    Redesign the workflow

    Change how the work happens before changing what runs it. A workflow redesigned around the real constraint often removes the need for a bigger technology investment altogether.

  5. 05

    Enable the people

    Build the knowledge, materials, and conversations people need to trust and use the new workflow — sales teams who can explain encryption, service teams who know what a notification means.

  6. 06

    Enable the technology

    Configure, connect, or introduce the technology that executes the redesigned workflow. This is the sixth step, not the first.

  7. 07

    Measure the result

    Re-measure after go-live, not just at go-live, and feed the result back into the next cycle.

Technology is step six. Not step one.

THE TECHNOLOGY LEVERAGE LADDER

Each stage of my career added a new form of leverage without discarding the one before it. AI is the fourth — and a genuinely different one, because for the first time the constraint is not execution but thinking.

01 · AUDIT

Controls

Multiplies trust — management doesn't have to verify every transaction manually.

Requires: evidence-based verification.

02 · OPERATIONS

Workflows

Multiplies consistency — hundreds of people execute the same way.

Requires: process design and standardization.

03 · RPA

Automation

Multiplies execution — repetitive steps no longer require a person.

Requires: workflow-maturity assessment before automating.

04 · TODAY

AI

Multiplies thinking — reasoning, communication, and decision support, not just execution.

Requires: capability architecture and knowledge design.

EVIDENCE IN PRACTICE

Three cases, each demonstrating a different mechanism: unlocking technology that already existed, redesigning an ecosystem instead of an application, and making adoption itself the business outcome.

CASE 01 · LATENT VALUE

When the Technology Already Worked and Nobody Used It

A remote-monitoring platform sat underused for years. Removing one dependency and equipping the sales team turned it into the foundation of a proactive service model.

SITUATION
A remote-monitoring and predictive-maintenance platform had already been deployed, capable of reporting device counters, service logs, and health data. The technology worked. Adoption did not follow. Customers were refusing to connect printers to the internet, and internal teams had no workflow for acting on the notifications the platform already produced.
DIAGNOSIS
The prevailing explanation — "customers don't want connected devices" — was treated as fixed rather than investigated. As incoming Head of After Sales Operations, I became a hands-on expert in the platform itself, reviewing training materials, technical documentation, and firmware behavior, and speaking directly with technicians, before proposing any change.
MY ROLE
Head of After Sales Operations — diagnosis, constraint redesign, cross-functional enablement, and value-chain redesign from manufacturer through to the customer's experience.
ACTIONS
Identified that internet connectivity was required for exactly one function: automatic firmware updates. Disabled that function, which removed the customer's actual security concern without limiting monitoring capability. Built enablement materials so commercial teams could explain encryption and data-security architecture directly to customer IT and procurement stakeholders. Introduced a lower-cost connectivity model using repurposed laptops from departed employees instead of new infrastructure spend.
RESULTS
Converted a mostly unused monitoring platform into an operational asset supporting proactive, preventive service; removed the leading customer objection at its root cause instead of arguing against it; delivered the improvement using assets the organization already owned, with no new capital investment.
LESSONS LEARNED
Technology rarely fails because of the technology. Adoption is an operational and communication problem before it is a technical one, and the highest-leverage fix is often a small, specific configuration change — not a bigger platform.
CASE 02 · ECOSYSTEM ARCHITECTURE

When Nine Systems Became One Operating Ecosystem

What started as a single-application rollout reaching 20% of the installed base became the redesign of an entire operating ecosystem spanning dealers, inventory, dispatch, and accounting.

SITUATION
An after-sales organization was evaluating a field-service technology initiative — mobile application, GPS, and CRM/ERP-adjacent tooling — which most stakeholders were discussing as a software selection decision.
DIAGNOSIS
Early tracking showed the initiative reaching only around 20% of the installed base. Most participants were debating whether the software itself was satisfactory. I reframed the question: if only a fifth of the operation benefits, the business case — not the software — is the actual problem.
MY ROLE
Moved from evaluating an application to architecting an ecosystem, connecting field service, GPS, inventory, spare parts, assets, dealers, ERP, and warehouse management into one designed data flow — with the operating model, not the software, as the unit of design.
ACTIONS
Established that each system should keep one clear purpose: the ERP manages accounting; the service platform manages operations, validates activity, and passes clean data to the ERP in batch, rather than forcing every operational step through accounting logic. Designed governance directly into the technology — user roles, permissions, read/edit rights, notifications, workflow status, and reporting were defined before rollout, not added afterward. Extended the design to the dealer network and dealer software vendors, aligning incentives so that dealer performance improvements produced direct benefit — which is why an external vendor agreed to build the required API.
RESULTS
Converted a fragmented, low-adoption software rollout into a connected operating ecosystem spanning field service, GPS-based dispatch, inventory, spare parts, dealers, ERP, and reporting — with governance and incentive alignment embedded in the technology design rather than layered on after deployment.
LESSONS LEARNED
Evaluate technology at the level of the operating model and the value chain, not at the level of a single application. The value is in the connections between systems, not inside any one of them — and incentive alignment across a partner ecosystem can succeed commercially even when it wasn't originally a technical requirement.
CASE 03 · ADOPTION AS RETENTION

When Adoption Became the Retention Strategy

An enterprise SaaS portfolio facing cancellation was retained not through relationship management alone, but by proving automation on the customer's own data.

SITUATION
A portfolio of 50–60 enterprise and mid-market accounts (~$2.5M ARR) — many navigating M&A, Chapter 11, or active cancellation notices — had adopted the platform's financial automation capabilities only partially, leaving reconciliation, ERP integration, and journal-entry workflows largely manual heading into renewal.
DIAGNOSIS
Low platform adoption was itself the leading indicator of churn risk. A relationship-only recovery strategy would not have been sufficient to change the trajectory of accounts already on a cancellation path.
MY ROLE
Senior Customer Success Manager, owning re-engagement and technology adoption directly for one of the highest-risk segments in the organization.
ACTIONS
Coordinated Solution Consultants, Product Specialists, and Technical SMEs to design and validate automation use cases against each customer's own live transactional data. Ran Executive Business Reviews using customer analytics to demonstrate adoption progress directly to Controllers and Finance VPs. Built structured training, governance guidance, and certification programs so customers could sustain the automation themselves after the engagement ended.
RESULTS
Retained approximately 70% of the at-risk portfolio ahead of renewal deadlines. Supported customer use cases reaching 95–98% automation efficiency in selected reconciliation and financial-close workflows.
LESSONS LEARNED
In a SaaS renewal context, technology adoption is the retention mechanism, not a supporting activity around it. The review that saved an account was never a relationship conversation alone — it was a demonstration of automation the customer could see running on their own data.

WHAT'S COMING — IN ACTIVE DEVELOPMENT

My own use of AI moved through four phases: personal productivity, decision support, knowledge synthesis, and finally capability-building. Each phase increased the complexity of what AI was trusted to help build — not just what it was asked to produce.

The AI Lab is where that fourth phase becomes visible: small, working systems built to test whether the methodology on this page holds when a machine executes it. Projects are named, documented, and published as they are built — including the ones that don't work.

SEE THE AI LAB

HOW THIS CONNECTS BACK

AI & Intelligent Operations does not replace the first three capabilities — it scales them. Governance & Risk establishes how the organization creates, protects, and can lose value. Operational Excellence improves how value is created. Customer Success ensures customers realize it. This capability increases the speed, intelligence, and reach of all three. Which is why weak processes should never be automated simply because automation is available.

The highest return on a technology investment rarely comes from buying more of it.

LET'S JOIN FORCES