Illustrative industrial-AI positioning sample
A fictional vision-inspection product for warehouse dispatch, taken through the Positioning & Evidence Sprint. It shows our reasoning and the deliverables. It does not describe a real company, a real deployment, or a result we delivered.
Part 1: The scenario
A fictional product with real-world problems.
The product is a camera-and-software system that reads pallet labels at a warehouse dispatch dock and checks them against the shipment record before the pallet leaves. The company behind it is invented for this sample.
It has two pilot customers, results from controlled tests, and a connector to warehouse management systems on its roadmap. Its website describes it in one sentence that could describe a hundred companies.
| Item | In this scenario |
|---|---|
| Product | Vision system that reads and checks pallet labels before dispatch |
| Intended buyer | Warehouse and dispatch operations leaders |
| Stage | Two pilots; controlled tests completed |
| Evidence held | Dated test footage and conditions; pilot notes; no customer baseline yet |
| Roadmap | Connector to warehouse management systems |
Part 2: The rewrite
From a category description to a position.
The proposed version is not cleverer. It is more specific: a reader can tell who it is for, where it sits in their workflow, and what it does today.
Before
An AI-powered1 platform2 transforming3 warehouse operations4.
- Describes the method, not the job
- No product category a buyer could compare
- An outcome nobody has measured
- No workflow, no user
After
A vision inspection system for warehouse teams checking pallet labels before dispatch. It flags unreadable or mismatched labels for operator review.
- Names the buyer
- Names the workflow step
- States what it does today
- Claims no result it cannot show
Why the proposed version works
It names a buyer — warehouse teams — so the right reader recognises themselves. It names a workflow step — checking pallet labels before dispatch — so an operations leader can picture where the system sits. And it states the current function — flagging unreadable or mismatched labels for an operator to review — so engineering knows what it does and what it leaves to a person.
What it deliberately does not say
It claims no superiority over alternatives and no savings, because neither has been measured with a customer. It does not lead with “AI”: the method is explained further down the page, for the readers who need it. And it does not imply the system corrects anything on its own — a person reviews every flag.
Part 3: The alternatives
What the buyer compares it with — mostly not other vendors.
| Alternative | What it does well | Where it leaves a gap | What the product would need to show |
|---|---|---|---|
| Manual visual check at the dock | Cheap and flexible | Inconsistent under time pressure; leaves no record | Consistent checking, and a record of each check |
| Handheld barcode scan of every pallet | Accurate when labels are readable | Slow; depends on discipline; an unreadable label is found only when a scan fails | Throughput against scanning, and handling of unreadable labels |
| Validation rules in the warehouse system | Catches record mismatches | Cannot see the physical label on the pallet | That it checks the physical label against the record |
| Doing nothing | No upfront cost | The cost arrives later as claims, rework and returns | A customer’s own baseline cost of dispatch errors |
Part 4: The buyer-question map
Four people decide. Each asks something different.
A page that answers only the operations question stalls in IT; one that answers only IT never reaches finance. The map assigns each question the evidence that answers it.
Operations
Where in the workflow does the check occur, and what happens after a flag?
Evidence: a workflow diagram, and dated footage of a flag being reviewed and resolved.
Engineering and IT
Which images and systems are needed, and how are exceptions handled?
Evidence: camera and mounting requirements, the data flow, exception handling — and the connector’s status, which is roadmap.
Finance
Which existing cost would improve, and what baseline would demonstrate that?
Evidence: the customer’s current error rate and cost per error, and an agreed way to measure change.
Procurement
What is included in a pilot, and who supports it?
Evidence: pilot scope, duration, success criteria, on-site support and the terms that follow a successful pilot.
Part 5: The claim-to-evidence register
Every claim, its status, and how it may be published.
The register is the hand-off between engineering and marketing. Nothing reaches the website at a strength the evidence does not support.
| Claim | Status | Evidence needed | Publishing treatment |
|---|---|---|---|
| The system flags unreadable labels for operator review | DemonstratedDemonstrated in a controlled example | Dated footage, test conditions, sample types and engineering review | Describe the demonstrated workflow and its limits |
| The system reads standard printed pallet labels | ConditionalTrue for the label types and lighting tested | A test matrix of label types, print quality and lighting | Publish with the tested conditions listed beside it |
| The system reduces shipping errors | UnvalidatedUnvalidated outcome hypothesis | Customer baseline, a comparable follow-up period and attribution caveats | Do not publish as an achieved result |
| Industry-leading accuracy | UnsupportedNo comparative benchmark exists | An independent comparison on a shared dataset | Remove. Describe the tested accuracy with its conditions instead |
| A warehouse-system connector is available | RoadmapRoadmap only | Released connector, documentation and integration validation | Label as planned; exclude from current-capability claims |
- DemonstratedShown under stated conditions, with dated material an engineer will sign off.
- Customer-validatedConfirmed by a customer, with a baseline and their permission to say so.
- ConditionalTrue within limits that must be stated alongside the claim.
- UnvalidatedAn expected outcome not yet measured. Not published as a result.
- UnsupportedNo evidence a buyer could check. Rewrite it or remove it.
- RoadmapPlanned. Labelled as planned and kept out of current-capability claims.
Part 6: The application-page outline
The page the sprint would write and implement.
In order, because the order is part of the argument: who it is for and what it does come before how it works.
Headline
The proposed positioning sentence, unchanged.
The workflow
Dock, camera read, comparison with the shipment record, flag, operator review, release or hold — as a diagram.
Who it is for
Dispatch and warehouse operations teams, and the conditions the system has been tested in.
What it does today
The demonstrated capability with its conditions, and the footage behind it.
What it needs
Cameras and mounting, network, access to shipment records, and how data is handled.
Limits
What it does not do: it does not correct labels, it does not replace validation in the warehouse system, and some label types are untested.
The pilot
Scope, duration, success criteria, how the baseline is measured, and who supports it on site.
Roadmap
The warehouse-system connector, labelled as planned.
Questions from IT, finance and procurement
Answered at the strength the register allows.
Next step
A single call to action: discuss a pilot.
Part 7: The AI-discovery questions
What an audit would test — and why no answers are shown.
The product is fictional, so any AI output shown here would be invented. We do not publish invented model answers, citations or visibility scores. This is the test design only.
| Question type | Example | What it reveals |
|---|---|---|
| Brand | What does [company] do, and who is it for? | Whether the description matches the approved positioning |
| Category | What systems check pallet labels before dispatch? | Whether the company is included, and in which category |
| Problem | How can a warehouse reduce mislabelled outbound pallets? | Whether the problem is connected to the product at all |
| Comparison | Vision inspection or barcode scanning for pallet labels? | Which alternatives are named, and how the product is compared |
Recorded for every run
- Date, platform and mode, language and region
- The exact prompt and the full answer
- Citations shown, and whether the company appears
- Factual errors against the approved facts in the register
How it is reported
Inclusion and accuracy for this sample of questions only. Observed citations are kept apart from sources we infer may have influenced an answer, and from provenance nobody outside the provider can see. A change between two waves is reported as a change, not as proof of what caused it.
Part 8: Limits
What this sample is, and what it is not.
It shows
- How we reason from a vague description to a specific position
- What the sprint’s deliverables contain and how they connect
- How claims are graded before anything is published
It is not
- A client case, or evidence of results we delivered
- A live AI audit — no model answers are reproduced
- Experience deploying this product, or any robot
A real client case adds what a sample cannot: the original commercial ambiguity, the research inputs, the decisions taken, the artefacts delivered, observations the client has approved, and the limitations. It does not treat later events — a financing round, a contract — as outcomes of the work.
Want this for your product?
The sprint produces these artefacts for one product, one use case and one buying group, in four weeks. Twenty minutes is enough to tell whether it fits.
If we can help, you leave with one specific observation about your positioning. If we cannot, we say so.