Build a review response queue with an explicit observation clock

An unanswered review becomes urgent relative to a particular observation time. Using the current execution clock against an old export can make a historical snapshot look like a fresh operational backlog. A reliable response queue needs both review-event evidence and a declared basis for age.

Google Reviews Response Backlog Builder reads an existing review batch and creates an assessment for each useful review identity. It records response status, disclosed urgency rules and supported keyword buckets. The receiving team can use those fields to organize human review while keeping unknown status and incomplete language evidence visible.

Keep the snapshot reference explicit

The example is a shortened review projection from the installed public September snapshot. Its observation reference is also in September. This lets a local inspection reason about that historical snapshot without implying that an owner response is still absent today.

{
  "items": [
    {
      "reviewId": "Ci9DQUlRQUNvZENodHljRjlvT2trM2RXcG5WVmhoUW1kaVduWlVVSGs1YmpCTE1FRRAB",
      "stars": 5,
      "publishedAtDate": "2026-09-22T22:12:29.184Z",
      "responseFromOwnerDate": null,
      "responseFromOwnerText": null,
      "originalLanguage": "en"
    }
  ],
  "maxInputRows": 100,
  "maxResults": 10,
  "observedAt": "2026-09-23T00:00:00Z"
}

observedAt accepts a full timestamp with a timezone. If it is omitted, a valid source scrapedAt can provide the reference. Without a supported observation reference, age remains unknown. Preserve ageBasis with ageDays in the exported backlog.

Separate unanswered from unknown

The response text field is evidence about what the source captured. A missing or wrongly typed field is different from a captured blank response. A valid response date with absent or blank response text can create a conflict that requires review.

Keep responseDateTextConflict and responseStatus visible. An unknown record should not enter a queue labeled definitely unanswered merely because a spreadsheet filtered for empty text. Conversely, an answered record should remain inspectable when a later reviewer needs to understand why it was marked resolved.

Use urgency as a disclosed routing rule

The installed score combines unanswered status, star rating and age against staleDaysThreshold. The default threshold is seven days. Store the chosen threshold with the snapshot so a team can reproduce the action labels after its own response policy changes.

Keyword buckets cover specific operational topics such as refunds, waiting time, cleanliness and billing. They require confirmed English or confirmed translation to English. They are literal signals for triage. Unsupported language should preserve its limitation instead of producing a confident empty set that could be mistaken for an absence of issues.

Keep the human decision attached to the record

Export the review ID, source link, relevant text and evidence into a staging queue. Assign an owner who can inspect the current review and choose an appropriate reply. The Actor does not generate or send responses, and its keyword rules do not resolve a customer complaint.

Text is bounded, so preserve its truncation flags and allow the reviewer to open the source when context matters. Reviewer identities and photos are outside the useful output scope. The operational goal is a focused response task with enough evidence to understand its priority.

For later imports, compare review IDs and snapshot times rather than assuming a repeated batch is a new queue. Persist the team's resolved state in the receiving system. Keep diagnostics and coverage notices with each import so a missing review can be distinguished from one that was processed and routed elsewhere.

Price and verification scope

Listing pricing read on 23 October 2026 is $0.008 per result-found event on the FREE tier. The documented unit is: One useful review assessment delivered with source evidence and a recommended next step. Source errors, invalid rows and budget diagnostics request no result event. Other platform tiers have their own rates. This pricing record has no separate start event. A usable result from an illustrative input can still be billable; inspect the applicable listing and run spending limit before executing it. maxResults is an output cap, separate from the platform's Max total charge option.

This article uses the installed source contract from build 0.1.3 (0Dhtdw9HCZVrhNh5e). The example is a shortened historical source projection, with local pure-transform validation only. No new Apify cloud build or run was started for this article. Local output does not establish cloud delivery, customer acceptance or commercial results.

Inspect the Actor's current input and pricing.

AI-assisted draft; independent technical and cover review is required before publication.