Review intelligence signal layer

Built from the system Vinayak Mishra, GTM engineer, built for Slang AI and described on GTM Vault SMYS 1 (https://pro.gtmvault.co/episodes/smys-01). Published free by GTM Vault. Numbers below are the operator's own, from the episode; your results will differ.

When to use this

Use this when you sell to local or small and mid-sized businesses whose customers leave public reviews, and the problem your product solves shows up in those reviews in the customer's own words. Slang AI sells a voice AI reservation system to restaurants, so a review saying nobody picked up the phone is a documented instance of the exact problem. The output is a working pipeline spec, an analyzer prompt and a test plan.

The system on the record

Vinayak built a five-layer pipeline: discovery, a master data layer, review aggregation, orchestration with a model, and a qualified output table (SMYS 1, 1:48).

1. Query grid. The first Clay table holds US localities and states with the business type "restaurants". A Clay JavaScript formula builds each query, such as restaurants in a city and state (SMYS 1, 3:34).
2. Discovery. Each query hits the Serper.dev maps endpoint. One Google page returns 20 results, so further pages need extra request columns or pagination in the workflow (SMYS 1, 3:34 and 4:36).
3. Restaurant table. Results land in a second Clay table with name, website, place ID, phone numbers, rating and price level (SMYS 1, 4:36).
4. Review pull. An Apify actor called restaurant review aggregator takes search keywords and location and returns reviews with provider, review text, date and star rating. It covers Google Maps, Yelp, TripAdvisor, Facebook and DoorDash among others; for this use case he used two (SMYS 1, 5:34).
5. Rating gate. An n8n webhook receives the actor's dataset. The workflow keeps only negative reviews, three stars or below, before any model sees them (SMYS 1, 6:37).
6. Claude analyzer. The prompt casts the model as a review analyst for Slang AI, describes the company, and lists relevant signals, such as a restaurant that could not be reached by phone on a busy day or callers who rang multiple times with no response (SMYS 1, 6:37 and 7:38), plus non-relevant signals, examples and edge cases. It returns reasoning per review and a true or false verdict (SMYS 1, 8:43).
7. Route and write back. A simple if/else on that verdict sends relevant reviews, structured, by webhook into a third Clay table of qualified reviews (SMYS 1, 7:38 and 9:39). One qualified example: a birthday special request made at reservation and then ignored by staff (SMYS 1, 9:39).

He calls it an MVP, a stage two orchestrated workflow rather than a fully autonomous agent; enrichment, personalization and sending come after the qualified table (SMYS 1, 10:34). His rollout rule is to "first test it on only 10 to 15 rows" (SMYS 1, 12:17), to find where the automation breaks and to save credits.

The result

1. In the test run shown, 20 reviews came in, the rating check discarded 16 and passed 4 to the Claude analyzer (SMYS 1, 8:43).
2. The build was run for three localities, not the full US (SMYS 1, 4:36).
3. In his view, one GTM engineer is sufficient to build and run a system like this end to end (SMYS 1, 11:17).

Run it on your company

1. Ask the user once, in one message, for: what the product does and the operational failure it fixes; the target business type; the target geography (localities and states or regions); which review platforms their buyers' customers actually use; five to ten real or likely review phrases describing the failure; phrases that look similar but are not the problem; where qualified results should land (spreadsheet, Clay, CRM); and their tool access for search, scraping, orchestration and a model.
2. Write the signal definition first. Produce three lists: relevant signals (the failure, described as a customer would describe it), non-relevant signals (complaints about food, price, staff attitude or anything the product does not fix), and edge cases with a ruling on each. This is the core of the prompt and the part that decides precision.
3. Build the query grid as a table: Locality, Region, Business type, Query string, Pages to fetch. Remember one Google page returns 20 results.
4. Define the business table schema: Name, Website, Place ID, Phone, Rating, Price level, Query source. Place ID is the join key for reviews.
5. Set the rating gate. Default to three stars or below. Write it as a rule that runs before the model, so the model only reads candidate complaints. If the product fixes something customers also mention in otherwise good reviews, say so and propose a keyword pass on the discarded reviews.
6. Write the analyzer prompt. Structure: role (review analyst for the user's company), company description, relevant signals, non-relevant signals, worked examples, edge cases, and an output schema in JSON with fields relevant (true or false), signal_type, evidence_quote, reasoning. Instruct the model to quote the review text it relied on.
7. Specify routing: false verdicts are logged and dropped; true verdicts go to the qualified table with columns Business name, Place ID, Platform, Review date, Rating, Review text, Signal type, Evidence quote, Reasoning.
8. Write the test plan: run 10 to 15 rows end to end, check each layer's output, then hand-label every review the gate passed and compare against the model's verdicts. Report the share the gate dropped, the share the model kept, and every disagreement, and revise the signal lists before scaling.
9. Deliver one Markdown build spec with sections: Signal definition, Query grid, Table schemas, Rating gate, Analyzer prompt, Routing, Test plan, Next layer (enrichment and outreach, not built here).

Tools on the record

1. Serper.dev: Google Maps scraping for venue discovery.
2. Clay: master data layer, three tables.
3. Apify: pre-built actor aggregating review sites.
4. n8n: conditional routing on star rating.
5. Claude: semantic scoring of reviews as buying signals.

Any tool doing the same job works; the method is the point. Full stack: https://pro.gtmvault.co/stack/operator/vinayak-mishra

Where it breaks

1. Each layer depends on the one before it. Rick raised that one wrong input breaks everything downstream (SMYS 1, 12:17), which is why the 10 to 15 row test comes before any scale run.
2. Credits. Clay and API calls cost money per row; testing small is also how you avoid paying to discover a broken request (SMYS 1, 12:17).
3. Page limits. One Google page returns 20 results, so coverage depends on pagination you build yourself (SMYS 1, 4:36).
4. The gate can be wrong. A rating cutoff assumes the complaint lives in low-rated reviews; a three-star threshold also needs a fixed rule on whether three stars passes, so write it explicitly and test it.
5. It stops at the signal. The qualified table is not pipeline until enrichment, personalization and outreach are built on top (SMYS 1, 10:34).