One Internal GTM Intelligence Layer

This is a working transcript with chapter timestamps. It may contain transcription errors. Private names have been removed; check the video before quoting a precise phrase.

00:00:00 Why build GTM tools in code

00:00:00 I'm going to walk you guys through some of the lessons that I learned in building Wallaby, which is our sort of like GTM intelligence that we have in our class. We're going to look at this area and be like, why do you need this PC client? Why do you need this PC client? I built that before I knew any of those things existed.

00:00:35 It made me think, yeah, it did not exist. I was very exasperated trying to get a table of codes to like give me an error state so I could know if I needed to run it or not. And I'm like, fine, I'll just build it in code. And then we're going to say like the very big philosophy of like, we'll just go build it. So we built a lot of things. And this is one of them. So there's definitely a lot of things that you have to learn

00:00:54 if you haven't built it now. But interestingly enough, I'm going to go over and walk you guys through. So principal issues, same things that I think those teams face when they reach like a certain state of scaling. We had kind of like before that had like a handful of people that were sort of managing all of GTM. And that was quickly growing to like more and more people. And they were sort of, we're a super distributed team. We work mostly out of Slack. It was like very, very hard to keep up

00:01:17 with the current scale of an account. It was very hard to understand how other people needed to like update sales for everything, and track correctly so we could put a dashboard on top of it. Like these are things that like everyday employees like shouldn't really need to know. So there are a lot of like workflows we need to standardize and like data flow into our platform we need to standardize. And then we also wanted to make it easy to get stuff out of it too. We wanted people to be able to ask like,

00:01:40 yo, what's going on with this account? When was the last time we talked to them? How many of these accounts have we talked to in the course of time? And get a pretty definite answer on that. So this was sort of built with that in mind. And the last point which I think was kind of, I'll get to a little bit later too, was we wanted to provide people answers when already working, which is more and more possible I think with agents and with AI, to kind of just like input in the information

00:02:04 that we'll need for the actual data, right? So what we kind of set up was looking at a bunch of startup studies that sound good together. But the Wallaby API is basically a way for us to programmatically do things like enrichment, account scoring, to create an event, to make a campaign for an event, event follow-up, discovery, hygiene, like pretty much anything. I wanted to create basically like a GT mailbox. So like anyone could reach out to this API or use our tool and it would basically do something

00:02:35 without me having to be the blocker on it. Effectively, that was like the goal initially. We had had a few like programmatically tables set up because we need to scale a few events processes specifically. So this started to grow out of that, of like the need to give other non-technical people the ability to like run enrichment and do that stuff. But they shouldn't really have to know about account duplication, resolution, observation, sales force, like different things I wanted them to have to know. So I wanted to give them a way to like take care

00:02:59 of all these actions and like self-serve it without me being in a loop. And it's kind of quickly grown to being most of our GT operations go through here.

00:03:05 Account and person data

00:03:06 And apparently I wanted to make sure that we had a nautical version of every account contact that we had. We were working across a couple of different CRMs, a couple of different, we wrote that as Slack, we had a lot of spreadsheets, data was everywhere. And so what we ended up actually doing was trying to create like consolidated views for every account, every contact that we would resolve on the identity. So we would like, we used this complicated data thing where we're like finding like the nearest likelihood

00:03:31 that these two things are matched and matching them together. So we have like single account entity, single contact entity, and then everyone uses that as their point of reference. So we're all talking about the same thing. And you don't have people being like, oh, let's do all sources of this, and there's other sources of that. We were like, canonicize, canonicize? I don't know how to say that. I made something canon. I don't think we wanted people to know. And then initially we sort of skipped through a dashboard,

00:03:52 which I'll show you here. I did create a demo. Actually, [colleague name omitted], you're creating a demo. You're creating a demo. And this is basically like a CRM. So this is that top level canonical account that I'm able to talk to you about. So it has the name, domain, it has all the tags that we think is relevant. I added a lot of these, basically just any possible statement that we want to segment off of. We have the fit score, industry, employees, you know, standard stuff. Also their error with us and other product information.

00:04:22 We have a lot of product information sitting in sales. Like it was not very well married to Salesforce, so this gives us an easy way to link the two together. People, pretty much the same thing, but much less cool because, truthfully, I haven't done too much work here yet. This is just every list of companies that we've seen come out. So like we see a cool list on LinkedIn, we want to make sure we track it, or we want to make sure that all the companies

00:04:44 we're reaching out to, like, have some touch point with the list that we've seen in the past. This just keeps track of all the lists that we've created over time and which accounts are associated to it. This is miniature Clay that I built. Basically I used our Quizlet back into this. That was just the one that we had being sort of inherited. And we wanted to use the time and basically what this does is it will, you know, loads, running through, you know, all this Google.

00:05:13 It basically provides me the output of like a Clay table. So you give it a link, send an email, or just like a name and a title, and then it'll spit out all this jazz, which is mostly like, here's your basic enrichment, so here's your basic demographic stuff. Here's your salesforce information, and here's your WorkOS information, and it'll do that for every account that we have. And that's utilized by a lot of these other flows.

00:05:35 Event workflows

00:05:35 We have SQL to look up, which again is sort of like a person look up. It just lets you find and sort of people at any given account based on seniority gives. Again, this is sort of used by a bunch of other tools. I'm not showing anything else. And then lastly, this is probably like the main use case you have is our events. So it's very similar to what I was showing earlier, where we basically have all of our events get uploaded either to a direct sync with Luma.

00:05:59 So we'll like live sync it to Luma. It'll upload that attendee as they responded and you'd need like approve, witness, et cetera, their status from there. And it provides all the arrestment info, so we can like see who are attending. And then we have a Slack notification of the status. So it'll pop into the Slack channel and be like, hey, this person wants to come. We can audit from there as well. We also do a lot of dinners. Our office people will like very routinely go into my favorite thing,

00:06:23 don't I? Our office people will very routinely like add people to our individual dinners. I will go say, I'll do this via Slack now, I'll show up over there in a sec. But here's how we manage like conferences, et cetera, here. And then having all this information in one place, which I'll show you in a second, it's like very beneficial for our ability to then do a lot of cool like cross-selection of data to figure out like who's mentioned events. And it's also one of this.

00:06:46 And it's also like we showed you recently and then we can kind of create these individual opportunities

00:06:50 MCP as the team interface

00:06:50 of like being able to be very hyper-specific with how we reach out to someone. Because we have all this information getting uploaded here constantly, everyone has access to it, right? Cool. Let's speed through a little more. So we were using the software quite a lot. But then over time, the MCP took over as the primary that people would interact with it. The MCP basically has access to all that data you just saw. And then it also can pick up its own enrichments. It can look up things.

00:07:16 It can access stuff that failsports. It can create events. It can do pretty much anything that you would like to in a platform. Because we set it up with WorkOS Auth, and then we used WorkOS Pipes to have everyone be able to SSO into it from their Cloud GPC instance. And that made it so everyone could just have it as a good tool in their toolbox. And a lot of people started using it by accident, because it was very useful. So a lot of the go-to-market flows people were already

00:07:37 using. And then since we already had the MCP connector and the tool was available, they just started using it. And so now we have it as upgraded applications. And some of the stuff they can do is, if I want to be like, hey, we're a good prospect to invite to our next dinner based on invites from people that we've talked to in the past, it'll tell me that. These are all demo things. I'm trying to keep it meaningful, coach. If I want to see, hey, which accounts are

00:08:00 spiking products or websites to me that we had in email recently, who would that be? And then it's like, OK, well, which ones are good accounts? It'll tell me that. I can ask it what it can do. It can enrich me. It can pull a name out of a hat from this event. I don't know if that's here, but it is. All right, that was an example. And then if I want to cross-service accounts, I can do that here. So again, pretty much everything I just

00:08:24 showed you in the dashboard, this agent also has access to. And we see a lot of cool stuff happen by combining this with other MCPs. So we have web research stuff that people can do with Go, a bunch of different ways that you can cross-service it to get out. But yeah, we've seen a lot of success with this. And we're trying to life scale it across the teams. And that's definitely what I have. So thank you guys. Thank you. Cool. Did I take a few questions?

00:08:49 Yeah. Why don't we do Nath and Ibo first, and then you'll be second. OK.

00:08:55 Questions

00:08:55 Where is this deployed? How does it have the infrastructure? How does it coordinate with all the data sources? Yeah, great questions. The shortest and very, the whole thing is deployed on Cloudflare. That was just the fact that Cloudflare was the hottest thing in the world. So we deployed it all on Cloudflare. And then all of our data, basically, we write to Salesforce primarily. But we read everything from Snowflake. So we have everything pushing into Snowflake from every CRM and system that we have. So that's sort of the source of truth

00:09:21 that all of our agents collectively use. And that's when there's like how many people that finish and do this as well. And then Salesforce is just an easy place to write to, because that's a very clear, like, it's very clearly structured how to do so. So that's like the primary way that we have it set up. Cool. Then another question? Was that the same question? It was the same question. OK. Perfect. Give it up for Jack. Thank you.