Case study · Commerce data
Thinkware Store — US.
The official US dash-cam storefront runs a deep catalogue with technical specifications, bundles, and support questions. AI is only useful here if the product and support data underneath it are structured first.
- Client
- Thinkware US
- Scope
- Commerce data foundation
- Status
- Ongoing
- Stack
- WooCommerce · US
Context
Dash-cam buyers compare models on specifications, compatibility, and installation. The catalogue carries those details across many SKUs, bundles, and generations. Support repeats the same compatibility and setup answers every week.
Put a model on top of that without structure and it invents specs, misses the right product, or sends a customer the wrong accessory.
The brief
- Make catalogue attributes consistent enough to retrieve and compare.
- Turn repeated support answers into a reusable macro library.
- Keep storefront operations and integrations stable through releases.
- Build the data contract before adding AI workflows on top.
What I did
Catalog structure
Attribute coverage, naming, and bundle relationships across the range.
Support data
Reusable answers for compatibility, installation, and firmware questions.
Storefront integrations
Payments, shipping, and catalogue operations kept consistent across releases.
Release support
Technical review and fixes when the storefront or catalogue changes.
What shipped
- A structured catalogue layer that supports retrieval and comparison.
- A support macro library built from real product questions.
- Storefront integrations maintained through ongoing releases.
- A data foundation that the Canada storefront also reuses.
This is the unglamorous layer AI depends on. No model fixes a catalogue where the same product has three names and no attributes.
Next
Support triage and catalogue enrichment are the natural next workflows on this data. Both start with an eval set, not a prompt.