Problem

In multi-location companies, reading reviews one by one takes time. A company average can hide a small branch that is struggling. Within the same review, staff can be praised while waiting time is criticised. Mixing sources, or presenting an incomplete period as complete, leads to false comparisons. Giving a review a single overall grade, or labelling it merely positive or negative, makes all of these distinctions invisible.

Approach

One view of all reviews. Google Maps reviews and CSV / Excel data that the company authorises are collected per source; duplicates and edited reviews are tracked separately.

One review, several scores. Each topic mentioned in a review is scored separately from 1 to 5; in “staff were attentive but I waited too long”, staff attitude scores high and waiting time scores low.

A fast, structured model handles routine reviews. Reviews with weak evidence or uncertainty are resolved in detail by a stronger generative model; no review is counted twice.

Code, not the model, computes branch and period scores. Topic scores are combined on the 1–5 scale with a versioned method, per source and period; when data is insufficient the product says “insufficient data”.

A separate step generates the executive summary from the computed results and authorised review evidence, delivered on screen, as PDF / Excel or through authorised sharing.

Critical decisions

No result without evidence

Every topic result is linked to the relevant passage of the analysed review. If the evidence is weak, the result is not considered complete and goes to the stronger model or to human review.

High confidence is not enough

A model's confidence value is not a measure of accuracy. Samples are also audited from automatically accepted results, and serious safety or privacy allegations can be routed to separate review even at high confidence.

The model does not produce the score

The score is computed by the application's versioned mathematical method. A model update cannot invisibly change the meaning of past scores.

Sources and periods are never mixed

External reviews and internal data are shown separately; there is no single blended score. A source outage is not read as an improvement, and small branches do not disappear into the average.

Correlation is not root cause

“Waiting complaints increased” does not automatically become “staff shortage”. The system does not rank individual employees and does not decide on the manager's behalf.

Reserve the expensive model for hard reviews

The stronger model is used only when needed. Cost is planned with model-independent scenarios.

Details

An example in use

In a service network, a manager sees that one branch's waiting score is clearly lower than at the other branches. The review “staff were attentive, but I waited a long time despite having an appointment” is scored separately: 5 for staff attitude, 2 for waiting. The manager checks whether this is a one-off or a recurring pattern in the period, and whether there is enough data. The system may suggest reviewing the appointment and reception flow; it does not claim a staff shortage without evidence.

This scenario describes the product experience; it is not a finding from a real customer.

Scope

Google Maps reviews and permitted CSV / Excel import
A single Turkish web interface; company, region and branch views
Topic analysis, per-source scores and review evidence
Turkish explanations of reviews written in other languages
PDF / Excel outputs and authorised sharing

New sources can be added as independent connector modules.

Rollout stages

Stage	Exit condition
Scope and permissions	Locations, period, source access and data processing terms are agreed in writing.
First end-to-end flow	Reviews from one source flow through; permissions hold and results appear with the right scope on screen and in reports.
Analysis comparison	The stronger model alone and the hybrid flow are compared on the same human-evaluated samples.
Hybrid use	Starts with cautious acceptance rules; automatically accepted results are audited too and a rollback path is ready.
Expansion	Quality, cost, data sufficiency, permissions and operational evidence are reviewed together.

Evaluation does not look only at overall accuracy: deviation of topic scores from human assessment, missed low-scoring topics per category, evidence support, unsupported inferences, faithfulness of the Turkish summary and deviation in branch / period scores are measured. Sarcastic, negated, mixed and short reviews are included in the evaluation.

Technical architecture

A Django / DRF core API, Python workers, a React + TypeScript interface and PostgreSQL. Long jobs run in the background through a queue; source connectors and analysis can be updated independently while the customer uses a single interface. Each company's data stays within its own boundary; permissions are defined by role and organisational scope.