Request Google reviews after matter closure
Get the source data and prepare the review

Documentation-checked component path; proposed workflow, not tested

WHAT WAS CHECKED
Official component documentation and editorial safeguards reviewed. No login, live data, account configuration, workflow activation, client message or runtime test was performed.

BEFORE YOU START
- Firm-approved advertising/confidentiality/contact policy for its jurisdiction and practice; responsible reviewer and explicit email/template activation approval.
- Existing authorized Lawmatics and Google Business Profile access; actual subscription, fields and send controls must be verified. No purchase, login, connection or new access is included.
- A uniform matter-closure milestone, documented privacy criteria, contact-level request history, opt-out data, cooldown policy and genuine firm/location review URL.
- Synthetic inputs first. Keep client identity and the contact ledger in firm-approved systems. AI is optional and does not need client records.

DATA ACQUISITION LIMITS
- Proposed field names and ledger schemas are editorial, not native export headers.
- Lawmatics documents a once-per-target automation limit, but separate matters and manual reruns require additional contact-level deduplication. Atomic cross-matter locking is not verified.
- Never copy a positive/neutral/negative review-routing template: the same genuine review opportunity must not depend on sentiment or case outcome.

NATIVE REVIEW INPUTS
version: 1
status: Exact upgraded closure/ledger scaffolds supplied; actual account fields, pre-send checks and contact-level reservations still require verification
compatibleWithoutMapping: False
requiredNativeInputs: - name: closure-register.csv
kind: editorial_table
proposedDistinctTemplate: closure-register-template.csv
columns: - matter_alias
- contact_alias
- location_alias
- closed_at
- closure_verified
- email_permission
- opted_out
- privacy_hold
- reopened
- reviewer
- policy_version
- approval
- reviewer_decision
- decision_at
- approval_valid_until
acquisitionRequirement: Map only from the approved source and policy described in START-HERE.txt. For optional AI setup review, supply synthetic records only. Native Lawmatics field names and available conditions must be verified in the account.
- name: request-ledger.csv
kind: editorial_table
proposedDistinctTemplate: request-ledger-template.csv
columns: - contact_alias
- location_alias
- request_id
- state
- requested_at
- reserved_at
- send_evidence_ref
acquisitionRequirement: Map only from the approved source and policy described in START-HERE.txt. For optional AI setup review, supply synthetic records only. Native Lawmatics field names and available conditions must be verified in the account.
- name: policy.txt
kind: approved_text_section
proposedDistinctTemplate: policy-template.txt
requiredContent: Firm-approved choices; do not treat examples as legal rules.
Closure milestone (all outcomes):
Launch date/cohort (exclude accidental historical import):
Timezone and delivery window:
Contact permission source and freshness:
Opt-out source and working mechanism:
Privacy hold criteria and lawyer reviewer:
Cooldown days (example 180):
Contact-level duplicate key and reservation owner:
Approval validity and pre-send recheck procedure:
Correct location and verified Google review URL:
Approved sender/template version:
Uncertain-send reconciliation owner:
Record retention and permitted systems:
Activation approval evidence:
Fallback if native conditions are insufficient: automated internal task, manual send after recheck.
Prohibited selectors: outcome, satisfaction score, likely star rating, complaint, fee value.

MANDATORY APPROVAL GATE
The send workflow requires BOTH a dedicated approved-task completion event AND a current approval=true field backed by a recorded reviewer decision, decision time and policy version. Missing, stale, conflicting or revoked approval stops the send. Held or declined tasks must have the trigger tag removed before they are closed; approval remains false.
Recheck approval validity, opt-out, privacy hold, reopened status and the contact ledger immediately before sending. If unsupported, keep automation task-only and send manually after documented review.

existingFileMapping: - file: legacy/services.csv and legacy/request-log.csv
mapping: Earlier service-level fixtures do not supply the new matter/contact/location identity, approval, reservation or observed send evidence. Preserve them only with the earlier prompt.

OPEN THE INPUT MAPPING GUIDE
NATIVE-INPUT-MAPPING.txt
Use the distinct native input scaffolds listed below. Complete them from the acquired, reviewed evidence and include every required scope section in the AI-visible packet. Existing synthetic examples exercise the original review prompt only. They are not acquired evidence or a test of this native chain.

closure-register.csv: closure-register-template.csv
request-ledger.csv: request-ledger-template.csv
policy.txt: policy-template.txt

STEP 1: Copy the real review link
Tool: Google Business Profile
Open: Business Profile > Read Reviews > Get more reviews > Copy
Access needed: Existing authorized Lawmatics account with required automation/email access and an authorized Business Profile; actual entitlement not observed.
AI role: not_an_ai_step

Open the existing authorized profile for the intended firm location. Copy the native review-request URL and verify the destination. Save it in the approved template; do not generate a guessed URL. QR download is optional on desktop.

Expected output: Verified firm/location link and neutral template.
Use it next: Human setup and review required; keep workflows inactive until separately authorized.
Check: Documentation checked; exact live field mapping, plan access and end-to-end behavior remain untested.
Documentation limit: Component capabilities are documented; this safety-gated combination is an editorial adaptation.
Source documentation:
https://support.google.com/business/answer/16816815?hl=en

STEP 2: Define neutral closure and safeguards
Tool: Lawmatics
Open: Matter record and firm-approved custom fields / sub-status
Access needed: Existing authorized Lawmatics account with required automation/email access and an authorized Business Profile; actual entitlement not observed.
AI role: not_an_ai_step

Use a closure milestone that covers completed services regardless of outcome. Staff maintain proposed fields for permission, opt-out, privacy hold, review-request state, approval (default false), reviewer decision, decision time and policy version; these are editorial fields, not guaranteed built-ins. Keep a contact-level request ledger across matters. Approve a consistent cooldown (example: 180 days, a firm choice, not a Google rule). Unknown eligibility stays on hold.

Expected output: Mapped fields, responsible reviewer and approved uniform policy.
Use it next: Human setup and review required; keep workflows inactive until separately authorized.
Check: Documentation checked; exact live field mapping, plan access and end-to-end behavior remain untested.
Documentation limit: Component capabilities are documented; this safety-gated combination is an editorial adaptation.
Source documentation:
https://help.lawmatics.com/en/articles/10699913-drip-campaigns

STEP 3: Build the closure-to-task workflow
Tool: Lawmatics
Open: Automations > Workflows > Create New Automation > target Matter > Entry Conditions > Match on Fields; add Add Task
Access needed: Existing authorized Lawmatics account with required automation/email access and an authorized Business Profile; actual entitlement not observed.
AI role: not_an_ai_step

Create an inactive workflow matching the approved closure field. Add an internal eligibility-review task, assigned to the responsible staff member, using a dedicated tag such as Review-invitation-approved. Label the task: complete only when approved; use a separate disposition for held or declined cases. Restrict enrollment to an approved launch cohort so historical imports do not trigger outreach. The send workflow requires BOTH a dedicated approved-task completion event AND a current approval=true field backed by a recorded reviewer decision, decision time and policy version. Missing, stale, conflicting or revoked approval stops the send. Held or declined tasks must have the trigger tag removed before they are closed; approval remains false.

Expected output: Inactive closure-to-task workflow; no client send action in this first workflow.
Use it next: Human setup and review required; keep workflows inactive until separately authorized.
Check: Documentation checked; exact live field mapping, plan access and end-to-end behavior remain untested.
Documentation limit: Component capabilities are documented; this safety-gated combination is an editorial adaptation.
Source documentation:
https://help.lawmatics.com/en/articles/10699821-creating-tasks-for-users
https://help.lawmatics.com/en/articles/10699907-automation-entry-conditions-triggers
https://help.lawmatics.com/en/articles/10699804-pipeline-overview

STEP 4: Review the contact and approve
Tool: Lawmatics
Open: Assigned task and contact/matter timeline; firm-controlled request ledger
Access needed: Existing authorized Lawmatics account with required automation/email access and an authorized Business Profile; actual entitlement not observed.
AI role: not_an_ai_step

Before completing the approval task, verify contact identity and appropriate email permission, current opt-out, neutral privacy criteria and closure state. Check prior sends across every matter for the contact, active pending approvals and the cooldown. Reserve one request for the contact/location and close duplicate tasks without the approval tag. Sensitive matters remain on a lawyer hold until privacy clearance; dissatisfaction alone is never a hold reason. Log reviewer, decision time and policy version. The send workflow requires BOTH a dedicated approved-task completion event AND a current approval=true field backed by a recorded reviewer decision, decision time and policy version. Missing, stale, conflicting or revoked approval stops the send. Held or declined tasks must have the trigger tag removed before they are closed; approval remains false.

Expected output: Auditable approval or hold; one reserved request per contact/location.
Use it next: Human setup and review required; keep workflows inactive until separately authorized.
Check: Documentation checked; exact live field mapping, plan access and end-to-end behavior remain untested.
Documentation limit: Component capabilities are documented; this safety-gated combination is an editorial adaptation.
Source documentation:
https://help.lawmatics.com/en/articles/10699842-task-tags

STEP 5: Configure approval-to-email separately
Tool: Lawmatics
Open: Automations > Workflows > new Matter workflow > Entry Conditions > Task Activity > completed task with dedicated approval tag; Send Email
Access needed: Existing authorized Lawmatics account with required automation/email access and an authorized Business Profile; actual entitlement not observed.
AI role: not_an_ai_step

Use task completion as the separate send trigger. Add current field conditions and exit rules for opt-out, privacy hold, reopened matter and already-sent state; unknowns stop. Choose the approved Marketing > Emails template, recipient and sender; configure a reasonable delivery window. The approval must still be valid at dispatch. Cross-matter atomic deduplication and cooldown are not established native features: retain manual dispatch if the firm cannot reliably recheck and reserve at contact level. No follow-up reminder by default. The send workflow requires BOTH a dedicated approved-task completion event AND a current approval=true field backed by a recorded reviewer decision, decision time and policy version. Missing, stale, conflicting or revoked approval stops the send. Held or declined tasks must have the trigger tag removed before they are closed; approval remains false.

Expected output: Inactive approval-to-send workflow, or a documented manual-send fallback.
Use it next: Human setup and review required; keep workflows inactive until separately authorized.
Check: Verify the second workflow checks current approval=true and recorded reviewer decision in addition to its tagged-task event. If live fields cannot express these checks reliably, keep automated email inactive and use manual send after checking the recorded decision and current safeguards.
Documentation limit: Component capabilities are documented; this safety-gated combination is an editorial adaptation.
Source documentation:
https://help.lawmatics.com/en/articles/10699866-sending-emails-via-lawmatics
https://help.lawmatics.com/en/articles/10699842-task-tags
https://help.lawmatics.com/en/articles/10699906-automation-actions
https://help.lawmatics.com/en/articles/10699927-exit-conditions
https://help.lawmatics.com/en/articles/10699933-using-delivery-windows-in-automation

STEP 6: Test, activate only with approval, and reconcile
Tool: Lawmatics
Open: Synthetic test matter; automation status; recipient timeline
Access needed: Existing authorized Lawmatics account with required automation/email access and an authorized Business Profile; actual entitlement not observed.
AI role: not_an_ai_step

First test with a synthetic matter and firm test inbox, never a real client selected as sample data. Verify enrollment, hold/exit logic and the genuine link. After separate firm activation approval, reconcile each send against timeline evidence; update the request ledger only from observed status. Never retry an uncertain send before checking the timeline. Reopened matters, imports and manual reruns must not bypass the contact ledger. Do not infer review publication or reviewer identity from clicks or names.

Expected output: Test evidence and per-request sent, failed, held or unknown status; no automated public reply.
Use it next: Human setup and review required; keep workflows inactive until separately authorized.
Check: Documentation checked; exact live field mapping, plan access and end-to-end behavior remain untested.
Documentation limit: Component capabilities are documented; this safety-gated combination is an editorial adaptation.
Source documentation:
https://help.lawmatics.com/en/articles/10699927-exit-conditions

ACCOUNT AND SOURCE CHECKS STILL NEEDED
- Live entitlements, available custom-field conditions, exact recipient mapping, unsubscribe behavior, cross-matter dedup and delivery-window rechecks require synthetic testing.
- If timely pre-send checks or reliable reservation cannot be implemented, automate the task only and keep the email send manual.
- Verify the live account can require a current approval=true field and recorded reviewer decision at dispatch; otherwise use the manual-send fallback.

USING THE FILES IN THIS KIT
Use the exact files or source text named in the steps above. Native exports keep their own headers. The kit tables are editorial review worksheets; they are not a claim that a product exports those fields. Some routes use reviewed text directly or require additional original files. Never rename an unreviewed raw export to make it appear mapped. Keep expected-result files separate from inputs.

The source account, actual data, prompts and end-to-end workflow were not tested. Any final communication, filing, permission change, payment or publication needs its own authorized human action. This guide performs none.
