How an engagement starts
It starts with a conversation about the work you already run, not a requirements document. The person who runs the desk sits down with the partner. You walk through a real day. You name the documents, the handoffs, and the moments that stall. Nobody asks you to write a specification first.
That first talk is about the work and what is possible. It is not a pitch. The honest result can be that there is nothing worth building yet. If fixed rules can do the job reliably, compare ordinary automation with AI before choosing the approach. Use the full cost of implementation, review and maintenance. Say that in the room if it is true.
What you look at together
You look at what people already do. The leasing manager walks a rider before a signature. The dispatcher matches a load against a transporter's evening spreadsheet. The front desk at nine in the evening still chases a goods receipt that never hit the system. Those are the particulars. If you cannot point at one of them, you are not ready to scope a build.
You agree what is worth building. Worth means the job still needs judgement, the records exist, and a wrong answer can be caught before it ships. For the arithmetic behind that cut, see when a business should use AI. You do not need to read that page yourself. Forward it if someone else has to sign off.
Then you agree a scope for a first build. Scope is the slice of work you will put in front of the people who do the job. It is not a catalogue of every pain on the floor.
How the work is done
Engineers go on it. They work on site where that helps. They work by call where it does not. On site helps when the job lives in a stack of paper, a side spreadsheet, or a habit no ticket describes. A call is enough when the records are already on a screen and the people who use them can share that screen.
A working version is put in front of the people who do the job. Not a slide. The leasing manager tries the rider. The dispatcher tries the evening list. The front desk tries the late receipt. They say what is wrong. That feedback is the next version. Then you do it again.
Nothing in that sequence promises a result. A first version can prove the work is not worth more time. That is a valid stop.
What this does not solve
This does not get you IT, security, or procurement sign-off. You still have to ask for access to records. You still have to free people's time for the first look and the feedback. You still have to live with a no from the first conversation.
It will not replace a process you have not named. It will not run if the only copy of the truth is in one person's head and they will not sit down. It will not move if you cannot put a working version in front of the desk that owns the job.
Questions for a meeting with no engineer present
Take this list into a meeting with a partner. You do not need an engineer in the room. Listen to the answer. A good answer is specific to your desk. A bad answer hides behind a document you have not written yet.
What work will you look at first? A good answer names a role and a document: the dispatcher and the evening spreadsheet, or the front desk and the goods receipt. A bad answer talks about use cases and asks you to send a requirements pack before they will look.
What would make you tell us not to build? A good answer is plain: the job is already a rulebook, the records are missing, or a wrong answer cannot be caught. A bad answer says everything is a fit if you buy enough time.
How do we agree the first slice? A good answer is a scope you can read in one sitting: who does the job, which record they touch, what done enough to try means. A bad answer is a roadmap with named stages and a calendar you did not ask for.
Where will the engineers sit? A good answer: on site when the work is paper, a side list, or a habit you cannot describe on a call. By call when the records are already on a screen. A bad answer: always remote, or always in your building, with no reason tied to the job.
Who sees the first working version? A good answer: the people who do the job, in the week they actually do it. A bad answer: a steering group, a demo to leadership, or a report instead of the desk.
What happens after they say it is wrong? A good answer: their notes become the next version, or you stop. A bad answer: a change request process, or a claim that the first version was the product.
If the first conversation finds nothing worth building, what do we walk away with? A good answer: a clear no, and the reason, in writing you can keep. A bad answer: a paid next phase because the conversation happened.
What you can do this week
Pick one job. Name the person who does it. Name the document they touch. Sit with them for one real instance, as long as that instance takes. Write down the stall in their words. Take that note, and the questions above, into the first conversation. If the partner will not talk about that note until you produce a requirements document, they are not starting with the work.