What the first weeks ask of your team
The first weeks ask your people who do the work to walk us through the job as it actually runs. That walkthrough, including exceptions and workarounds, is what makes the build useful. Watching the job first is faster than writing something that claims to do it.
You control budget, time, and access to records. You do not control IT, security, or purchasing. This post is for the person who runs the work, not the person who will later read a technical note.
What we need to see
We need time with the people who already know the job. Not a slide deck. Not the policy binder. The run as it happens on a normal day.
That includes the leasing manager who holds the lease rider until a clause is checked. It includes the dispatcher who waits on a late goods receipt. It includes the front desk at nine in the evening, when the transporter's evening spreadsheet is the only source that still matches the floor.
Name the exception at the same time you name the rule. An exception, meaning a case that leaves the written process, is where a system usually fails. If we only see the happy path, we will write to the happy path.
An illustrative walkthrough of the work today
This scene is illustrative. A clerk opens the day's list and pulls each goods receipt against the purchase order. Most lines match. A few do not. The clerk checks the transporter's evening spreadsheet, calls the warehouse, and writes a note in the ERP. The dispatcher will not release the next load until that note exists. The leasing manager is not in this loop, but the same habit shows up on a lease rider: hold the file, ask a person, then record the answer.
Nobody writes a new rule for this. They already have a workaround. The workaround is the job.
The same walkthrough with a system in it
This scene is illustrative. The clerk still opens the day's list. The system, meaning the software we would put next to that list, drafts a match from the goods receipt and the order. The clerk still sees the mismatch. The draft is wrong when the spreadsheet and the ERP disagree. The clerk keeps the call to the warehouse. The note still has to land where the dispatcher looks. If the note is only in the new screen, the load still sits.
The system does not remove the judgement. It sits where the judgement already happens. If we never watched that desk, we would put the draft in the wrong place, and your people would keep the spreadsheet anyway.
Why the walkthrough comes before writing
The fastest way to build something useful is to watch the job before writing anything that claims to do it. A written process hides the hold, the call, and the second source. Those are the parts that decide whether a clerk trusts the next screen.
The engineering behind this is the same discipline used when a pilot is allowed to fail: you learn from the live run, not from a promise on paper. Read how to run a pilot that can fail safely if you will forward a note to someone who wants that argument in full.
You can test the claim at your own desk. If the people who do the work cannot show the exception in the same hour they show the rule, we do not yet know the job.
What this does not solve, and what it will demand
A walkthrough does not replace security sign-off. It does not replace a connection to your ERP, meaning the link that lets records move between systems you already run. It does not decide budget. It does not pick a vendor. It does not promise a go-live date.
It will demand access to the people who run the work, not only the people who own the policy. It will demand that someone can open a real file, a real list, and a real workaround. It will demand that you say which records may be seen and which may not.
If fixed rules can do the job, compare ordinary automation with a language model using the full implementation and operating cost. The walkthrough is how you find that out before anyone writes code.
A meeting you can run with no engineer in the room
Use this list in a short meeting with the people who do the work. Write answers in their words.
- Which document starts the job on a normal day?
- Who touches it next, by role, not by title on an org chart?
- Where does the file wait, and who is allowed to release it?
- What do you open when the official system is wrong or late?
- Name one exception from this week. Who handled it, and where did the note go?
- If a new screen drafted the next step, where would you need to see that draft to trust it?
- What must never leave the building, even as a sample?
If the room cannot name the workaround, you are still describing the policy. Stay in the room until the workaround has a name, a person, and a place.
How to judge whether the first weeks were used well
You will know the time was used well if the next conversation is about a specific desk, a specific document, and a specific hold. You will know it was wasted if the next conversation is about a generic "workflow" with no clerk, no goods receipt, and no evening spreadsheet.
Do not measure the first weeks by how much was written. Measure them by whether the people who do the work would recognise the description.
If they would not, we watched the binder, not the job. Then we should watch the job again before anyone claims the system can do it.