The questions your last software vendor didn’t ask.

As an executive leading a transportation/logistics company…

How do you go about digitally transforming your business?

You spot a gap in your process, something that can be automated, a piece that could significantly elevate your customer experience. You come up with the overall vision and requirements, and then what?

How do you go about delegating to the tech team? In-house or outsource?

And how do you convey your ops knowledge to a team that doesn’t live it on a daily basis?

As it turns out, building the software isn’t the real challenge.

It’s understanding what the system is supposed to do. Which data matters. Real-life limitations that operators may experience.

Not the features. The facts.

Which trucks can take which loads. Who is allowed to drive what. What goes wrong in a normal week, and what it costs when it does.

A trucking company came to us a few weeks ago at exactly that point.

We could’ve quoted it. It’s not a hard system to describe in a proposal.

Instead, we sent them a document with about sixty questions and asked them to answer whatever they could off the top of their head. Approximate numbers welcome. «Around three a month» is worth more to us than an exact figure someone has to dig for.

Discovery questionnaires aren’t a new invention. Every decent analyst has some version of this, and the format has been in the business-analysis playbook for decades.

The interesting part is which questions are in it.

What we ask a trucking company before we quote anything

Coordination first. How many people coordinate trips, how many trips a day, how many Whatsapps and calls it takes for one trip to leave and arrive cleanly. What is the most repetitive thing in a day. And the one that tends to go quiet in the room: what happens when the coordinator is out sick. Can anyone else do it.

We also ask for the scheduling spreadsheet. Messy is fine. Messy is better. A real Excel file tells us more about how a company works than an hour of describing it.

Then trucks and drives. Do all trucks serve all trips. Can every driver drive every truck. Who is credentialed for hazmat, drives and trucks both. Who can cross borders into another country, and with what documentation. How do you track expirations today: licenses, permits, insurance, technical inspection.

And then: has a trip ever failed to leave because something was expired.

Assignment is where fleet software quietly dies. If the system can dispatch a truck the driver is not certified for, nobody trusts it by month two, and the coordinator goes back to the spreadsheet they can see all of at once.

Then the shape of the year. How far ahead do you know what freight you will have. Is there any way today to see committed load two or three weeks out, or is it discovered as it goes. Are these seasons much heavier than others.

That last one is not small talk. Harvest season, for instance, is the difference between a fleet that looks right-sized in March and one that is renting third-party trucks in November. Build capacity views off the quiet months and the system is useless exactly when it matters.

Then the delivery note, which is the block we press hardest on. How many times a month does a truck reach its destination and come back with the goods still on it. What does that lost trip cost, between fuel, driver and a truck-day. How does the signed note get back to the office, how long does it take, and what happens when it’s lost or illegible.

Then the question that decides the whole scope: if the client knew what was loaded and when it arrives, from the moment the truck leaves, would that solve it, even if the paper document still shows up later.

A yes there is a notification feature. A no is a document workflow with signatures and custody. Same complaint, two projects an order of magnitude apart in cost. Nobody volunteers that distinction. You have to ask for it.

Then equipment, which decides what is buildable at all. Do all drives have a smartphone with data, and is it theirs or the company’s. Would they mark load and delivery from the phone, and how do you honestly think they would take it. Which GPS and telematics platforms are in place, is there a web login, does anyone know whether it connects to anything else.

And the last one, which is the most important: if in six months this is running and we ask you whether it was worth it, what would have to have happened for the answer to be yes.

What a copy of this list does not get you

Take the list. Genuinely.

A competent analyst could draft something structurally similar without ever having run a trucking project, and today an LLM will produce a plausible version in a matter of minutes. The document is not the asset, and pretending otherwise would be an odd thing for us to argue right after publishing it.

What does not transfer is the weighting.

In the version we sent, some questions carry a star. If they answer only those, we can still write a useful proposal. The starred ones are the ones whose answers have decided whether past projects landed where we said they would: how many people coordinate, the lost-trip count and its cost, the «would early visibility solve it» question, committed load two weeks out, fleet growth, whether drivers have phones and would use them, who approves, and the six-month one.

Three of those stars have nothing to do with the software.

Fleet growth, who approves, and the six-month question tell us whether there is a project here at all, how big it gets, and who can say yes to it.

That is qualification, not discovery, and it’s in the same document on purpose. A list that only scopes the build tells you what to quote. It does not tell you whether the thing is worth quoting, or whether the person answering it is the person who decides.

The star is not reasoning. It’s a symbol. Behind it is having watched those answers matter, and having been wrong about them before.

Same with what happens after an answer comes back. «A few times a month» on lost trips is where the conversation starts, not where it ends. So is «the drives will be fine with it,» which is the answer we hear most often and take at face value least.

Why we build the questions instead of the feature list

This is one of the five pillars of The Leverage Method: deep industry fluency beats hiring for tech stack alone.

It sounds like a hiring slogan. In practice it looks like a document.

Fluency is why we ask about hazmat credentialing before we ask about the tech stack. Why seasonal freight swings show up in a scoping conversation at all. Why the delivery-note question is phrased as a counterfactual instead of «tell us about your document problem.»

A team without that history is not incompetent. They will just discover these things mid-project, which is a nicer way of saying the client discovers them in change requests, with the budget already committed.

So what happened

Nothing yet.

The answers haven’t come back. They told us they have a lot going on right now.

There is no quote. There is no price. That is what the document was for, to understand their situation without first putting them through a month-long paid consultancy.

So we wait.

The questionnaire cost them an afternoon, and costs us nothing to wait on. The alternative was a discovery engagement somebody has to pay for before anyone knows whether the project is even the right shape.

Waiting is what the cheap instrument buys you.

If you run a fleet, you can use the list above without us. Answering it honestly will tell you where your operation actually leaks, whoever ends up building the software.

And with that, my question to you is: