The AIM Framework

Most organizations have a formal version of their workflows — the org chart, the documented SOPs, the onboarding materials — and a real version. The real version is what your team actually does, including the exceptions, the workarounds, the tribal knowledge, and the informal handoffs that never made it into any documentation.

The Assess phase closes that gap. Through structured interviews and direct observation of the people closest to the work, we develop a detailed picture of how workflows actually flow — what triggers each process, what information each step requires, who makes decisions and on what basis, and where things most often fall through the cracks.

This is the most important phase and the most commonly skipped. Organizations that automate without assessing first are automating their assumptions about the work, not the work itself. The resulting systems encounter edge cases immediately and handle them badly.

Not every workflow is worth automating. The Identify phase scores the workflows from the Assess phase against three criteria to find the right starting points.

Impact measures what solving this workflow problem is worth — time saved, cost reduced, quality improved, or revenue accelerated. Feasibility measures how well-suited the workflow is to automation: is it high-volume? Are the rules consistent? Are inputs and outputs well-defined? Readiness measures whether the organization can actually absorb the change — team capacity, decision ownership, and appetite for the process to change.

The intersection of high impact, high feasibility, and high readiness is the right starting point. It is almost never the most technically interesting problem or the one that gets mentioned first in the kickoff meeting. Finding it requires the work done in the Assess phase.

With the right opportunities identified, the Map phase designs the future-state system in enough detail to inform build decisions, vendor selection, and team communication — before any code is written or tool is purchased.

A Map deliverable is not a slide deck. It is a specification: trigger logic, data flow, integration architecture, human checkpoints, edge case handling, and failure modes. It describes what the automated workflow does at each step, what a human reviews before an output becomes operational, and how the system handles exceptions.

The Map phase also specifies the implementation sequence — which pieces get built first, what dependencies exist, and how the system is designed to accommodate future extensions without requiring a rebuild. This is the architectural foresight that prevents the fragile, unmaintainable automation stacks that are common in organizations that built without a design phase.