On this page
Reviews
Plan structured guest-feedback context for Mobility without confusing ratings with technical measurements.
The planned reviews module adds guest-feedback context to Mobility. It is in development; the scope below supports integration planning and does not establish a live connection to any review provider.
What the module is intended to receive
The design uses structured ratings and WiFi feedback indicators. Overall property ratings and WiFi-specific feedback are different signals: a guest can rate a stay poorly for reasons unrelated to connectivity.
| Input | Planning question |
|---|---|
| Property and source | Which Lens location does the feedback concern, and where did it originate? |
| Review date | Which period does the feedback belong to? |
| Rating and source scale | What does the value mean on that provider’s scale? |
| WiFi-specific score, when available | Does the source supply a separate rating for connectivity? |
| WiFi mention and sentiment, when available | Does the supplied structured feedback refer to WiFi, and in what terms? |
The intended import excludes review text and reviewer identities. Plan to supply structured data through an integration; do not treat the module as a review scraper or a place to upload free-text guest comments.
Preserve the meaning of a score
A numeric WiFi subscore and a sentiment indicator are different kinds of evidence. Know which is available before discussing a result. Do not describe sentiment as a directly measured network-quality score.
When combining providers, preserve the original scale in the mapping so that equivalent values can be interpreted consistently. Also check how many reviews contribute and how recent they are. A small or stale sample can be unrepresentative of current experience.
Read feedback alongside measurements
Compare the relevant property and periods, allowing for the fact that a review date need not identify the exact time a guest experienced a problem. A difference between measured conditions and reported experience is a prompt for investigation.
Good signal measurements do not cover every part of a guest’s experience. Conversely, a poor overall property rating does not establish a WiFi fault. Do not infer a financial return or a technical cause from the relationship alone.
Plan the source mapping, then read how to interpret these figures alongside WiFi.
Plan review data mapping
The reviews module is in development. This page supports planning for an external integration; it is not a provider connector or activation guide.
Identify a source and scope
For each provider, agree how its property identifier maps to a Lens location. Identify the review date, the overall rating, its original scale, and any WiFi-specific rating or structured WiFi sentiment. Keep the source and scale with the value so a later normalization can be checked.
The planned model receives structured fields. It does not accept review text or reviewer identities. Do not plan a text scraping or free-text upload workflow around this module.
Check representative records
Use a few fictional or approved sample records to verify the mapping. Distinguish a missing WiFi subscore from a low WiFi score. Agree how duplicate imports and corrected ratings will be handled by the integration. Check how fresh the source data is before relating it to current measurements.
Interpret reviews alongside WiFi
The planned reviews view adds reported guest experience to Mobility. It is in development; current Sample badges in Compare & Act do not represent live review data.
Read the basis of a rating
Identify whether a WiFi figure comes from an explicit WiFi subscore or from structured sentiment associated with a WiFi mention. These are different kinds of input. Check the number of contributing reviews, their date range, and the provider scales before comparing properties.
A missing WiFi score is not a zero. A low overall property rating may concern services unrelated to connectivity. Use the source and contribution count to avoid treating every review as a WiFi complaint.
Compare with measurements
Match property and a plausible time period, then look at measured signal, reachability, and data completeness. A disagreement between ratings and measurements is useful for investigation: the device route, service experience, and review date may differ.
The relationship alone does not prove a technical cause or the financial return of a network change.