A poorly scoped proof-of-concept brief is the single biggest reason fashion-tech pilots fail to produce usable results. When the scope is vague, every vendor interprets it differently, outputs are incomparable, and your internal stakeholders cannot agree on what success even looked like. A well-structured brief fixes all of that before the first demo call.
Key takeaways
- Specify the exact operations, SKU ranges and size runs the vendor must address — not a general category of work.
- Define success metrics in advance, in numbers, so pilot outputs can be compared on the same scale.
- Describe the challenge you need solved, not the solution you expect; carefully written requirements let vendors propose their best approach.
- Separate must-have criteria from nice-to-have criteria so evaluation stays objective.
- A pilot's findings should translate directly into procurement requirements if you decide to scale.
What you need before you start
- A documented internal pain point with at least one owner (product manager, innovation lead or equivalent)
- A shortlist of two to five vendors you intend to invite
- Access to a representative sample of your product data: SKU list, size run, relevant files (tech packs, bills of materials, historical sell-through data — whatever the technology will touch)
- Alignment from legal on IP, data-sharing and confidentiality terms before you share any files
- A named internal evaluator for each functional area the pilot will touch (design, production, merchandising, IT)
- A realistic timeline: most fashion-tech PoCs run four to eight weeks; anything shorter rarely produces statistically meaningful output
Step 1 — Write the challenge statement, not the solution
Open your brief with a plain-language description of the business problem. Resist the urge to specify the technology you think will solve it. UK government AI procurement guidance is explicit on this point: tell suppliers about the situation or challenge, and let them propose a solution that meets your needs. Carefully written requirements promote a more innovative response from the market.
A strong challenge statement answers three questions in two or three sentences:
- What is the current state and why is it costly or slow?
- What outcome would a successful solution produce?
- Which teams or systems are affected?
Example (weak): We want an AI tool for trend forecasting.
Example (strong): Our buying team currently takes six weeks to compile a seasonal trend brief from internal sell-through data and external sources. We want to reduce that to under two weeks without reducing the geographic and category coverage. The output must feed into our existing planning workflow.
Expected result of this step: A one-paragraph challenge statement that every vendor on your shortlist reads the same way.
Step 2 — Define the exact scope of the pilot
This is where most briefs collapse into vagueness. Vendors need to know precisely what data they will work with and what operations they are expected to perform. Specify:
- Product scope: Which categories, SKU ranges and seasons are in scope? (e.g., womenswear tops, Spring/Summer, 120 active SKUs)
- Size run: Which size range must the tool handle? Note any regional grading differences.
- Data inputs: What files will you provide — and in what format? List them explicitly (CSV sell-through exports, tech packs as PDFs, size charts as spreadsheets, image assets).
- Operations: What must the vendor's tool actually do during the pilot? Be verb-specific: generate, classify, rank, flag, predict, output.
- Exclusions: What is explicitly out of scope? This prevents vendors from padding their demo with capabilities you are not evaluating.
Important: Do not share your full product database to make the pilot feel more impressive. A tightly scoped sample — representative but limited — is easier to evaluate and carries lower IP risk.
Expected result of this step: A scope table your legal and IT teams can sign off on before any data leaves the building.
Step 3 — Set your success metrics before you read a single proposal
Success metrics must be defined before you see vendor outputs, not after. Post-hoc metrics are unconsciously shaped by whichever result impressed you most, which makes comparison meaningless.
For each operation in scope, write a metric in this format:
Metric name / Measurement method / Minimum acceptable threshold
Examples by function:
| Function | Metric | Threshold |
|---|---|---|
| Trend signal accuracy | Buyer agreement rate on top-20 trend flags | ≥ 70% |
| Time saving | Hours to produce seasonal brief vs. current baseline | ≤ 50% of baseline |
| Data coverage | Percentage of in-scope SKUs processed without manual intervention | ≥ 95% |
| Output usability | Proportion of outputs usable without rework, rated by named evaluator | ≥ 80% |
Include at least one metric that is measurable by your team independently of the vendor's own reporting. Vendors are not adversarial, but self-reported accuracy figures are not a substitute for your own spot-check.
Expected result of this step: A metrics table that every evaluator on your team has reviewed and agreed to before the pilot begins.
Step 4 — Specify integration and data requirements
A pilot that works in isolation but cannot connect to your existing stack is not a successful pilot. State your integration constraints explicitly:
- PLM environment: If your product data lives in a PLM system — such as Centric PLM (part of Dassault Systèmes, covering fashion, cosmetics and retail) or PTC FlexPLM (used by apparel and footwear brands for design files, bills of materials, tech packs and supplier collaboration) — name it, state the version, and specify whether you expect the vendor to read from it, write to it, or both.
- File formats: List accepted input and output formats. If your production workflow requires a specific format, say so.
- Authentication and security: State your SSO requirements, data residency rules and any regulatory constraints on where data can be processed.
- API availability: If the pilot tool must connect to an existing data feed, confirm whether your IT team will provide sandbox API access during the pilot period.
Vendors who cannot meet your integration requirements during a pilot are unlikely to meet them in production. This section lets them self-select out early, which saves everyone time.
Expected result of this step: A one-page technical requirements annex that your IT team has reviewed.
Step 5 — Structure the evaluation criteria and weightings
List your criteria, separate must-haves from nice-to-haves, and assign a weighting to each. Publish this weighting to every vendor in the brief — it signals that you are running a serious evaluation, and it prevents the conversation from drifting toward whichever feature a vendor happens to demo best.
A workable structure:
Must-have (pass/fail)
- Processes all in-scope SKUs without manual data preparation
- Output delivered within the agreed pilot timeline
- Meets data security and residency requirements
Scored criteria (weighted)
- Accuracy against defined metrics (40%)
- Ease of integration with existing stack (25%)
- Quality and usability of outputs (20%)
- Vendor support and documentation during pilot (15%)
Score each vendor against the same rubric, using the same evaluators. If you use PI Apparel events or similar industry forums to meet vendors before the formal process, note that those conversations inform your shortlist — they are not a substitute for structured evaluation.
Expected result of this step: A scoring sheet that any evaluator on your team can complete consistently.
Step 6 — Write the deliverables and timeline section
Tell vendors exactly what they must produce by when. Vague deliverables produce vague outputs.
For each milestone, specify:
- The deliverable (e.g., processed trend report covering in-scope SKUs, accuracy report with methodology)
- The format (e.g., PDF plus underlying data as CSV)
- The recipient (e.g., sent to named innovation lead and named IT evaluator)
- The deadline (week number from pilot start, not a calendar date — calendar dates shift; week numbers do not)
Include a mid-pilot check-in at week two or three. This is not a review meeting — it is a data-quality checkpoint. If the vendor's tool has misread your input files or hit an integration blocker, you want to know before the final week, not after.
Expected result of this step: A milestone table that becomes an annex to any contract or letter of engagement you sign with the vendor.
Step 7 — State the path from pilot to production
A PoC that proves value but has no defined next step is a dead end. Close your brief with a short section that explains what happens if the pilot succeeds. As the GSA's AI project guidance notes, a successful pilot's findings should translate into procurement requirements so the work already done serves as the starting point for a full engagement.
Write two or three sentences covering:
- The decision timeline (when will you communicate a go/no-go?)
- The form a production engagement would take (full licence, phased rollout, expanded SKU scope?)
- Any constraints the vendor should be aware of (budget cycle, IT change-freeze windows, seasonal deadlines)
This section also signals to vendors that you are a serious buyer, which tends to produce more committed pilot support.
Expected result of this step: A paragraph that every vendor reads before they commit resources to your pilot.
Troubleshooting common brief problems
The brief is too long and vendors skim it. Aim for eight to twelve pages including annexes. Move technical specifications to annexes so the main document stays readable. Use a table of contents.
Vendors keep asking clarifying questions that suggest they have not read the brief. This usually means your challenge statement or scope section is still ambiguous. Run a pre-brief call with one trusted vendor contact to stress-test the language before you send it to the full shortlist.
Your internal stakeholders disagree on the success metrics. This is the most valuable thing a PoC brief can surface — and it is far better to surface it before the pilot than after. Schedule a one-hour alignment session with all evaluators before the brief goes out.
A vendor proposes a pilot that does not match your scope. Treat this as a signal, not a negotiation. A vendor who cannot follow a brief during the sales process is unlikely to follow a specification during implementation.
The pilot timeline slips. Build a one-week buffer into your milestone table. If a vendor misses the mid-pilot checkpoint, escalate immediately — do not wait for the final deliverable.
What success looks like
At the end of a well-run PoC process, you should have:
- Scored outputs from every vendor on the same rubric
- A clear winner on your defined metrics — or a clear picture of why no vendor yet meets your requirements
- A set of pilot findings that translate directly into a production contract or RFP, with no ambiguity about what was tested and what was not
- Internal stakeholder alignment, because everyone agreed on the metrics before the results came in
The brief is the instrument that makes all of that possible. The time you spend writing it precisely is the time you save in every subsequent conversation.
FAQ
How long should a fashion-tech PoC brief be? Eight to twelve pages, including annexes for technical requirements and the milestone table. Longer briefs are rarely read in full; shorter ones leave too much open to interpretation.
Should I share my full product data with vendors during a pilot? No. Provide a representative sample that covers your in-scope SKUs and size runs. Full database access carries unnecessary IP risk and makes the pilot harder to evaluate cleanly.
How many vendors should I invite to a PoC? Two to five. Fewer than two gives you no comparison; more than five creates evaluation overhead that degrades the quality of your assessment.
What if a vendor's pilot output looks impressive but misses my metrics? Score it against your rubric as written. Impressive demos that do not meet your defined thresholds are not successful pilots — they are sales presentations.
When should I involve IT in the brief-writing process? From Step 4 onward, at minimum. If your organisation has a data governance or security review process, involve IT from Step 2 so the scope section reflects what data can actually be shared.
Further reading
- Guidelines for AI procurement — UK Government Office for Artificial Intelligence
- Starting an AI project — GSA IT Modernization Centers of Excellence