A contractor review-request workflow should offer the same neutral opportunity to every eligible customer, regardless of whether the business predicts a positive or negative rating. It should not ask for satisfaction first and send only happy customers to Google. It should not offer a discount, gift, draw entry, warranty benefit, or other incentive in exchange for posting, changing, or removing a review.

The complete workflow is:

verified customer and completed milestone → objective eligibility → consent and suppression check → neutral request → direct platform link → delivery record → optional reminder → public-response queue

The outcome of the request belongs to the customer. The contractor can decide who is genuinely eligible, which channel is permitted, when to ask, and how to respond. It must not manipulate which eligible customers receive the public-review opportunity or what rating and wording they provide.

This guide is for Canadian contractors and the teams connecting their CRM, email, SMS, website, and Google Business Profile. It is implementation guidance, not legal advice. Platform rules, privacy obligations, and electronic-message requirements can change and depend on the organization, relationship, message, channel, and jurisdiction. Review the current rules and obtain qualified legal advice before launch.

Define the workflow's job and its boundaries

Write a narrow purpose before configuring automation:

Invite every objectively eligible customer to share an honest review of a genuine experience, record the request without predicting sentiment, and route published feedback to an accountable response process.

That purpose excludes several adjacent workflows:

  • a private service-quality survey;
  • complaint intake and escalation;
  • warranty or callback handling;
  • customer support;
  • a testimonial or case-study permission request;
  • a referral promotion;
  • a reactivation campaign; and
  • an employee performance contest.

These systems can exchange factual status, but one should not secretly control another. A complaint process may tell the review workflow that a job remains open under a documented rule. It should not assign a hidden “likely detractor” score that permanently blocks the customer from receiving the same review opportunity as everyone else.

Choose one owner for policy, one owner for the automation, and one owner for public responses. If nobody is responsible for checking eligibility, failed deliveries, platform changes, and unresolved replies, the workflow is not ready.

A compliant implementation has more than one rule source:

| Layer | Question to answer | | --- | --- | | Review platform | What solicitation, incentive, conflict, content, and manipulation rules apply? | | Electronic messaging | May this organization send this request through this email, SMS, or other electronic channel? | | Privacy | Was the contact information collected and used for a clearly identified, appropriate purpose? | | Consumer protection | Could the overall process or presentation mislead a prospective customer? | | Contract and sector | Do project agreements, franchises, professional rules, or regulated work add restrictions? | | Internal policy | Who approves eligibility rules, templates, links, data fields, and responses? |

Do not label the workflow “Google compliant,” “CASL compliant,” or “PIPEDA compliant” based on a vendor toggle. Record the exact policy pages reviewed, their review date, the relevant decision, and the person responsible for future checks.

Google's current Maps policy permits merchants to encourage reviews that represent genuine experiences without incentives or attempts to influence the rating or content. It prohibits paying for reviews, discouraging negative reviews, selectively soliciting positive reviews, pressuring users while on the premises, requesting specific content, and using staff review quotas.

The Competition Bureau's guidance on online reviews and endorsements addresses deceptive practices such as fake or undisclosed reviews and emphasizes authenticity, transparency, and the overall impression presented to consumers. Platform permission does not replace Canadian legal review, and legal compliance does not guarantee that a platform permits the practice.

Recognize review gating in its common forms

Review gating is not limited to a page that literally asks, “Were you happy?”

The workflow is gating when it:

  • sends a public-review link only after a high private rating;
  • routes low private ratings to support while routing high ratings to Google;
  • lets staff choose only the customers they expect to be enthusiastic;
  • excludes customers who complained but completed the same eligible transaction;
  • suppresses requests based on sentiment analysis of calls, texts, or surveys;
  • asks an employee whether the customer is “safe to request”;
  • sends different destinations after thumbs-up and thumbs-down answers;
  • offers a public link only after a positive testimonial;
  • delays dissatisfied customers indefinitely while inviting everyone else; or
  • rewards staff only for five-star reviews or named positive comments.

A polite interface can still manipulate the review pool. Judge the complete decision path, including CRM filters, hidden scores, manual approval queues, branching pages, and follow-up automations.

The simplest audit question is:

Would this same customer have received the same public-review opportunity if the business expected a one-star review?

If the answer is no, inspect the rule. A legitimate rule should be independent of predicted sentiment and applied consistently.

Define objective eligibility from business facts

Use verifiable operational facts rather than mood or rating predictions. A contractor might define eligibility as:

  • a real customer or authorized project contact;
  • a specific service milestone is complete;
  • the business has enough information to identify the relevant experience;
  • the review destination represents the business that delivered the work;
  • the contact channel passed the legal and consent review;
  • the customer has not already received the maximum approved requests for that experience;
  • the customer is not an employee, contractor, family member, competitor, or another conflicted party under the platform rules; and
  • no global suppression or correction flag applies.

Document what “complete” means for each job type. It could be:

  • final invoice issued;
  • scheduled service marked complete;
  • inspection or handoff completed;
  • maintenance visit closed;
  • paid consultation delivered; or
  • another defined milestone suitable to that business.

Do not ask before enough of the experience has occurred. A deposit, signed estimate, accepted quote, or scheduled appointment may not represent the completed service a future reader would assume the review covers.

For multi-stage work, choose whether one project receives one request or whether legitimately separate experiences can each qualify. Avoid turning every visit, invoice, or employee interaction into another request.

Use defensible holds and exclusions

Not every customer record should enter the workflow immediately. A hold can be legitimate when it is based on a documented operational or legal state rather than expected sentiment.

Examples that may require a hold or exclusion after appropriate review include:

  • the project or service milestone is not complete;
  • the contact information is wrong or belongs to someone else;
  • the person did not have the experience being reviewed;
  • a safety, emergency, warranty, billing, or legal process requires a different immediate route;
  • the business cannot establish a permitted electronic-message basis;
  • the customer requested no further messages;
  • the customer already received the approved request and reminder;
  • the platform or profile is not eligible for reviews;
  • the destination link is unavailable or points to the wrong profile;
  • the record appears duplicated;
  • the person has a disqualifying conflict of interest; or
  • another documented restriction applies.

Define what clears each temporary hold. A service issue should have an owner, next action, and resolution state. It should not become a permanent hidden exclusion merely because the customer may still be unhappy after the issue is closed.

When the underlying experience becomes eligible, apply the same request rule used for other customers. Do not require the customer to confirm satisfaction as the price of leaving the hold state.

Separate private feedback from the public-review opportunity

Private feedback can help improve operations, but it must not be used as a screen that decides who gets a public link.

Safe design choices include:

  • offer private feedback to every eligible customer;
  • offer the public-review link to every eligible customer;
  • present both choices without ranking one by sentiment;
  • keep complaint and support routes visible to everyone;
  • do not reveal different destinations after a satisfaction answer; and
  • do not imply that private feedback is required before a public review.

If the business wants to ask an internal service question, send it as a separate workflow with its own purpose, consent assessment, data fields, and owner. A private survey result can inform service improvement. It should not turn the public-review request on for promoters and off for detractors.

Do not use a landing page that appears neutral but performs the split after the click. Test every answer path, query parameter, redirect, tag, and CRM automation in production.

Establish the electronic-message and privacy basis

A phone number or email address in the CRM does not prove that every future message is authorized. Identify:

  • why the contact information was collected;
  • what the customer was told;
  • which channel was approved;
  • the relationship and transaction that support the decision;
  • whether the request is a commercial electronic message;
  • which consent, identification, unsubscribe, record, or exception rules apply;
  • the age and source of the record;
  • whether an opt-out or suppression applies; and
  • who reviewed the conclusion.

The CRTC explains that Canada's Anti-Spam Legislation applies to commercial electronic messages sent to electronic addresses, including SMS, and provides rules for consent, sender identification, unsubscribe mechanisms, records, and exceptions. Whether a particular review request is a commercial electronic message is fact-specific. Have qualified counsel assess the exact message, purpose, relationship, and channel rather than assuming that a completed job creates unlimited permission.

The Office of the Privacy Commissioner of Canada presents identifying purposes, consent, limiting collection, limiting use and retention, safeguards, openness, access, and accountability as distinct fair information principles. Its meaningful-consent guidance emphasizes making key uses and disclosures understandable. Map those principles to review-request data, CRM tags, delivery providers, link tracking, survey responses, and response notes.

Keep a suppression instruction global across relevant workflows. A person who opts out should not continue receiving the same request from another campaign, staff member, or imported list while systems disagree.

Write a neutral request message contract

The message should identify the business, connect the request to a genuine experience, ask for an honest review without suggesting a rating, provide the approved destination, and include any legally required information.

A neutral structure is:

Thank you for choosing [approved business name] for [accurate service or project reference]. If you would like to share your honest experience, you can leave a Google review here: [verified direct link]. Feedback is optional.

Adapt the wording to the business and legal review. Do not publish the bracketed example as a live template.

Avoid:

  • “Please leave us five stars.”
  • “If we earned five stars, review us here.”
  • “Help us stay the number-one contractor.”
  • “Our technician needs your five-star review.”
  • “Leave a review for a discount, gift, draw entry, or warranty benefit.”
  • “Post these specific keywords or mention your technician.”
  • “If anything was less than perfect, contact us instead.”
  • “Change or delete your review and we will resolve the issue.”

Do not prewrite the customer's review. A prompt may remind someone which genuine service they received, but it should not dictate praise, location keywords, employee names, or claims.

Keep promotional offers out of the review request. Adding a referral promotion, coupon, reactivation offer, or sales pitch can change the message's purpose and legal assessment.

Choose timing based on the real customer experience

Send the request when the customer has enough experience to review and the record is operationally complete. Timing can depend on:

  • service completion;
  • installation handoff;
  • a reasonable period to use the work;
  • final documentation;
  • invoice or payment state, when appropriate and reviewed;
  • closure of a temporary service hold; and
  • channel-specific sending hours.

Do not choose timing only to catch a customer at the emotional high point or before a known issue can emerge. For work where performance becomes clear over time, a request immediately after installation may invite a review of the sales experience rather than the result.

Set a maximum request count. One initial request and, where authorized and reasonable, one reminder is easier to govern than an open-ended sequence. Stop when:

  • the maximum is reached;
  • the customer opts out;
  • the contact fails;
  • the record is corrected or suppressed;
  • the workflow detects an already posted review under an approved method;
  • the platform link becomes invalid; or
  • a safety, legal, or service state requires a hold.

Do not repeatedly ask someone to revise a rating. A customer may update a review voluntarily after further experience or service recovery; the business must not pressure or incentivize that change.

Use the platform's direct, verified destination

Google documents how eligible businesses can create a review link or QR code from the Business Profile. Store the approved link as controlled configuration rather than typing it into every template.

Before launch, verify:

  • the link opens the intended Business Profile;
  • the business name and location or service-area identity are correct;
  • the customer is not routed through a sentiment screen;
  • redirects do not add unexpected tracking or another destination;
  • mobile and desktop paths work;
  • the QR code resolves to the same approved destination;
  • the link remains usable outside the CRM preview;
  • no internal contact or customer information appears in the URL; and
  • the fallback message does not ask the customer to search for a profile manually.

A contractor with several eligible profiles needs a deterministic destination rule based on the genuine transaction and platform eligibility. Do not choose whichever profile needs a rating boost. If the business cannot reliably map the experience to the correct profile, stop the automation until the profile architecture is resolved.

The Google Business Profile and website consistency checklist covers profile eligibility, location models, business name, service areas, phone, website, and hours—the identity foundation the review link depends on.

Do not attach incentives to reviews

Google states that offering free or discounted goods or services or other incentives in exchange for posting, changing, or removing a review is prohibited. Its current policy also treats incentivized or biased reviews as rating manipulation.

Prohibited designs can include:

  • discount for any review;
  • gift card for a five-star review;
  • prize draw entry after posting;
  • loyalty points for leaving a rating;
  • free upgrade for showing the review to staff;
  • warranty extension tied to a review;
  • payment to revise or remove criticism; or
  • employee compensation based on named five-star reviews.

“We reward honest reviews of any rating” does not resolve a platform rule that prohibits the incentive itself. Check every target platform separately; do not assume one platform's rules apply to another.

Keep legitimate customer promotions independent from review behaviour. A customer should receive or qualify for the same offer whether they review, decline, criticize, or never open the request.

Prevent staff selection and pressure

Manual staff involvement creates a hidden gating risk. Give employees a factual completion process, not a “good customer” nomination form.

Staff may verify:

  • the correct customer and contact;
  • the completed service or milestone;
  • the correct job type and profile destination;
  • duplicate or incorrect records;
  • an objective temporary hold; and
  • a documented suppression.

Staff should not decide:

  • whether the customer seems happy enough;
  • which customers are likely to leave five stars;
  • whether criticism makes someone ineligible;
  • what rating or words the customer should use;
  • whether a negative reviewer deserves support;
  • whether to offer an incentive; or
  • whether to hide the review link until a complaint is resolved favourably.

Google's current policy states that merchants should not require or pressure users to leave reviews on the premises, request specific content, or require staff to solicit a target number of reviews. Train staff on the actual rule and audit overrides. A manager approval queue can still gate reviews if approval depends on sentiment.

Define one CRM data contract

The workflow should be explainable from structured fields rather than notes and intuition.

| Field | Purpose | | --- | --- | | Customer or contact ID | Identify the person without using contact details as the workflow key | | Experience or job ID | Identify the specific genuine transaction | | Completion milestone and date | Prove the objective eligibility event | | Profile destination ID | Select the correct review destination | | Contact channel | Apply the approved email, SMS, or other path | | Consent or messaging basis | Preserve the reviewed decision and evidence | | Suppression state | Stop requests across workflows | | Hold reason and expiry | Distinguish temporary operational holds from permanent exclusions | | Initial request state | Pending, attempted, accepted by provider, failed, or suppressed | | Reminder state | Prevent duplicate or excessive reminders | | Template and link version | Reconstruct what the customer received | | Last transition and source | Trace automation and manual changes |

Do not use review_eligible = happy or a hidden score. Do not copy private complaint details into a marketing automation when a minimal status is enough.

Define which system owns each field. A job system may own completion; the CRM may own contact and suppression; the messaging provider may own delivery events; the Business Profile owns the public review. Reconciliation should detect disagreements rather than silently letting the last write win.

Make retries and duplicate prevention explicit

An automation may fire twice because a job is reopened and reclosed, a webhook retries, a CRM field is edited, or an integration times out after accepting the send.

Use a stable request key based on the customer, experience, destination, and request type. Before sending:

  1. Recheck objective eligibility.
  2. Recheck consent and global suppression.
  3. Check whether this request key was already accepted or completed.
  4. Lock or atomically claim the send where the platform permits.
  5. Submit the message.
  6. Record the provider's response and identifier.
  7. Retry only states that are safe to repeat.

Provider acceptance is not customer delivery. Keep attempted, accepted, delivered, bounced, failed, and clicked states separate when the provider legitimately supplies them. Do not send again merely because a review did not appear.

The missed-call text-back workflow for contractors covers adjacent message classification, suppression, delivery evidence, provider boundaries, and reply routing. A review request should reuse approved infrastructure without inheriting the missed-call workflow's trigger or purpose.

Keep service recovery independent and available

Every customer should retain access to ordinary support whether they review or not. Never make issue resolution conditional on:

  • posting a positive review;
  • deleting a negative review;
  • changing a star rating;
  • sending a screenshot of a revised review;
  • withdrawing a complaint; or
  • declining to review publicly.

When a customer raises a problem after receiving a request:

  1. Route the problem to the correct service owner.
  2. Pause future review reminders under a documented operational rule.
  3. Preserve the original request and support records.
  4. Resolve or respond to the issue on its merits.
  5. Do not ask for a rating change as consideration for the remedy.
  6. Apply the standard eligibility rule after the hold is cleared.

The customer may independently decide to add, update, or remove a review. The business can explain that option without pressure when appropriate, but it should not script the outcome.

Route public reviews into a response process

Review collection without response ownership is incomplete. Create a queue that records:

  • platform and profile;
  • review URL or platform identifier;
  • observed date;
  • whether a response is needed;
  • assigned responder;
  • privacy or legal escalation;
  • draft and approval state;
  • published response date; and
  • later changes that require review.

Google advises businesses to keep replies professional, relevant, conversational rather than promotional, and careful about privacy. A public reply should not reveal project details, invoices, addresses, phone numbers, private messages, health or safety information, or the identity of someone who used a screen name.

For a positive review, acknowledge the experience without adding claims the customer did not make. For criticism:

  • read the complete review;
  • check internal facts privately;
  • avoid arguing about private details in public;
  • acknowledge the concern appropriately;
  • state a useful next step;
  • move case-specific discussion to a private channel; and
  • preserve evidence for any platform report or legal escalation.

Do not paste one generic promotional reply under every review. Do not use review replies as keyword containers.

Report policy violations, not disagreement

Google allows businesses to report reviews that violate its policies. It also states that a negative review is not automatically a sign of wrongdoing and that disagreement alone is not grounds for removal.

Create a review-reporting decision record:

  • exact review and URL;
  • policy category believed to apply;
  • factual evidence;
  • report date;
  • platform status;
  • appeal decision, where available;
  • public-response decision; and
  • internal owner.

Do not promise that a report will remove a review. Google notes that reviews may be delayed, checked, removed for policy violations, or occasionally removed by automated systems. A missing review is not proof that the contractor or automation deleted it.

Never organize employees, friends, suppliers, or customers to mass-report legitimate criticism. Do not retaliate against the reviewer or expose their information.

Reuse a review only with separate authorization

A review visible on Google does not automatically answer whether the contractor may copy its text, name, profile image, or star rating onto a website, advertisement, proposal, or social post.

Before republishing, record:

  • the exact review and source;
  • the identity and genuine relationship;
  • permission or other reviewed basis for the intended reuse;
  • exact excerpt and permitted edits;
  • name, role, location, and image attribution;
  • included channels and duration;
  • date captured and date last checked;
  • whether the original changed or disappeared; and
  • correction and removal procedures.

Do not improve the wording, combine several reviews, manufacture an aggregate rating, or omit a material qualification. Keep the copied version traceable to the approved source.

The project-photo and case-study permission checklist provides the adjacent rights, approval, version, and removal record for testimonials and other project evidence.

Measure the workflow without turning rating into a quota

Useful operational measures include:

  • objectively eligible experiences;
  • records held or suppressed by reason;
  • initial requests attempted;
  • provider acceptance, delivery, bounce, and failure;
  • reminders attempted;
  • verified link failures;
  • duplicate sends prevented;
  • replies or service issues routed;
  • published reviews observed through an approved process;
  • response queue age and completion; and
  • policy or suppression incidents.

Keep these meanings separate:

  • message delivered is not review submitted;
  • review submitted is not review published;
  • review published is not a qualified lead;
  • positive rating is not proof of a technical performance claim;
  • total review count is not proof that every customer was invited fairly; and
  • higher average rating is not proof that the workflow is compliant.

Do not set a five-star quota for staff or vendors. Measure policy adherence and operational quality: eligible-population coverage, suppression accuracy, duplicate prevention, response handling, and correction speed.

Avoid sending customer names, contact details, free-text feedback, or review content into general analytics. Use controlled IDs and aggregate workflow states where measurement is necessary and approved.

Run a production acceptance test

Use controlled test records and preserve the expected result, actual result, timestamp, request key, template version, provider identifier, and evidence.

Eligibility and anti-gating

  • [ ] Eligible completed customer receives the request.
  • [ ] Eligible customer with predicted positive sentiment receives the same path.
  • [ ] Eligible customer with predicted negative sentiment receives the same path.
  • [ ] Low private survey score does not remove the public-review opportunity.
  • [ ] Staff cannot approve or suppress based on expected rating.
  • [ ] Objective temporary hold has an owner and clearing rule.
  • [ ] Employee, family, competitor, and other conflict rules behave as approved.
  • [ ] No incentive, rating request, keyword prompt, or five-star quota appears.
  • [ ] Each channel has a reviewed legal and consent basis.
  • [ ] Required identity and unsubscribe elements appear.
  • [ ] Global opt-out stops initial requests and reminders.
  • [ ] Wrong contact and corrected contact behave safely.
  • [ ] Imported, stale, and duplicate records fail closed.
  • [ ] Template, consent, source, and decision versions are reconstructable.
  • [ ] Desktop and mobile links open the correct Business Profile.
  • [ ] QR code reaches the same destination.
  • [ ] No satisfaction screen or conditional redirect gates the link.
  • [ ] No personal information appears in the URL.
  • [ ] Support remains available without posting or changing a review.
  • [ ] The request is readable, optional, neutral, and accurate.

Reliability

  • [ ] Duplicate completion events create one request.
  • [ ] Provider timeout does not cause a blind duplicate.
  • [ ] Accepted, delivered, bounced, and failed states remain distinct.
  • [ ] Reminder respects delivery, suppression, maximum count, and hold state.
  • [ ] Invalid profile link stops the workflow and alerts an owner.
  • [ ] Reconciliation finds an intentionally introduced mismatch.

Responses and reporting

  • [ ] New reviews enter the correct response queue.
  • [ ] Public replies disclose no private customer or project facts.
  • [ ] Negative reviews are not reported merely because staff disagrees.
  • [ ] Policy reports preserve evidence and status.
  • [ ] Republished testimonials require a separate approval record.
  • [ ] Workflow analytics contain no unnecessary personal information.

Assign monitoring and change ownership

Review workflows drift. Profiles merge, review links change, CRM fields are renamed, consent wording changes, staff add a manual shortcut, vendors update policies, or a new campaign bypasses suppression.

Assign owners for:

  • platform-policy review;
  • Canadian legal and privacy review;
  • eligibility and hold rules;
  • message templates and links;
  • CRM and integration changes;
  • global suppression;
  • delivery failures;
  • public responses and escalations;
  • testimonial reuse;
  • monthly sample audit; and
  • incident correction.

Audit a sample across the whole eligible population, not only successful reviews. Compare completed experiences with requests, holds, suppressions, delivery, reminders, and overrides. Look for sentiment-based selection hiding in manual steps or legacy fields.

Retest after any material change to the profile, link, platform policy, CRM trigger, consent language, message provider, service milestone, or response process. The current contractor SEO service is the commercial owner for reputation workflows that support truthful local visibility without review gating.

The launch decision

Launch when every objectively eligible customer receives the same neutral opportunity, every exclusion has a defensible non-sentiment reason, the channel and data use have been reviewed, the direct platform destination is correct, suppression works globally, duplicate sends are controlled, and someone owns public responses and corrections.

Do not launch when staff can cherry-pick customers, a survey score controls the Google link, incentives influence reviews, the request pressures a rating or wording, service resolution depends on changing criticism, or the business cannot reconstruct why a person was contacted.

A credible review workflow does not guarantee five stars. It earns a representative opportunity for genuine customers to speak and gives the contractor a disciplined way to listen, respond, and improve without manipulating the record prospective customers rely on.