How we get twenty years of judgment into one conversation
Our operators do not arrive knowing your business. It has to learn it, and most of what it needs to learn was never written down.
That is the real problem with putting AI onto operations work. Connecting to the systems is the easy half. The part that decides whether an operator works is the reasoning your team carries around in their heads. Which customer tolerates a late delivery but not a surprise. Which contractor answers on WhatsApp and never by email. Why nobody trusts the sensor data on Line 4. None of that is in any system, and if you ask people to write it down they struggle, because they stopped noticing they knew it years ago.
So onboarding is built around one idea. Work out everything that can be worked out without asking. Then spend the conversation only on what is left over.
What is left over is the tacit knowledge. That is not a soft way of describing it. It is a working definition: the part of how a business runs that its own records cannot account for. Six stages, and the first four exist to find it.
1. Before anyone speaks to you
Cody is the agent who runs the call. Before it happens, he reads everything publicly available about the company and builds his own picture of the operation.
Corporate filings. News and press. Industry reports. Competitor positioning. The regulatory environment you work under. Whatever operational or financial data is in the public record. The technology he can detect that you run. The profiles of the specific people who will be on the call, so he knows who he is talking to and what they are likely to own.
And your open job postings, which tend to be the most honest document a company publishes about itself. A role that has been open for seven months is not a recruitment problem. It is a description of work that is not getting done, written by the people it is not getting done by.
This asks nothing of you and it finishes before the first conversation. The point is that the call does not start with an hour of background.
2. Cody connects to your systems and maps how work moves through them
Ideally this happens before the call. Otherwise it happens live during it.
Cody connects to the systems you already run and builds a map of how work actually moves across them. Where a job originates, what happens to it next, which system it passes into, who touches it, where it stops. Not the process as described in a document. The process as the records show it happening.
On one freight operation that meant five systems: a Cargowise TMS holding shipment records and carrier assignments, an ERPNext instance holding billing, carrier portals, customs portals, and the email logs where most of the actual negotiation lived. On a brokerage it looks different again, and usually less tidy. A TMS, a tracking system, the planning spreadsheet nobody is going to give up, the phone system, and a shared inbox. All of it counts. The spreadsheet often counts most, because that is where the judgment has been quietly accumulating.
Nothing is migrated and nothing is restructured. There is no new system of record, and your team does not stop working while this happens.
How that map gets built is the one part of this we do not publish.
3. Cody works out what he cannot explain, and asks about that
This is the stage that matters, and it is the one most people get backwards.
A map of how work moves tells you what happened. It does not tell you why. Two loads arrive looking identical and get handled differently. An exception sits for a day and an identical one is cleared in ten minutes. A rule is followed ninety times and broken on the ninety-first. In every one of those cases somebody exercised judgment, and the reason is not in the data.
Those are the gaps. Cody works out where his own understanding runs out, goes deep on the pain points behind them, and builds his questions from there. Then he sits down with your team and asks.
One session, one to three hours, three to six of your people, deliberately mixed across seniority so you get both the strategic view and how things actually work. It is a conversation rather than a questionnaire.
Nobody is asked to explain their job. They are asked to explain the decisions their own systems cannot account for. That is a much shorter conversation and a far more valuable one, and it is why three hours is enough. The answers sound like this:
When a supplier is more than 48 hours late on a critical component, we call the plant manager directly.
If downtime is going to cost more than $5,000 an hour, the VP gets called whatever the time zone.
That supplier has a relationship with our CEO, so we never hard-escalate.
We tried automating this three years ago and it failed, because the sensor data on Line 4 is unreliable.
That is the institutional knowledge that lets a business function. It is also the thing that walks out of the door when someone retires, and the reason a new hire takes most of a year to become useful. Getting it into a form an operator can act on is the whole exercise.
4. Cody turns it into a report you can argue with
Everything from the first three stages comes back as a strategic report, 30 to 50 pages, closer to a consulting deliverable than to software documentation.
It contains visual diagrams of how your operation actually runs, drawn from your own systems rather than from what anyone believes is happening. It names where work is leaking: the rework, the double entry, the exceptions that get worked twice, the time going into cases that never needed a person. And it names where the opportunity is, ranked.
Then Cody puts up a set of operators he thinks are worth building, each one attached to the findings that justify it, with forecasted return in both money and hours.
Every number in it is sourced, to the session transcript, to your live system data, to public research, or to a previous deployment. Projections are labelled as projections. Nothing is invented. That matters more than it sounds, because a report full of unsourced numbers is a document you have to take on faith, and this one is meant to be a document you can push back on.
5. You choose the operators, and they go live under guardrails
You pick which ones you want. The platform configures them and puts them live on your existing stack within 24 hours of the onboarding call.
Live does not mean loose. An operator starts in calibration, working real cases and proposing real actions while executing none of them. Your team reviews each proposal and does one of three things: approves it, denies it, or changes it and says why. Those three responses are the training signal, and the modifications are the valuable ones, because that is where the reasoning nobody ever wrote down finally makes it into the record.
On the coldest start we have measured, with no prior exposure to the operation and no tuning window, an operator agreed with the human team on 82% of 143 exceptions in its first week. We published that test in full, including the 18% it got wrong. Treat it as the floor rather than the average. Deployments since have exceeded it materially, because every deployment leaves capability behind that the next one starts from.
Accuracy climbs from there, and it climbs on your operation specifically, because the corrections it is learning from are your team's.
6. It graduates to running the role on its own
Typically three weeks to a month, an operator reaches full autonomy on the role it was built for.
It does not get there because a month has passed. Graduation requires four things to be true at once: the integrations are reliable, it has seen a broad enough range of real cases, its decision quality holds up, and every issue logged during calibration has been closed. All four, and none of them can stand in for the others. A high approval rate across a narrow slice of cases is not the same thing as being ready, which is why coverage is tracked separately from quality.
Autonomy is measured over the whole role, spanning the TMS, the ERP, the portals, email and phone, rather than over one channel. And it is scoped to that role. The decisions that carry real liability stay where you want them: the thin-margin quote, the customs classification where being wrong means a hold or a fine, the relationship that needs an actual conversation. Full autonomy on a role does not mean nobody is accountable for anything. It means the work that never needed a person stops taking one.
What your team actually has to do
It is a short list. Connect the systems. Put three to six people in one session of up to three hours. Review proposals through calibration. We have written separately about what you need in place before any of this starts, and the honest answer is less than most people expect.
There is no documentation exercise to run first. No data cleanup project. No migration. If you are waiting until your systems are tidy before you look at this, the waiting is the expensive part, because the map is built from your operation as it is rather than as it should be.
What you get at the end of it is an operator that runs a role the way your team runs it, because it was built from how your team runs it. This is what that looks like across a full day on a freight desk.
Start with one role
It begins with one session and a connection to the systems you already run. Book a demo and we will work out which role has the most to gain, and what the first few weeks would look like on your own data.