Review Intelligence as a GTM Signal Layer

Machine-generated transcript from the episode video. Speaker labels are not included and some names and product terms may be transcribed phonetically.

[0:00] Welcome to Show Me Your Stack. This isn't a GTM podcast about frameworks or strategy decks. This is the build layer. Each episode, I sit down with a GTM engineer and break down how they're running go to market in production, the workflows, the orchestration, and the autonomous agents behind the execution. We go inside the stack, what's connected, what's automated, what's still manual, where it breaks, and how it gets rebuilt. Because modern GTM isn't a funnel. It's a system of agents, data flows, and decision layers operating in real time. Today's guest is Vinak Mishra, building AI native GTM systems across automation, evaluation, and agent workflows. No theory, no slides, just the stat. Let's get into it. Vineak, thanks for being a guest with us today. Thanks, Rick. Thanks for invite inviting me on the show. Thank you so much. It's a great opportunity to come over here and share my GTM engineering experience with you and everyone. So for this video, I uh would love to show a restaurant review

[1:03] intelligence system that I recently built. So without wasting a lot of time, let's let me just present my screen and take you to where the things are actually happening. Okay. So here we are on this restaurant review intelligence system. I'll take it in three steps. First I'll tell you whom I built this for and then what I built and then for how I built I have all my tabs open where the real workflow lies. So I built this restaurant review intelligence system for a company called Slang AI. Quick context about them. uh they are a very good company just there's a series B round and they basically are into voice AI reservation system for restaurants and the the main bottleneck is to uh that they need to find restaurants actively struggling with phone uh and reservation communication.

[1:48] So for them I figured out that a review GTM workflow could be very good and owing to that like I built a system that basically tracks the reviews given by end customers at scale which means like reviews across different platforms like Google maps, Yelp, uh Trip Adviser and lot more. And then uh the system that I built finds these review uh the negative reviews that complain specifically about phone and reservation issues because these are the problems that Flang AI's voice reservation system solves. Now I'll deep dive into an whiteboarded architecture for how I built this. So this is uh again a five-layer architecture. I'll start with serer.dev that is basically uh a very fast and cheap Google search API. So the main goal for using serer.dev dev was to uh gather the restaurants that are uh look that are that can be found in Google maps using ser.dev. I scrape all the restaurants present in the US that were on the Google maps. Then this restaurant data was sent into a master clay table

[2:50] which I'll I'll just show in a bit and then I used aify actor which is a restaurant review aggregator. So that helps me uh with the my whole review workflow and after that these reviews are all all these reviews that are fetched using the API actor are sent back to my editin workflow where all the where it's like a central brain using plot that filters all these reviews funnels uh and brings out only the reviews that are relevant for slangi by that I mean all the reviews that are relevant uh that are like negative and mention problems around phone and reservation communication. So let's quickly dive into the master clay table. So I basically uh I designed a three table architecture for this workflow.

[3:34] The first table is uh like a master table that contains all the US restaurants. So here you can see two columns. These are all the localities and the states in the in the US and the business type over here is restaurants and using a clay JavaScript formula we basically build a query that says restaurants in LA, California or maybe restaurants in Harris, Texas. So using these three columns this uh serp queries formed and next these are the serer uh http request that I'm sending to the serp I'll just quickly show you inside how it looks like. So as you can see the endpoint we areing is uh serp.dev/maps because we want to fetch a maps but if you want for other use cases where you want like images news uh maybe places or videos you can do that as well. So this the query is very simple. We have our ser query ready which is in this column and we want to scrape only one page for now. I just wanted only 20 uh restaurants to be brought back and then similarly we create the supple page two, page three and page four and sim uh like

[4:36] you can continue to build this so on and so forth or you can also use the pagination inside uh using uh an workflow uh to continue scraping till the last till like as many restaurants are available because on one page of Google only 20 results can be fetched. So this is my master table and on hitting these server server endpoints I stored the data received into a new play table so that I have only all the restaurants in the US in one single table. So for this use case I have I ran it only for three localities. Uh we can totally do it for all the localities and states in the United States. So these are the scraped restaurants and we as you can see we get all the relevant info about these restaurants like their name, website, the place ID, phone numbers and the rating and price level details. Okay, perfect. So till here we have now all the restaurants. Now uh let me take you to the app ampify actor that I've used. This is the app actor column.

[5:34] Let's go directly to the app actor. It's called restaurant review aggregator which basically takes uh the search keywords and the search location as input and brings back all the reviews found find uh like found it for different review providers like Google maps Yelp or maybe you can use trip advisor Facebook operates and do dash as well for this use case I stick to only these two so I set up like the HTTP request for this appy actor over here and yeah let's see uh I have already done some of the runs so we can go to the logs and check. So let's pick the latest one. Amazing. So this this particular restaurant called 71 and above brings back the uh who is the provider first of all. So these are the other reviews that are given by Google maps and this is the review text that the particular author has uh given and it also brings back on what date this review was posted as well as the rating of this review. Is it was it a one-star rating two or five? Now uh comes the brain of this whole workflow which is my uh uh which is what I built inside the niten. So I'll first tell you in

[6:37] overview what this whole workflow is about. So at the starting point via an enit web hook uh we are receiving data from this uh appy actor into our uh the nitin workflow. Uh remember here I just showed like there are lots of different reviews and they have lots of different ratings. So here we filter uh only the reviews that are negative and for that we need to uh filter the reviews that have less than or equal to three uh star ratings and once after the uh the star reviews filter is done it goes into a claude analyzer that basically checks if this negative review is relevant to slangi or not. Now how that happens I can quickly show you the prompt as well. So this is my whole prompt and it basically asks us to act like a review analyst for Slangi. It describes what the company does and it it gives like the relevant signals. For example, if a restaurant restaurant could couldn't be reached out by phone on a busy day, let's say a Saturday or something or maybe someone called

[7:38] multiple times but there was no response and things like that, just uh give us give it some of the non non-relevant signals, some of the examples and some of the edge cases and it was working perfectly fine. And after this filtering of the reviews that are relevant to us, I just structured the output. And here it's like a simple if else statement whether it's relevant to slang or not. And if it is relevant, this data is again structured back and sent it into our clay table in a third different table which is the qualified reviews one. So without wasting any time, I'll just uh show you one of the execution that we had done. So let's go over here. Okay, perfect. So as you can see this is our this is the data that we received from our ampify actor and this basically filters uh the data into the uh actor using data set ID. So using the uh unique data set ID we bring back the results for a particular restaurant into this uh end workflow and then here yes so here here as we can see like 20 items

[8:43] were brought in because we set our limit to 20 only. So 20 reviews were basically fetched inside this and then there was a check if the ratings is less than three or not out of which 16 were discarded and four were accepted. So they move moved further ahead. So next is the cloud analyzer that checks all these four reviews and filters out only the ones that are relevant for us. So these four items that were received as the lowar reviews are passed into the cloud analyzer. I'll just show you how the analyzer works. Basically it takes all the reviews inside and it it gives the relevant reasoning for each review whether it was like relevant to slang or not and then later this data is passed into the it it marks it as true or false and based on that the data is again later sent back to the clay table. So the relevant uh reviews are passed into the later stage of this nin workflow.

[9:39] And here just a bit of structuring is done in the output so that it can the data can be sent back to our clear table via an N uh web hook. Uh so that the data can be sent back via a web hook. So let's see if the review was feted over here. So as you can see in this third table, we have all the qualified reviews sent back that are like relevant to uh Slangi. And let's see if our the review that we fetched is relevant to slang or not. So it says special request for daughter's birthday was mentioned during reservation but completely ignored by restaurant staff. So as we can see there it is a clearly a reservation related problem and our workflow worked pretty fine. So yeah, this is uh this was my whole workflow and this is how you can build uh basically an end to-end automation for this is especially very useful for local businesses or like small and mediumsiz businesses motion.

[10:34] So this is an automation that you can replicate uh whenever it comes to selling to SMBs or like HBASC or restaurants. I want to say stage two orchestrated workflow not yet stage three fully autonomous AI agent workflow. Is that an accurate statement? Vi yeah correct. So basically I just designed an MVP of this of course like in the third table that I showed for which had all the qualified reviews from there you can enrich the restaurant's info and basically take it out from there and like do all the personalizations and send out the the copy via uh different tools. But the core of this workflow was to focus on uh the stage two. Got it. Can you quantify the efficiency?

[11:17] Traditionally, you would probably need several humans right on the team to get the outcome that you're getting with this architecture. Definitely Rick that's a good question. So in terms of the efficiency, I think uh one GTM engineer is sufficient to build uh such systems and run them end to end uh without a lot of manual intervention. It's more about if you architect a system pretty well, pretty well thought to cover all the edge cases that uh that uh like potentially the places where your automation could uh just drop off. Keeping that in mind, if you select the right set of tools, orchestrate them well and build a correct architecture, I think one person is more than enough to uh run such an automation at scale. So yeah definitely if if there are people on the team who are right now doing manually such stuff acting like analysts and you know fetching the review like they're doing the sentiment analysis part of the review. So for the example I showed that can be as I showed this this can be done at at a very large scale. So one GTM engineer should be good enough.

[12:17] And how do you know that it's ready to run you know and what I mean by that is if there's one fault in the workflow in the system it can mess everything up right if the act the the right data isn't collected then everything onward will will break basically at every stage it all depends on the previous layer being accurate. So tell me a little bit about is it experimental at first before rolling it out. Can you talk to me about the implementation framework? Of course whenever I build such uh well architect architected systems never run them at scale. So even if in this example where I showed I think I ran it only for three US locations I wanted to be pretty sure that my ser.dev dev queries are built well enough all my HTTP requests all my basically API integrations are working well as well as my amplify actor. So the recommended approach is and what I I personally follow is to first test it on only 10 to 15 rows that helps you with

[13:20] two things. One to identify where your automation is breaking and second when you're working with systems like clay or even doing API calls it helps you save a lot of credits in term uh in terms of like dollars and cents. So from both the perspectives, first it should always be well tested. I come from an AI evaluations background. So I am pretty much someone who loves doing the rigorous testing and running evaluations on any AI uh agent or AI automation that I built. So in that way it gives you like a wholesome picture of how when it when you will run it at scales how are things going to look like what would be the success percentage let's say if you have built a system that would be only 70% successful or 90% successful in terms of what sort of results we are getting back all of that can be done with some good amount of testing all the things are happening inside my clay table only like a traditional software how it is built right one first it is done on local and then it is deployed so clay works slightly differently And it's more about all things can happen in one place itself. That is like the beauty of P.

[14:22] Well, that's all folks. Thanks so much for joining us today Vinak and sharing your stack. Thanks. Definitely that was uh great choice.