Voice of customer: the enrichment signal your spec sheet can't provide

A spec sheet tells you what a product is. It rarely tells you what a product is for. That gap — dimension in inches vs. "finally fits my studio apartment," material composition vs. "held up through two winters of salt on the driveway" — is exactly the terrain reviews and Q&A cover, and it's becoming the terrain AI shopping agents weight most heavily when they decide what to recommend.

Specs answer "what." Buyers answer "what for."

Manufacturer data sheets are built to be defensible, not useful. Tolerances, materials, dimensions, certifications — accurate, but written for an engineer or a compliance file, not a shopper trying to figure out if the thing solves their problem. Voice-of-customer content — reviews, Q&A threads, return notes, chat transcripts — carries the use-case language specs never will: what it's compatible with in practice, who it's good for, what breaks it, what surprised people.

Here's the difference on a real category:

None of that second column exists in the manufacturer's PDF. It exists in the sentences buyers already wrote, sitting on the PDP, in support tickets, in marketplace Q&A — unused because nobody's job is to read three thousand reviews and turn them into structured attributes.

Why AI shopping agents weight this so heavily

This isn't a nice-to-have anymore. The current wave of AI shopping tools is explicit about what it rewards. Research on how ChatGPT ranks shopping results points to "descriptive, usage-based customer reviews" and embedded "FAQs, videos, Q&As, and images" as a real differentiator between products that get surfaced and ones that don't (Profound). A separate breakdown of ChatGPT's shopping ranking signals makes the same point more bluntly: the model prioritizes "clean, factual, use-case-rich descriptions" over generic manufacturer marketing copy, and weights third-party sources — reviews, roundups, forum threads — far more than brand-authored content, with one estimate putting 91% of AI shopping citations as coming from third-party sources rather than the brand's own site (Alhena).

There's a mechanical reason for this, not just a stylistic preference. Generative answer engines are doing semantic matching against a shopper's intent, not keyword matching against a title. "Quiet vacuum for a small apartment" only connects to a listing if something on or around that listing actually contains apartment-scale, noise-level, or small-space language — attributes a spec sheet was never written to include, and attributes reviews supply constantly, in the buyer's own words.

Ask an answer engine "best cordless drill for building a deck" and watch what it actually cites: it's pulling from review sentiment and forum answers about torque-under-load and battery life in real use, not the amp-hour rating on page 3 of a datasheet. The products that show up are the ones whose data — somewhere, in some field — already speaks that language.

Structured data still has to carry it

Having the language isn't enough if it's trapped in unstructured review text nobody's attributing back to the product record. Schema.org's Review and AggregateRating types exist so this content is machine-readable, and current guidance is unambiguous that Product rich results essentially require review or rating markup alongside price and availability (Google Search Central). Structured data is also increasingly framed as the mechanism behind AI Overview and answer-engine citations generally, not just search snippets (Search Engine Land).

So the pipeline that matters looks like this:

1. Reviews, Q&A, and support interactions get mined for recurring use-case, compatibility, and limitation language.
2. That language gets converted into structured attributes — use case, compatible-with, fit note, common concern — attached to the actual product record, not left as freeform review copy.
3. The structured version gets scored for confidence: a use-case mentioned by dozens of reviewers is a stronger signal than one throwaway comment, and the system should say so rather than treating every review sentence as equally reliable.
4. It ships through the feed and PDP in a form both a shopper and an answer engine can parse.

Skip step 2 and you have a wall of reviews that humans might skim and machines mostly can't use. Skip step 3 and you risk turning one outlier's complaint into an authoritative-sounding attribute.

The enrichment problem, not a moderation problem

Most teams already collect reviews and Q&A. Almost none of them turn that content into structured product attributes at catalog scale, because doing it by hand — reading review threads SKU by SKU and hand-coding use-case tags — doesn't scale past a few hundred products, let alone tens of thousands. It's the same math as manual spec-sheet enrichment, which typically runs 30-45 minutes per SKU when someone has to read a source document and populate fields by hand; voice-of-customer mining at that pace across a real catalog simply doesn't happen, so the signal sits there unused.

This is squarely enrichment work, not a new system to buy. Your PIM stores the data — Akeneo, Salsify, inriver, Stibo, Syndigo, Pimcore, Informatica, or nothing at all if you're still working from a flat file. Anglera does the work: pulling structured, quality-scored use-case and compatibility attributes out of review and Q&A content and attaching them to the product record your channels already read from, live in a few weeks rather than a multi-year integration. It's additive to whatever you already run, and it extracts and scores what buyers actually said rather than inventing language that sounds plausible. The spec sheet still tells you what the product is. The voice-of-customer layer is what tells a buyer, and increasingly an AI agent doing the shopping for them, what it's actually for.