The Building Blocks of GTM Orchestration — Arman Vaziri, Ramp

Yeah, really appreciate everybody showing up.

As Mada mentioned, my name's Arman. I lead our product and sales-led growth engineering teams at RAMP. And today I'm going to talk to you about the building blocks of go-to-market orchestration. And to kick it off, what do I mean by go-to-market orchestration? Effectively, what we're building towards is the ability to describe emotion, whether it's playbooks or experiments or evergreen campaigns that you want to run, and how those get distributed across the channels through which you actually execute your go-to-market, whether it's outbound or ads or web or whatever. We want the ability to describe this and automate that output.

And this really started a few years ago, where we noticed that there's a ton of great ideas. Everybody across product and data and engineering and go-to-market has really good ideas for things that they want to do. And the bottleneck is everything after that. How do you pull an audience to target? How do you convince a bunch of people to abide by whatever strategy you've come up with, or playbooks, or enabling materials? And we wanted to try to reduce that coordination cost. So there are parts of this where we could see it as an engineering problem.

Even a few years ago, just create a consistent data substrate, and federate that across the different systems through which you run your go-to-market. And obviously, in the last few years, agents have really deepened our ability to push the level of automation that you can do on behalf of operators as close as possible to those points of execution. So, really specifically, I'm a golfer. Suppose I want to offer golfers at East Coast construction companies an incentive to try Ramp, talk to sales, whatever.

And we want to be able to spin up an audience of golfers at East Coast construction companies, spin up an incentive, let's go offer some Pro V1 golf balls to these people, create outbound sequences, generate the copy, generate creative for paid ads and for web, maybe show some in-app notifications for your customers, and do all of that seamlessly by just describing the intent, right? And probably more than just this one sentence. So a few years ago, we identified a few fundamental challenges here. As was previously mentioned, the necessary data for this was just messy, inconsistent across systems, right?

Everybody's operating off of a different source of truth, and that makes it effectively impossible to distribute some coordinated action across these different go-to-market teams and channels. The next is that reps were just buried in busy work, right? Even if you have the best intentions, I want to run this campaign, I want your help doing it. The reality is that our sales teams are in back-to-back-to-back-to-back meetings all day. They're outbounding, they're selling, and the operational burden of doing everything in between sales was just really high, which made scaling out experimentation and creativity challenging.

And similar to that, the coordination and distribution are expensive, right? If you're like, I have this idea, I'm going to write this proposal, this enablement material, I'm going to try to convince a bunch of people to use all of this. That's just a really challenging thing to do at any pace that's not on the order of months. So over the last few years, we've been trying to solve this problem from the ground up, right? How can we start with that ingestion and consistency problem and data quality, which is on the roadmap every quarter? How can we then build those vertical efficiency and growth levers, saving people time and managing operations and execution?

As well as how can we improve conversion rates, make people more performant by being able to scale some of these more informed and personalized and creative strategies? And then how can we extend this horizontally, right? Teams have very common workflows at some level, right? Everybody wants to outbound, everybody has meetings. How can we take the patterns that we build for one team and start to mirror them to others? And now where we're at is this distribution and coordination problem, right? How can you execute across multiple channels simultaneously through the description of intent? So, yeah, I'll get into the building blocks really broadly.

Go-to-market agents are complicated. In order to do this effectively, your agents have to understand pretty much the entirety of your company, how you go to market, why products are useful, how to segment your buyers, your prospects, your customers, from people who have never heard about you, and you have no information on them and they have no information on you, all the way to customers who are actively using your products, who have a totally different set of problems that you have to work with. And to start to get a little technical here, we started with this consistent data foundation problem.

And if you're looking at this and you're like, that looks like a CDP, yeah, you're right. We effectively went and built an internal customer data platform at RAMP, where we're doing your very traditional things. We're going to take CRM data, product data, enrichment data, web data, buying signals, whether it's things that are internally modeled, like, I don't know, we think that this customer has a high propensity to attach to procurement or treasury, all the way to things that are external signals like funding announcements, as well as interaction data, right, emails, meetings, calls, page views.

And on the signal side of this, right, we have some set of real-time events that are coming in, things like emails. You can pipe them onto a Kafka topic, consume them, and then funnel them back into both, we have a Postgres database that backs all of this and enables us to maintain transactional guarantees, referential integrity between the entities that exist and the different entities that exist, right, between your CRM, between your product, between third parties, and attribute everything to the right level of detail, which we found to be a pretty important problem, as well as all the associated metadata around capturing where did this come from? When did it come in?

As well as starting to embed a lot of this data, right? So much sales data is just inherently unstructured, right? You have call transcripts, you have emails, you have notes, and the ability to search across that is really valuable. We have a set of online batch jobs, which are really just calling a lot of APIs for the most part. RAMP's addressable market is pretty much the entire US and now expanding internationally. So being able to pre-compute, pre-process, pre-ingest all this enrichment data about who we can sell to and who we're already selling to is really important for us.

And then, as previously mentioned, a ton of work has gone into the offline piece of this with dbt, Snowflake, pulling everything into our warehouse, doing a lot of offline batch compute, and then piping that in via reverse ETL back into the same layer. Next, more tactically, the way we tend to approach these problems is solve for one team first, then scale horizontally. As I mentioned before, you have a very overlapping set of problems that exist, right? Everybody wants to do automated outbound. Everybody wants to prepare for meetings. Whereas certain teams may have problems or things that they do that are isolated to them, like QBR generation.

And to get into an example, one of the things that we shipped is pre-meeting briefs, right? For AMs, AMs are account managers. They manage the customer relationships that exist, trying to ensure that customers are using RAMP as best as possible. And there's a lot of important context that goes into a meeting, right?

It's like what are we talking about? Who are we meeting with? What is the AM trying to do? What is the product usage information? What are the account vitals? What's the agenda that we want to tackle? And similarly, what is the customer trying to do, right? Do they have open tickets that they're trying to address? Did they email us saying that there is a specific thing they're trying to talk about? And how can we pull this together for AMs so that they can go in prepared and manage the operational piece of just being in back-to-back-to-back meetings all day?

Again, technically, the place to start with this is obviously, if we're trying to generate a pre-meeting brief, we need to know when these meetings are. So we can pipe in meeting events, do some hydration, map things like attendee emails and meeting titles back to the accounts that we're meeting with. This is a sneaky hard problem at RAMP because you have the same emails that can work on behalf of multiple businesses. So it's a fuzzy match, and we can persist that so that every downstream consumer of, hey, I care about this meeting, doesn't have to recompute this from the ground up.

And also, as mentioned in the previous talk, we've built a system around durable execution, right? That's pretty agnostic to the trigger that comes in. Everything is represented as a durable thread built around Temporal, representing each tool call and model call as an activity. That way, if a worker goes out for some reason, it can resume execution from where it left off, pulling together all the state that it accumulated at that point in time, instead of starting back from the beginning of the thread and trying to reprocess everything, which would be very inefficient and slow. There's also great out-of-the-box capabilities for things like config-scoped tool calls.

Different agents are going to have access to different sets of tools, which give them access to different information, different integrations, and different skills that might be necessary to actually perform the work. And similarly, there are things like human-in-the-loop tooling to just pause execution, get input, resume. And then, getting to the unstructured piece of this, as I mentioned, unstructured information is probably the most valuable thing you're sitting on within your warehouse or your notes or wherever you store this today. So we have some set of real-time data coming in, meeting transcripts, emails.

We have some set of batch jobs that are pulling in enablement materials, product knowledge, playbooks, chunking them, embedding them, putting them in TurboPuffer. And it allows agents to search what do I care about, what am I trying to answer right now, and do some combination of vector search, attribute search, keyword search in order to pull information scoped to a specific account, for example, without having to pull in the full raw corpus into agent context, which would also be very inefficient and very expensive. And similarly, we've built a skill library to allow people to customize their agents, right?

Getting back to the meeting brief example, different people have different formats that they care about, they have different information that they care about, and allowing them to represent that in text, giving that to the agent to pull it together, has been very valuable for getting adoption. And putting all this together, you get an operational background agent, right?

Every night, we're going to generate these things, fan out a set of agents that are going to compute per-account meeting prep, which use some set of tools, giving them access to that online CDP and Postgres I had mentioned, the vector database, meeting prep skills that we own at the system level, as well as custom instructions that users are providing themselves. And getting into extending the blocks, the goal is for these foundations to speed up the next thing, right? Meetings are super important.

We want to be able to generate things like post-meeting follow-ups and things like automatic CRM updates, right, which can pull in the transcript and say, hey, we discussed this potential expansion opportunity, let me pre-fill all the information needed to create that opportunity, get a thumbs up from a rep, and just make it happen.

And similarly, we want to extend it horizontally to other teams, right, which is mainly an exercise of creating specific skills, data integrations, and data ingestion itself, where we can say, okay, email, call transcript embeddings, custom instructions, generalizable, but if we're building this for AEs who are handling pre-sales opportunities, we need to focus more on third-party data instead of a bunch of product data that we have already, and that needs to be incorporated into our customer data platform.

The skills need to reference a different set of information that we have on the people that we're trying to sell to. And similarly, we've built this in a way where employees have access to the same tools and skills that are being used for the background agents that we're creating, right? We set up what we call our GTM MCP. And this is basically a window into the same exact tools that we've set up for these background agents. So that way, the things that we build are automatically federated out to people who want to build their own agents, they want to chat with the information that we're setting up, and build their own automations. And they're building a ton of them.

This is just a glimpse into some of the analytics that we've done, taking the reasoning generated by the MCP tool calls that are being executed remotely. And this compounds because when people build their own thing and they connect to our MCP, they're basically telling us, here's a problem that I have, here's how I'm trying to solve this problem. And we can work with them to be like, okay, we can just productionize this, distribute this to everybody who probably has similar problems. And they give us the prompts and the skills and even applications that they're vibe-coding to really simplify our ability to productionize it. And then we can prioritize these use cases.

So now, you're probably wondering, what about that golf example that I had mentioned at the beginning, the orchestration problem? The point that I'm trying to convey by talking about all these specific things that we're doing is that these vertical builds that we're creating are the foundation of multi-team, multichannel distribution.

If we want to be able to say, here's a playbook, here's how you sell procurement, here's how you sell to construction, or here are wacky experiment ideas that we have, like offering Pro V1s to golfers, which actually works really well, we need to be able to take in that corpus of information of things that people are trying to do and federate that out through the background agents that are actually creating these artifacts that people are using to operationalize go-to-market and execute.

So, for my Pro V1 golf example, the goal is to funnel this into Ramp Revenue, the internal application that we have built, and effectively funnel this into some of these vertical solutions that we've created. Right? So, you can say, for SDRs, we want to create an audience of here are the golfers that we want to send things to. We can generate personalized copy and sequences that they can send. Maybe we want to create web landing pages and spin up the images and the creative that we'll point these email sequences to.

And we can do all of that through the description of here's my intent, get the people who own these channels to review them and sign off, and really allow us to move a lot quicker in how we ship and scale creatively across all these different go-to-market channels. So the goal of this is to ship faster, ship safer, scale our teams, become more efficient. And with these campaigns, we can execute them across multiple channels with consistent audience targeting. Agents can hold context on multiple things that are options, right?

We can execute this campaign or that campaign or that experiment and balance the traditional multi-armed bandit problem of exploring new possibilities versus being safe and going into known returns. And then we can build in guardrails as well to effectively manage compliance rules, rules of engagement, being context-aware, making sure we're not doing the same thing over and over again. And yeah, just do this on behalf of everybody. And those are the building blocks of go-to-market orchestration. Thank you, everybody.

Awesome. We have probably time for one question. Hey, there we go. Hey. So, just curious, how would you approach building something like this for a smaller company or for a company that's just getting started? Yeah. I think a few people before have mentioned something similar.

But I would find the very specific use cases that you can build automation around and just solve really specific problems that exist first. Three years ago, there were two of us.

And we were building automated outbound, right? So we were just trying to figure out how can we use GPT-3.5 and put personalized copy into some sequences and pull data from wherever to generate that. And by doing these things and solving these problems, you get a really good understanding of how this works, how it could extend to other teams, and solving real problems as you go. The reality is that you can't spend a year building some really complicated system architecture that is perfect.

So you have to piece together the vertical solutions and then stick them together. And this is basically just like a window into the same exact tools that we've set up for these background agents. So that way, the things that we build are just kind of automatically federated out to people who want to go and build their own agents, they want to go chat with the information that we're setting up, and build their own automations. And they're building a ton of them. This is just like a glimpse into some of the analytics that we've done, taking the reasoning generated by the MCP tool calls, you know, that we've, that are being executed remotely.

And this compounds because like, when people go and build their own thing, and they go and connect to our MCP, they're basically telling us like, here's a problem that I have, here's how I'm trying to solve this problem. And we can go and work with them to be like, okay, we can just go and productionize this, distribute this to everybody who probably has similar problems. And they give us the prompts and the skills and the like, you know, even applications that they're vibe coding, to just like really simplify our ability to just go and productionize it. And then we can't really prioritize like these use cases.

So now, you're probably wondering, what about that golf example that I had mentioned at the beginning, the orchestration problem. The point that I'm trying to convey by talking about all these specific things that we're doing is that these vertical builds that we're creating are the foundation of like, multi-team, multichannel distribution. If we want to be able to say like, here's a playbook, here's how you sell procurement, here's how you sell to construction, or here are like, wacky experiment ideas that we have, like offering Pro V1s to golfers, which is actually like, it works really well.

We need to be able to say like, take in that corpus of information of things that people are trying to do, and federate that out through the background agents that are actually creating these artifacts that people are like, using to operationalize like, go to market and execute. So, for my Pro V1 golf example, the goal is to funnel this into Ramp Revenue, the internal application that we have built, and go and like, effectively like, funnel this into some of these vertical solutions that we've created. Right? So, you can say like, for SDRs, we want to go and create an audience of here are the golfers that we want to send things to.

We can go and generate like, personalized copy and sequences that they can go and send. Maybe we want to go and create web landing pages and spin up the images and the creative that we'll point these email sequences to. And we can do all of that through just like, the description of like, here's my intent, get the people who own these channels to review them and sign off, and really allow us to just like, move a lot quicker in how we ship and like, scale creatively across all these different go to market channels. So, the goal of this is to ship faster, ship safer, scale our teams, become more efficient.

And with these campaigns, we can go and execute them across like, multiple channels with consistent audience targeting. Agents can go and hold context on multiple things that are like, options, right? We can go and execute this campaign or that campaign or that experiment and balance the like, traditional multi-armed bandit problem of like, exploring like, new possibilities, versus like, being safe and like, going into just known returns. And then, we can build in guardrails as well, to go and effectively like, manage compliance rules, rules of engagement, being context aware, making sure we're not doing the same thing over and over again.

And yeah, just do this on behalf of everybody. And those are the building blocks of go to market orchestration. Thank you everybody. Awesome.

We have probably time for one question. Hey, there we go.

Hey. So, just curious, how would you approach building something like this for a smaller company or for a company that's just getting started? Yeah. I think a few people before have like, mentioned something similar. But, I would go and like, find the very specific use cases that you can build automation around. And just like, solve really specific problems that exist first. Like, three years ago, there was two of us. And we were building like, automated outbound, right? So, like, we were just trying to figure out like, how can we go and use GPT 3.5 and like, put personalized copy into some sequences and go and like, pull data from wherever to go and generate that.

And by doing these things and solving these problems, you get like, a really good understanding of how this works, how it could extend to other teams. And solving like, real problems as you go. The reality is that like, you can't spend like, a year going and building like, some really complicated system architecture that like, is perfect. So, you have to like, piece together the vertical solutions and then stick them together.