At the end of a busy week, the owner may know that “we asked for reviews” but have no idea which customers received a message. A simple request log answers that question. It also shows whether the problem was an unrecorded job, a failed email or a follow-up that never happened.

Download the review request tracking CSV and open it in Excel, Numbers or Google Sheets. Delete the marked demo row before recording real work.

The file is deliberately a plain CSV. It has column headings and one sample row, but no formulas, dropdowns or automatic connection to Google reviews. You can keep it in a spreadsheet program or import it into an existing job log. If several people edit it, agree who enters service completion and who records the actual send; otherwise the same row may be mistaken for two separate customers.

What to enter for each eligible customer

  • Service date and customer reference: Use an internal ID or short code, not a full name or contact address if the sheet may be shared.
  • Eligible and permission checked: Record your decision before a message is scheduled. Do not treat a blank cell as permission.
  • Channel and sent date: Email, an appropriate personal message, or a QR card offered. For a card, write “offered” in delivery status; you cannot verify that it was scanned.
  • Delivery status: Use a real status from your sending system, such as queued, sent, delivered, bounced, or opted out. “Sent” does not prove delivery.
  • Follow-up fields: Leave them blank if no follow-up is planned. Record an actual send date separately from a due date.
  • Customer reply and review observed: Note a reply or review only when you can identify it reliably. An aggregate public review count belongs in the weekly summary, not on a guessed customer row.
  • Owner and notes: Assign the person who will resolve a missed handoff or delivery problem. Keep notes short and avoid sensitive service details.

Keep contact details and permission records in your normal customer system. Give sheet access only to the people who need it and remove references when they are no longer useful. Check the rules that apply where you operate before using customer data for outreach.

The example row is marked DEMO-001. Replace it with a reference your team can find in its customer system, such as a job number. Do not put a full address or details of a medical, legal or household service in the notes column. The sheet needs to show why a request did or did not go out; it does not need to become a second customer database.

Make a weekly summary from the rows

At the end of the week, count four things: completed services, eligible customers, requests actually sent or cards offered, and confirmed deliveries where your channel reports them. Then note new public Google reviews for the period as a separate total. Write down the biggest reason eligible customers were missed.

In an illustrative week, 24 customers were eligible, 18 received an email and 15 emails were confirmed delivered. The team reached 75% of eligible customers; 83% of those emails were delivered. Two new public reviews appeared. They may have come from this week's emails, earlier invitations or customers who found the profile themselves.

For the first percentage, divide requests actually sent by eligible customers: 18 ÷ 24 = 75%. For the second, divide confirmed deliveries by emails sent: 15 ÷ 18 is about 83%. Leave delivery rate blank for QR cards and other channels that do not report it. If the sending system only reports “sent,” do not relabel that number “delivered.” The distinction tells you whether to fix the handoff, the contact data or the invitation itself.

The request log can identify missed handoffs, bad addresses, duplicates and opt-outs that need attention. Keep the public review total as a separate weekly observation. It cannot reliably grade individual staff or customers.

Do not turn the review_observed_at column into a guess. A public review might use a different name, arrive weeks later or follow a QR card. Fill that field only when the link to a customer is clear and appropriate to record. For routine reporting, the separate weekly public count is safer and more useful than a guessed one-to-one match.

Choose the next action from the pattern

  • Low request coverage: Assign the closeout task to one role. The automation guide has a handoff card if manual sending is the bottleneck.
  • Many failed deliveries: Check the contact source, address quality, and tool status before changing message copy.
  • Delivered requests, little visible response: Test the review link on a phone and inspect timing. The troubleshooting guide walks through the checkpoints.
  • More reviews but no business outcome: Compare Business Profile actions, enquiries, and customers separately using the ROI worksheet.

If the sheet takes more time to maintain than the requests themselves, simplify the fields or use the request records in your sending tool. Keep your service and customer records as the source for actual bookings; a request log by itself cannot establish financial return.