An AI answer about a company can sound positive and still contain a factual error. It can sound critical and still correctly cite a public limitation. Therefore, "sentiment" and "reputation" should not be measured by a single improvised score. For the enterprise, diagnostics must keep tone, factuality, source and business risk separate.
The method below is built for organizations with multiple products, markets, and teams. Don't assume you can directly control a platform's responses. Instead, it creates a process of observation and triage that can be repeated.
Start with the questions that can change a decision
Don't collect prompts just for volume. Select questions about product, pricing, security, support, incidents, comparisons and compatibility. Add brand questions only if they are relevant to the buyer, candidate or partner.
Group them by category. A security issue has a different owner and risk than a support program question.
Save the raw response before tagging
For each observation, keep the exact prompt, language, date, full response, and sources displayed, if any. Don't start by just writing "negatives" in a spreadsheet. Without the raw response, you can no longer verify that the tag was applied correctly.
If the platform produces different responses on successive runs, it preserves the variation. Don't just select the best or worst example.
Evaluate factuality separately from tone
Build two axes. The first asks whether the main claims are correct and verifiable. The second describes the tone or framing. A favorable response that attributes a non-existent certification to the product is more problematic than a neutral one that accurately explains a limitation.
For factuality, use primary sources: product documentation, official security pages, terms, releases, and other controlled documents. For public allegations or incidents, also retain independent sources where necessary.
Don't make up a total score
You can use internal categories for sorting, but avoid a reputation index with arbitrary weights. A score of 73/100 seems accurate without telling what population was assessed, what questions went in, and how stable the result is.
More useful is a table with the number of factually correct answers, answers with material errors, inconclusive answers and cases where the tone can create risk. Keep the denominator visible.
Link the finding to the source of the statement
If a response says that the product does not support an integration, check the current documentation. If the information is old on a third party page, note this. If your own site is contradictory, the problem may be internal.
Do not assume that every unfavorable response comes from a single source. Some systems can synthesize multiple documents, and some statements do not have fully visible provenance.
Create a triage flow between teams
Marketing can investigate framing and brand pages. Product confirms capabilities. Security verifies assertions about controls and certifications. Legal or compliance can evaluate sensitive cases. Support can confirm operational experience.
Every finding needs an owner. A central dashboard without clear accountability just moves the problem from one file to another.
Separate markets, languages and products
An enterprise company may have different policies, pricing and availability by region. Do not combine answers from Romania, USA and Germany into a single score if the product or offer differs.
The same goes for language. Available sources and question wording may produce legitimate variation. Aggregate reporting should be used only after the differences are understood.
Define severity by impact, not tone
A negative response about a minor preference may have little impact. A neutral but false security claim can have a big impact. It defines severity by materiality, audience, and the possibility of inducing a wrong decision.
A practical system may use categories such as: critical incorrect information, non-critical incorrect information, questionable framing, outdated source, inconclusive response. These are more actionable than "negative feeling".
Repeat the diagnosis after material changes
If you update the documentation, release a product, change the name of a feature, or publish a clarification, create a new baseline. Do not compare without context a set collected before the change with one collected after.
It also maintains a cohort of stable questions. It helps to observe changes without constantly moving the target.
Report examples, not just distributions
An executive report can contain distributions, but must allow drill-down to the actual answers. For each material finding, it shows the prompt, the relevant passage, the verification source, and the internal owner.
It did not present the diagnosis as an exhaustive measure of the company's reputation. It is an observation of a defined set of responses over a specific period.
What goes into the backlog after diagnosis
Not every finding requires a site rewrite. A factual product error may require clearer documentation; an outdated third-party source may request outreach; a contradictory internal statement may require reconciliation between teams; a critical but fair response may require no intervention. The backlog must keep the probable cause, the owner, the evidence and the closure criteria. Thus, the diagnosis does not become an endless list of negative examples, but a prioritization mechanism.
Claim ledger
- FACT/EVIDENCE: ChatGPT Search may include web information and sources, but response behavior may vary over time and by query.
- FACT/EVIDENCE: the search documentation provides principles for access and content, without an official universal "AI reputation score" metric.
- PRACTITIONER GUIDANCE: separating factuality, tone, severity and ownership is a method of operational diagnosis.
- INFERENCE: clearer and more current sources may reduce some errors of representation, but do not guarantee a certain sentiment.
- NOT PROVEN: that improving your own pages removes all unfavorable responses or produces a better reputation score.
