Guide

Connecting your invoicing app to review requests

The paid invoice is the best possible trigger for a review request: the work is done, the customer has seen it and they have paid without complaint. Getting that event out of your invoicing app and into a text message is a plumbing job. This guide covers the four ways to do it, the data you need to pass across and the ways it breaks.

Marketing Systems for Trades 2026-11-08 Guide
Invoice marked paid on a tablet with an arrow leading to a review request text on a phone

What you are actually building

The chain is: invoice status changes to paid, something notices, that something looks up the customer's mobile number, waits a couple of hours, and sends a text with your Google review link. Optionally it checks three days later and sends a reminder.

Four components: the source (invoicing app), the transport (how the event gets out), the logic (delay, exclusions, reminder) and the sender (SMS tool). Sometimes one product does the last three. Often it takes two.

If you have not yet designed the message and timing, read our review automation workflow first. This guide assumes you know what you want to send and are working out how to make the invoice send it.

Route 1: A native integration

Some trade job-management and invoicing apps have review requests built in, or a direct integration with a review tool. If yours does, use it. The event, the customer record and the sender all live in one place, there is nothing to keep in sync and nothing to break when one side updates.

Check three things before relying on it. Can you set the delay, or does it fire instantly? Can you exclude a specific invoice from triggering a request? And does the text go from a number you control, so replies come to you?

The review tools in our review automation tools for tradesmen comparison list which invoicing apps each one connects to directly.

Route 2: Webhooks

A webhook is the invoicing app sending a small message to a URL you specify whenever something happens. 'Invoice 4471 is now paid, here is the customer ID.' Many invoicing and accounting apps support webhooks on invoice status changes.

You need somewhere for the webhook to land. That is either your review tool, if it accepts inbound webhooks, or a connector tool (route 3) that catches it and does the rest. The webhook payload usually contains the invoice ID and customer ID but not the mobile number, so a second step has to look the customer up.

Webhooks are reliable and fast, and they are the approach a competent agency will use when wiring a system for you. Riley Marketing's fixed-fee system, which includes review automation alongside a CRM, is built on this kind of event-driven connection; whether you build it yourself or have it built, the architecture is the same.

Route 3: A connector tool

Connector platforms sit between apps and let you build 'when X happens in app A, do Y in app B' without code. For this job the recipe is: trigger on invoice paid in your invoicing app, find the customer record, delay two hours, filter out excluded customers, send an SMS via your messaging tool.

They are the most flexible route and the one most people end up using when the native integration does not exist. Expect a monthly fee that scales with the number of automations you run, and expect to spend an hour setting it up and another hour testing it.

One caution: connectors poll some apps rather than receiving webhooks, which can mean a delay of up to fifteen minutes between the invoice being paid and the trigger firing. For a review request that does not matter. For a missed-call text back it would be fatal, so do not assume what works here works elsewhere.

Route 4: Parsing the payment email

The fallback when your invoicing app has no integration, no webhook and no connector support. Most apps email you when an invoice is paid. A mail-parsing rule reads that email, extracts the customer name and invoice number, and passes them on.

It works, but it is brittle. The app changes its email template and your parser breaks silently. The email rarely contains the mobile number, so you need a lookup against a separate customer list. Use it as a bridge while you move to an app that supports one of the first three routes.

The data you must carry across

The mobile number is the one that fails most. Normalise it before sending: strip spaces, convert a leading 0 to +44, and drop anything that does not start 07 after normalisation. A review request sent to a landline is a silent failure that you will not notice for months.

FieldNeeded forCommon problem
Customer first namePersonalising the textStored as 'Mr and Mrs Patel' or a company name
Mobile numberSending the SMSMissing, a landline, or formatted with spaces and +44 inconsistently
Invoice IDSuppressing duplicatesStage payments share a job but have separate IDs
Job descriptionMentioning the work in the textFree text that is too long or too technical
Exclusion flagNot asking after a bad jobNo field exists; needs a tag or a custom field
Paid timestampCalculating the delayTime zone differences in the webhook payload

Handling stage payments and deposits

For project trades, a job may have a deposit invoice, an interim invoice and a final invoice. Only the final one should trigger a review request. Three options: tag the final invoice manually, filter on an invoice title that contains 'final', or trigger on the job being marked complete rather than on any invoice.

Whichever you choose, add a suppression rule: one review request per customer per 90 days. It protects you from stage payments, from a customer with two small jobs in a month, and from your own mistakes.

Testing the connection

Create a test customer with your own mobile number. Raise an invoice, mark it paid, and wait. Note how long the text takes. Mark a second invoice paid for the same customer and confirm no second text arrives. Create a customer with a landline number and confirm the system drops it quietly rather than erroring.

Then leave the test customer in place permanently, and once a month mark a test invoice paid to prove the chain still works. Integrations rot. A monthly test is how you find out before your review count flatlines.

Where this sits in the bigger picture

The invoice-to-review connection is one link in the chain described in our anatomy of a trades lead system. It is also, in our view, the first one to build if you have nothing automated, because it compounds: every review makes the website and map listing work harder for the next customer.

If the wiring described here sounds like more than you want to take on, the bundled systems in our marketing systems for trades ranking include it pre-built, and the CRM for a one-van business guide explains how the same paid-invoice event should also update the job's status.

Frequently asked questions

Which event should trigger the review request?

Invoice marked paid, with a two to four hour delay. For stage payments, the final invoice only.

My invoicing app has no integrations. What then?

Use a mail-parsing rule on the payment notification email as a bridge, and plan to move to an app that supports webhooks or a connector platform.

How do I stop a customer getting two requests?

Add a suppression rule of one request per customer per 90 days, keyed on the mobile number rather than the invoice ID.

How often should I test the integration?

Monthly, by marking a test invoice paid for a customer record that uses your own mobile number.

M
Marketing Systems for Trades
Playbooks and provider analysis from people who build lead systems for trades. Edited by Tom Riley.