WrenchCue — Review & service recovery
Ask every customer. Catch the unhappy ones first.
Reviews decide who gets called next in local service work, but asking is manual and the bad job surfaces publicly before anyone hears about it. WrenchCue automates the ask on every completed job — and routes the answers that need a person to a person.
The problem
A job finishes and nothing happens. Reviews are the deciding signal for local service businesses, yet asking depends on whichever technician remembers. Field-service tools stop at sending the ask: no second channel when nobody replies, no attribution to the technician who did the work, no path for a complaint. So the winnable unhappy customer posts publicly before the owner knows anything went wrong — and the tools built to fix this are priced for enterprises, not three-truck operations.
What changes
Closing the job starts the follow-up. Every eligible customer gets the same neutral invitation — a one-tap review link and a one-to-five rating they can reply with. Anyone who doesn't answer gets an AI voice call that discloses what it is, then an email. A high rating goes toward a public review and the testimonial library; a low one becomes a recovery case with the job, the technician, and the customer's own words on one screen, in the owner's hands the same day.
Built for
What it does
What's being built
This platform is in active development. The capabilities below describe what is being built, not what is available today.
Connects to the tool you already run
Jobber via OAuth and Housecall Pro via API key, with signature-verified webhooks, idempotent upserts, and a nightly reconciliation pass that heals the webhooks every integration eventually drops.
A cascade, not a single text
SMS an hour after the job closes, an AI voice call a day later for non-responders, then email. Each stage checks the local calling window, the suppression list, and the attempt cap before it runs.
Service recovery queue
A low rating raises an alert and opens a case with an owner, a due date, and notes — so the complaint is assigned and resolved rather than discovered later in public.
No review gating, by policy
Every eligible customer is offered the same public review invitation regardless of what they privately scored. Recovery runs alongside it. The link is never withheld or delayed on sentiment — it's written into the requirements, not left to configuration.
Consent and suppression as gates
Opt-out words permanently suppress a contact across every channel, checked before each stage. An automated voice call needs affirmative consent evidence — unknown consent means no call.
Attribution and dashboards
Per-job timeline with stages and outcomes, review velocity and rating trend, a per-technician leaderboard, the live call feed, and the testimonial library.
How it's built
The stack, specifically
No mystery boxes. These are the actual choices behind the platform — the ones that decide how it scales, who can read what, and how quickly it can change.
Frontend
- React 19 + TypeScript
- Vite
- Router with route guards; org, branch, and platform admin surfaces
Backend
- Supabase Edge Functions (Deno)
- Ingestion: FSM webhook ingest, backfill, hydrate, job refresh
- Connectors: Jobber OAuth authorize/callback, Housecall Pro connect
- Versioned workflow engine with worker claims and run history
Data & channels
- Postgres with row-level security on every public table
- Tenant keys are composite and always carry org_id
- Long work on a queue table with pg_cron, never in a function
- SMS, AI voice, and transactional email providers kept server-side
Our role
A Narix Labs product, in active development
Our own build: the connectors, the outreach cascade, the workflow engine, the multi-tenant schema and its security policies, and the dashboards. Production rules are enforced in the repository rather than deferred — every webhook signature-verified before it's parsed, every retry idempotent, every table's access decided in Postgres. It is not generally available, and the capabilities above describe what is being built.
Reject before parse
Every inbound webhook is treated as an attack surface until its signature verifies. Nothing is read, let alone written, before that check passes.
At-least-once, so idempotent everywhere
Webhooks get lost and replayed; that's assumed rather than hoped against. Unique constraints turn duplicates into no-ops, and a nightly reconciliation diff catches whatever never arrived.
The compliance surface is the product
Calling windows, AI disclosure, opt-out handling, and consent evidence aren't settings bolted on before launch — they're gates each stage passes through, because the alternative is a product that creates the liability it was bought to remove.
FAQ
WrenchCue questions
Need something like WrenchCue?
Tell us what you're holding — an idea or a codebase — and you'll have a written proposal for the first step within 48 hours.