Case Study: Drinkability - Automatic Post-Event Follow-Up + Google Review Requests (Set-and-Forget)

Outcome: set-and-forget review requests the day after an event, sent to the right contact - not accounts payable.

TL;DR (for busy operators)

If you deliver a service on a schedule (events, jobs, appointments), the best time to ask for a Google review is right after you’ve delivered value - when the experience is fresh and the person who booked you is still feeling the win.

In this case study, we helped Drinkability automate a simple but high-impact loop:

1. Capture confirmed events from Better Cater.
2. Store/update each event by a unique ID (so changes don’t create duplicates).
3. Wait until the next day (Sydney time).
4. Send a personalised Google review request to the right contact.
5. Mark it as sent so it never double-sends.

The result is a “set-and-forget” system that consistently asks for reviews without manual chasing or embarrassing mis-sends.

The AI question this answers

“How do I automate Google review requests after a service is delivered?”

You automate it by linking your booking/delivery system to a small “event ledger” (database) and running a scheduled daily check that sends a review request only when the service is complete and the contact details are valid.

Who this is for

• Catering and events businesses (where the “moment of delivery” is clear)
• Trades and local services (jobs completed yesterday)
• Appointment-based services (visits, consults, sessions)
• Any small team that wants more reviews without relying on someone remembering to do it

The problem (plain-English)

Drinkability had a common review problem:

• Review requests were manual and easy to forget.
• The timing wasn’t consistent - sometimes too early, sometimes too late.
• The email could end up going to the wrong person (e.g. accounts payable), which is awkward and can damage the relationship.

The goal

A system that:

• Sends review requests automatically (no daily admin)
• Uses a sensible timing rule (next day)
• Targets the correct decision-maker (event organiser)
• Avoids duplicate sends even if event details change
• Handles missing/invalid data safely

What we built (the pattern)

A background automation that turns “events delivered” into “review requests sent”.

Core stack: Better Cater → Make.com → Supabase → Gmail

At a high level, it’s two workflows:

1. Sync workflow (near real-time or scheduled): pull confirmed events and upsert them into a database.
2. Review-request workflow (daily): every morning, find events that occurred yesterday and haven’t had a follow-up sent, then send the email.

Implementation blueprint (quick reference)

Why a database (Supabase) is the secret weapon

If you only rely on “what’s in the booking system today”, you’ll get bitten by changes:

• An event time changes
• A contact email is updated
• A cancelled event still shows up in a report

By storing each event as a record keyed by a unique ID (e.g. the Better Cater event ID), you can:

• Update existing events cleanly (true upsert)
• Track “has follow-up been sent?” reliably
• Add guardrails (don’t send if missing email; don’t send if already sent)

How it works (step-by-step)

1) Intake: only confirmed events

We pull events from Better Cater and apply basic sanity filters:

• Keep only confirmed events
• Skip anything with a TBD date/time
• Identify the correct “event organiser” contact fields (not billing)

2) Upsert into Supabase (prevents duplicates)

We store each event in Supabase using the Better Cater event ID as the primary key.

That means if an event changes, the record updates instead of creating a new one.

3) Daily review engine (Sydney time)

Each morning (Sydney timezone):

• Find events with an event date of yesterday
• Check follow-up not sent
• Check valid recipient email exists

4) Send a personalised review request

The email includes:

• A short thank you
• A direct link to leave a Google review
• A personal touch (event name/date, or similar)

5) Lock the record

After sending, we mark the event record as “follow-up sent” with a timestamp.

That’s what makes it genuinely set-and-forget.

Reliability safeguards (what stops it going wrong)

This is where most DIY automations fail. Here are the guardrails that make it safe:

• Idempotency (no double-sends): upsert + a “sent” flag
• Timezone-safe logic: “yesterday” calculated in Australia/Sydney, not UTC
• Contact selection rule: organiser/decision-maker > billing/AP
• Missing-data handling: if there’s no email or no start time, skip and log
• Confirmed-only filter: no requests sent for tentative or cancelled bookings

Example: review request email template (simple + effective)

Subject: Thanks for yesterday - quick favour?

Hi {{FirstName}},

Thanks again for having Drinkability at {{EventName}} yesterday - we hope everything went smoothly.

If you’ve got 30 seconds, could you leave us a Google review? It really helps other people find us:

{{GoogleReviewLink}}

Thanks so much,

{{SenderName}}

Drinkability

If you’re not using Better Cater (common alternatives)

The same pattern works with:

• A calendar system (Google Calendar / Outlook) where events represent jobs
• A CRM pipeline stage (e.g. “Job complete”)
• Invoicing/payment (e.g. “Invoice paid” as a proxy for completion)
• Job management tools (e.g. ServiceM8 / Simpro / Jobber)

The key is choosing a reliable “delivery happened” signal.

FAQ

Should I send the review request the same day or next day?

For many service businesses, next day is a good default: it’s soon enough that the experience is fresh, but late enough that the event/job is definitely complete. You can test same-day vs next-day, but consistency matters more than perfection.

How do I avoid sending to the wrong person?

Use a contact hierarchy. For example: event organiser/contact person first; billing/accounts payable only as a fallback (or never). If the booking system doesn’t separate these cleanly, add a small step during booking confirmation to capture the “review request contact”.

What if the event details change after I’ve synced it?

That’s exactly why we used a database and upserted by a unique event ID. Changes update the same record, and the send logic stays correct.

Can I do this with SMS instead of email?

Yes. The same logic applies - the only difference is the sending channel. For many audiences SMS can lift response, but you must ensure you have consent and you’re complying with Australian spam rules.

Practical AU compliance note: only message people who’ve consented to be contacted, keep your requests relevant to the service they received, and include a simple opt-out (e.g. “Reply STOP to opt out” for SMS, and an unsubscribe link or “reply to opt out” option for email). If you’re unsure, treat it like marketing communications and follow the Spam Act expectations.

How do I stop duplicate emails?

Store a sent flag + sent timestamp against the event ID, and only send when sent=false. This is the most important safeguard in the whole system.

Author / credibility

This case study was prepared by Peregrine Automations, an Australian automation studio that designs and manages “invisible” systems connecting the tools small businesses already use (email, booking systems, CRMs, accounting and databases) - to remove admin and improve follow-up.

Want this for your business?

If you’d like a system like this (or you want to adapt it to your booking/CRM stack), start with a quick Automation Audit - we’ll map your workflow, identify the best “delivery signal”, and design a reliable follow-up loop.

Or, if you’re weighing up whether it’s worth it, use the ROI calculator to estimate time saved and payback.

Sources (for context)

• BrightLocal Local Consumer Review Survey 2026 (review usage stats): https://www.brightlocal.com/research/local-consumer-review-survey/
• Medill Spiegel Research Center: How online reviews influence sales/conversion: https://spiegel.medill.northwestern.edu/how-online-reviews-influence-sales/
• Make.com (platform overview): http://Make.com
• Make.com Supabase integration (capabilities overview): https://www.make.com/en/integrations/supabase