The first two weeks of an AI project are not build time. They are the weeks that decide whether the build is worth doing at all.
We spend them in the business, watching the work happen rather than reading a description of it. Almost every project changes shape once we do.
Who actually touches the work
A process that looks like three steps on a whiteboard is usually seven steps across four people, two of whom were never mentioned. Until you know every pair of hands involved, you are automating a diagram, not a job.
Where the data really lives
The system of record is rarely the system people trust. We look for the spreadsheet on somebody's desktop, the shared inbox, the notes field being used as a database. That is where the truth sits, and it is what the automation has to read.
If the current process depends on one person remembering something, that is the part to fix first.
What good looks like in numbers
We agree the measure before we start. Hours returned, days off a cycle time, error rate, response time. One number, written down, so nobody argues about success later.
- Who does the work today, and how long it takes them
- Which systems hold the data and who owns access
- The single number that will show this worked
- What happens when it fails, and who notices
- Who will run it once we step back
The failure path
Every automation fails sometimes. The projects that survive are the ones where failure is visible and someone is responsible for it. We design that in before launch, not after the first bad week.
Two weeks of this usually saves a month of building the wrong thing.