How To Brief A Development Studio So Your AI PoC Starts Fast
When a two-week AI PoC slips, the lost time is almost never in the model work. It is in week one, and most of it sits on the buyer's side: waiting for a sample file, an API credential, or an answer to "who actually owns this process." The studio's velocity matters, but you control the variable that matters more — what you bring to the first call.
The fix is not a longer requirements document. It is a shorter one: a single page that answers the six questions every competent studio will ask anyway.
The One-Page Brief
If you can fill in these six items, a studio can come back with a real scope and price in days instead of weeks:
Workflow owner. Name the person who does or supervises the work daily and can answer "is this output correct?" within hours. Not the executive sponsor, not the IT contact.
Current process walkthrough. Five to ten steps in trigger → action → output form. Where it starts, who touches it, where the result lands.
Sample data. Twenty redacted examples beat any specification document. Real emails, real PDFs, real rows — with names and account numbers replaced, not deleted.
Systems and access status. Which systems the workflow touches, whether they have APIs, and — honestly — who has to approve credentials and how long that usually takes.
One success metric. A single number that would convince you: "80% of tickets routed correctly," "report draft in 10 minutes instead of 3 hours."
The decision after the demo. What gets decided when the PoC ends — integrate, extend, or stop — and who makes that call.
The sample data deserves the emphasis. A studio can scope around missing documentation; it cannot scope around invisible data. Twenty real examples expose the format chaos, the edge cases, and the actual difficulty — which is what an honest price has to be based on.
What Not To Write
The most common briefing mistake is over-specifying the solution and under-specifying the problem. Leave these out:
Solution designs. "Build a RAG pipeline with an agent layer" locks the team into your guess before anyone has seen the data.
Model choices. Which LLM to use is an engineering decision, made against your accuracy, cost, and data-residency constraints — and revisited as models change.
Feature lists. A PoC has one workflow and one metric. A ten-feature wishlist is an MVP backlog pretending to be a PoC.
You are buying judgment, not typing. Describe the problem precisely and let the proposal show you how the studio thinks.
Handle Security And NDA Early
Security review is the most common silent killer of week one. Sequence it before kickoff, not during it:
Sign a mutual NDA before sharing samples. Any serious studio has one ready; a week of legal back-and-forth over a standard NDA is a process smell on either side.
Write down the data rules. What may leave your network, which fields must be masked, and how long the vendor may retain data and logs — under GDPR or APPI, depending on where you operate.
Name the person who approves the security review, and start that review in parallel with the commercial discussion, not after it.
Red Flags In Vendor Responses
The brief is also a probe. Send the same one-pager to two or three studios and watch how they respond:
No questions back. A studio that reads "classify supplier invoices" and starts proposing has not understood the problem. The right response to a good brief is better questions.
An instant fixed quote without seeing data. Anyone pricing an AI workflow before looking at samples is pricing a template, not your problem.
Refusing acceptance criteria. If a vendor will not commit to a measurable definition of done, the PoC cannot fail — which also means it cannot prove anything. This is the core argument for a paid PoC over a free pilot.
Vague answers about who does the work. Ask whether the engineer scoping the project is the one building it. Briefs that pass through a salesperson, an analyst, and a subcontractor lose exactly the detail you wrote them to convey.
What A Good First Call Covers
When the brief exists, the first call stops being discovery theatre and becomes a working session:
A live walkthrough of the real process — screen share, not slides.
A first look at the sample data, with the engineer who would build the PoC in the room.
A proposed scope cut: what is inside the PoC, and what is explicitly out.
A draft success metric and how it will be measured at the demo.
Logistics: demo cadence (weekly works), access plan, dates, and a price band — for reference, our packages run from a 1-week audit to a 4-week MVP sprint.
If you leave the first call without anyone having disagreed about anything, the scope was not discussed concretely enough.
A Copy-Paste Brief Template
```markdown
AI PoC Brief — [workflow name]
Workflow owner: [name, role — the person who can judge output correctness]
Problem in one sentence: [what hurts, how often, who feels it]
Current process (5-10 steps)
1. Trigger: [what starts the process]
2. [step — who does what, in which system]
3. Output: [what is produced, where it ends up]
Sample data
Attached: [20+ redacted examples — formats and count]
Cannot be shared: [what and why — proposal: anonymized stand-ins]
Systems and access
Systems touched: [names, versions]
API status: [exists / unknown / needs approval from <who>]
Test environment: [available / needs setup — expected lead time]
Success
Metric: [one number, with the current baseline]
Decision after the demo: [integrate / extend / stop — decided by <who>]
Constraints
NDA / security review: [status, who approves]
Timing: [deadline or budget window, if any]
```
What Happens Next
With this brief in hand, the scoping conversation compresses. A studio can return within days with a written scope, acceptance criteria, and a price, and the sprint itself starts on the data instead of on a document hunt.
Before kickoff, walk through the DX PoC checklist — it goes deeper on data preparation and environment setup. The brief gets you a fast start; the checklist keeps the two weeks honest.