The buyer already wrote the first deal: a paid audit and seven questions

The owner of a logistics company hiring for automation wrote the first deal themselves: a paid audit, and a list of seven questions. We think the reply that wins is not a pitch. It is the seven answers, in order, plus one ugly process you took to mostly automated. The question that separates the replies is the sixth: what you would need access to in your first week, before you know the business.

What the buyer wrote

On 17 September 2026 the owner of a logistics company posted a hiring brief to r/AiAutomations. It scored 28 points and drew 50 comments.

The brief does three things.

It proposes the first engagement. A paid audit: go through the company function by function, find work done by hand or across disconnected software, estimate ROI and difficulty, set priorities, and hand over an implementation roadmap. If that goes well, more work follows. The scope covers AP/AR, the inbox, customer service, quoting, shipment tracking, documents, carrier onboarding, recruiting, reporting and data entry. The systems underneath are a TMS, accounting software, email, phones and portals.

It rules out a category. A chatbot builder is not what this owner is hiring. They want someone who can learn how the business runs, find where it jams, propose the architecture, and then build it or run the build. The owner is explicit that AI is not the goal in itself.

It asks for ugliness, not polish. No generated pitch. Instead, one messy process the candidate has taken most of the way to automated.

Then the replies came in. Most of the 50 comments were exactly what the brief asked people not to send: DM notices, links to profiles, agency links, a résumé, a GitHub. By our count, only a handful of replies answered the seven points or told the owner something they didn't already know.

It is not only one buyer

Two other signals point the same way.

Buyer-side guides on choosing an AI development partner, from Golabs, Launch Day Advisors and TechMagic, tell the buyer to discount demos. The proof they tell the buyer to ask for is a system the partner has operated in production. One caveat: each guide is written by a vendor selling against "slideware" competitors. The pattern counts because it repeats across unrelated vendors, not because a buyer signed it.

Technical buyers go further. A 2026 vendor checklist for CTOs and CIOs tells them to ask for sandbox access and attack the system before they sign. OWASP published Vendor Evaluation Criteria for AI Red Teaming Providers & Tooling v1.0 on 4 February 2026, written for buyers. It followed with the GenAI LLM Top 10 2026 on 3 August 2026. The metrics buyers are told to demand are jailbreak success rate, guardrail bypass rate, hallucination frequency and leakage severity (coverage of the OWASP criteria).

A demo answers none of this. An answer to the list does.

The seven items, and what answers each

The list belongs to the buyer. The answers below are our reading of how to meet it, and they are opinion.

1. What you have personally built
   -> one or two systems, what they run on, who uses them today.
      The word to answer is "personally".

2. Real businesses you have automated
   -> the business, the process, before and after.
      Under NDA? Say so, and describe the process without the name.

3. The largest or most complex workflow you redesigned
   -> the ugly one. Steps before, steps after,
      and what a human still does.

4. Preferred stack
   -> your stack, plus what of theirs you would keep.
      A working TMS and accounting system stay unless there is a reason.

5. Architecture AND implementation?
   -> yes or no. If no: who does the other half, and how the handoff works.

6. Access during the first week
   -> see below. This is the test.

7. Rate or expected compensation
   -> a number or a structure they can compare.
      "Let's hop on a call" is not a rate.

We think item five is the one buyers learn the hard way. In our experience, the gap between the person who maps a process and the shop that builds it is where audits die: the roadmap is handed over, and nobody is accountable for building it.

Item six, taken apart

Item six asks whether you know what you need before you know the business. In our experience, asking for too much, like admin rights to everything, tells the buyer you plan to learn on their live systems. Asking for too little, like "a kickoff call and we'll see", tells them you have no method.

This is our version for an audit shaped like this one. It is ours, not the buyer's:

Week one: read-only and scoped

People
  - a short session with each function lead:
    finance (AP/AR), customer service, dispatch / operations
  - time watching one person do the manual work, live

Data (exports or a viewer role)
  - TMS: loads/shipments for one recent month
  - accounting: invoice volume, AP/AR aging
  - shared inbox: message counts by category, not content where possible
  - the spreadsheets people actually use between systems

Not in week one
  - write access to anything
  - production credentials
  - customer personal data beyond what a sample needs

What week one produces
  - a map: process -> steps -> who -> volume -> where it breaks
  - a shortlist of candidates, each with a rough effort and a rough value

The last block matters most. An access list with no stated output is a request for trust. An access list tied to an output is a plan.

The ugly process is the proof

The owner asked to see one ugly process taken to mostly automated. We think the useful format is short and has numbers in it:

Process:       what it was, in one line
Before:        steps, who did them, volume per week, where errors came from
Why it was ugly: the part everyone had given up on
After:         what the system does, what a human still does and why
Measured:      time per item, error rate, volume handled, before vs after
After launch:  what broke, and what we changed

In our experience, the "what a human still does" line is where people give themselves away: a system that removes every human step on paper usually moves them somewhere nobody is watching. The "after launch" line answers the production-evidence test from the buyer-side guides. If the buyer is technical and the system touches a model, the same card can carry the four red-teaming metrics. For a system you operate, you can state those before anyone asks.

What we would tell this buyer

One of the few replies that actually engaged told the owner to narrow the scope: go workflow by workflow before choosing who implements each part. We agree, and we would put it inside the audit rather than instead of it. In our view, an audit covering a dozen functions that ends with "automate all of it" has failed. A useful audit ends with a short, ranked list, and at least one item that should stay manual.

FAQ

Should we offer the audit for free to win the work? Our view: no. This buyer offered to pay for the audit themselves. A free audit changes what the buyer is evaluating, and it asks them to trust a discount instead of a method.

What if our best work is under NDA? Describe the process, not the client. The "before / after / what a human still does / what broke" format works without a name. What doesn't work is a portfolio link standing in for an answer.

Do we need red-teaming numbers for back-office automation? Not always. If a model reads customer email or documents and acts on them, a technical buyer can now point to OWASP's red-teaming criteria and ask for those numbers. We think it's cheaper to have the numbers ready than to be scored on a demo.

Isn't one Reddit thread a thin signal? On its own, yes. It is one buyer. What makes it worth writing about is that the list matches what buyer-side guides and the OWASP criteria already ask for: evidence from operation, not presentation.

Why single out item six? A portfolio can't answer it. It shows whether you have a method before you have context.

Related case

The seven items, one per slide, are in the carousel for this series: {{anchor_url}}. It is the short version of this piece, laid out so you can send it to whoever on your side writes the reply.

If you have something worth building, we'd like to hear about it.