AI in GTM at Notion — Flora Liu

From marketing ops problem to distributed systems problem

00:12Well, first of all, hi everyone. I'm an engineer on the product growth team at Notion and now working on the GTM engineering team. A year ago, I would have told you that building a GTM system was a marketing ops problem. And today, I think it's one of the most interesting distributed systems problems that I've worked on.

00:33GTM at most companies involve a spiderweb of tools like what you see here, and they're stitched together by customer notes, proposals, contracts that are passed back and forth. Over the last few months, a small team and myself, um, we've been trying to turn this spider web into a unified GTM system.

00:48We're still in the midst of it, but we've learned a ton that I'd like to share with you today. So, this isn't really a new problem. We've been wrestling with pieces of it for years. Life cycle messaging, product recommendations, sales automations, customer data, and onboarding.

01:13But the solutions were fragmented because the underlying technology forced them to be. Then over the winter break, our CEO Ivan built spent it building a video game and he came back convinced that software engineering could be applied to many problems that were previously unwieldy or too costly.

01:28At the same time, our ability to execute skyrocketed with agentic technology and the breath of problems we could solve did too. the costly, time-consuming, and previously unsolvable spaghetti could now be sorted. So, what we found is that GTM had become a systems problem.

01:52That made us realize we could chip away at this holistically. In case you don't know, notion's platform is a collaborative brain for human and agents to think together. Over the years, we've evolved into a context layer for your company and AI agents can act on it.

02:07Notion's business moves between self-s serve growth and sales assist. Um, and customers move between these two motions all the time.

One journey for the customer, disconnected systems inside

02:23The problem is that customers experience one journey, but internally it is supported by disconnected systems that don't actually talk to each other very well. These processes were rife with human error and put a lot of cognitive burden on our teams.

02:39For example, sales reps are probably not the strongest at managing systems, but their strength is in sussing out human signals during the buying process. So, every time they had to context switch between after a call, doing research, drafting follow-up, they were spending less time with our customers and customer problems.

03:02Most companies have separate systems for sales assist and productled growth. And this is actually also true for us. Marketing run runs on one set of tools, sales on another, customer ops on a third. But all of them are looking at a customer independently and making decisions separately.

03:17So what we set out to build is a single decisioning system that spans self-s serve growth and sales assist. and it can help the customer decide the next step so that everything is cohesive. Our vision is for this system to be programmable, proactive and continuous.

03:43When we started, we were faced with some challenges. There was so no single source of truth. So customer data was spread across Salesforce, Gong, Outreach, Zoom Info and many more. Product usage lived in Snowflake and a decade of the most important context lived in notes and meeting docs.

03:56Yes, our sales reps do use notion for that too. Notion employees were actively using MCPs and their own agents to solve problems already, but they were innovating within their own departments. So it was single player mode or you could say here single department mode.

04:20Marketing built tools for tool uh marketing sales built tools for sales and each tool served a tiny slice of that customer journey and it would make it really hard to create something that was more holistic.

Data quality, latency, and the notes nobody can parse

04:34When we tried to automate across all of that we hit some roadblocks. First data quality conflicting systems of records wrong contacts tied to different accounts. One bad mapping was enough to lose trust for sales rep. Secondly, data latency.

04:49Every vendor added a hop and this lag was causing us to act on stale data and that meant we were automating on yesterday's world. Third, and this is a big one, structured and unstructured data. The most important facts about a customer were left in notes like the champion just left or don't contact this customer again.

05:07Um or they're blocked illegal. And so these are exactly the types of notes that help sales rep move forward and decide what to do next. And if an automation couldn't see it or process it, it could do something catastrophically wrong. So our project team consisted of CX, RevOps, product, engineering, sales.

05:29And

Four questions that became four layers

05:36after brainstorming together, we all kept finding the same patterns underneath that complexity. Whoops. Oh. Every workflow could be reduced to four questions. What do we know about the customer? What should happen next? How do we execute that safely?

05:50And did it work? That became our architecture. So the system has four layers. Know a context layer we can trust about every customer. Decide, choose the single next best step for them. Third, fire act and fire a concrete action that could be a life cycle email um an inapp nudge or a task handed to a rep and then learn watch what happened and feed it back into the decisioning so that it's a loop.

06:25But this architecture is missing something important. The most important part is that humans and agents are operating on the same loop. Concretely, this means that the

Humans and agents on the same loop

06:39context needs to be displayed so that humans and agents can read and operate on it together. So you can see that they're working in the same system, but they might have different roles. Agents do the repetitive work at scale like gathering context, researching, drafting recommendations, and writing artifacts.

06:59Humans provide the judgment, adding nuance, deciding what to do next, and if a recommendation is correct. and owning the customer relationship. We found that instead of building an AI layer on top of our business, we designed our architecture so that the agent can operate as another operator within the same system as humans.

07:23Before we built the system, we made some choices about how we were going to implement this. Firstly, we deliberately chose not to let an agent talk directly

Agents never talk to the customer

07:31to a customer. For sales assist workflows, humans stay in the loop by default and approve anything the agents do. The agents do the busy work. That decision that decision also has a security dimension too. If a prospect fills out a contact sales form online, we treat that as untrusted user input.

07:53And so trust boundaries don't break down, especially because there is an agent in the middle. Secondly, routing and eligibility became a first class primitive. Eligibility used to be scattered in all over the place. We had one check or rule in an email tool, another in sales and we pulled that all into one place so that these rules can be consumed across our codebase uh product sales engineering and these are like customer segmentations or signal signal definitions and then a single classifier will route what the customer should do

08:30and this will actually prevent double sends from our system and create very cohesive communication across And last but not least, we decided that it was very important to own the contact layer and we decided to rent everything else. Since we are a lean team, we will not build our own email vendor or enrichment services like Clay.

08:47We use Clay and we believe that we understood our customers the best. So we will not um give that away. So let's get into what we built.

Snowflake computes truth, DynamoDB serves it

09:04The first step was to gather a consolidated view of all of our customers. Snowflake, which is our data warehouse, is where we compute this truth. We ingest data from all the vendors in our GTM stack to Snowflake. We run daily transforms and in some cases real time to produce a small set of modeled versioned entities and these are accounts, contacts, workspaces, eligibility, and facts.

09:25And this also has clear ownership of what teams or uh tools they come from and like timestamps. Dynamob is our key value store and it's where we compute our truth or serve our truth. We publish a denormalized key addressable profile that agents can quickly query in milliseconds with no joins.

09:44We also persist agent uh persisted uh or generated artifacts and these are research snippets, summarized notes, rolling summaries and these unstructured data are also keyed by the same ids so that downstream systems can read all of this in one shot.

10:10So this data was normalized and of course we brought it into notion so that we could work with structured and unstructured data at the same time. So some of the data I showed you in the boxes earlier, there's like product usage data, there's activity log from across our vendor stack, and then we also have like unstructured data that like I mentioned that is most important for sales context with research reports and notes.

10:36And this turned out to be powerful for two reasons. First, our internal GTM teams didn't need to jump between many tools anymore. They could use notion itself, a tool they were already using to explore context, investigate investigate accounts, answer questions, and they could even take actions like sending to Nooks or um sending to outreach.

10:58This is a tool that they were very familiar with, and they didn't need to open seven tabs anymore. Secondly, because we weren't building an AI layer, um humans, workflows, and agents could all operate on the same source of truth. In a very literal sense, we are using notion to grow notion.

Signals: turning customer events into tasks

11:20The next primitive we decided that we needed was a way to turn customer events into actions. The unit here is a signal. A signal is a single customer event that's important enough to change what should happen next for a customer. Some are userdriven like a customer hitting their a AI limit or maybe they reached out to contact contact sales.

11:36But some of them are not user initiated at all which are these external signal examples I listed here like company raising funding, hiring signals or shift in their tech stack. Those external signals are what allowed us to be proactive instead of reactive.

12:00So this is the signal service that watches the customer profile, decides whether a single action is available, decides who should own that action, and then it emits a concrete task following the architecture I described before. And this task could be for a human or an agent.

12:17If there's a task for sales rep, that actually just lands in their notion database and they can quickly view it and act on it. What's what's interesting about the way we built our GTM systems is that if there is no signal about a customer, the marketing component of our system kicks in.

12:37We have a predictive engine that will recommend product features most relevant for that customer and it will send out life cycle emails and inapp nudges or multi-channel communication to drive a customer towards adoption automatically. So diving deep into a small slice of what happens when we decide what action should be emitted.

12:55Um this is for like

Shadowing the best reps, encoded on Temporal

13:04the sales workflow and we shadowed our best reps to capture something that was the most repetitive part of our job and encoded it as a durable multi- aent workflow. Every signal becomes a workflow on temporal which is something we rent and a single run will touch enrichment web search draft generation and more.

13:19Each of these is a network call that could fail or rate limit. And so temporal lets us focus on writing the sequential logic for our GTM use cases while it will handle the retries, ddupes um and handling and going back to exactly where failures left off.

13:37and one malformed transcript can't take down the whole batch which was really important to us. So an example of a cold outbound signal for us will have a research sub agent do concurrent researches then it'll draft like an email and those emails uh there should be three of them so they're scored and then a review agent will pick the highest scoring one and make any updates if necessary.

14:02And this also operates on a loop um so that the email drafts are improved. And then when it's ready, this email draft will land in the sales task that is available for for them to act on. Um for more reactive signals after a follow-up call, the Gong transcript will come in.

14:27Our agent will parse the transcript and then um again it will extract the critical sales medpic data uh metrics economic buyer decision criteria plan and champion and draft a grounded followup for that. Every LLM step is traced so that we can evaluate quality and improve over time.

14:53The third layer is what turns this automation into a system that self-improves. Every action is a decision log and every outcome threads back to the decision that caused it. So the naive version of this is a data analyst coming in and trying to understand if the output of this could be better.

15:08The rebuilt version of this is wiring our engagement history back into the decision layer so that the system decides whether or not to continue a thread, advance to the next step or pivot. The system will continue to do that with the life cycle message performance history as well.

15:23So these verification loops are really critical so that the system can self-heal and continuously improve. Let's see how an agent and human work together in this shared customer view. In the customer view, a rep can come here and see the product usage, the recent activity and get an answer using that same data.

15:50They used to find all of this across many different tabs and now they can just come here each day. The rep can ask an agent and the agent will reply uh querying our context layer. We can also use notion custom agents which

A rep's day starting from a prioritized task box

16:06are sharable across companies to access this data context for recurring automated workflows. In the task view, a rep starts their day with an already prioritized task box and they already know how to move forward with accounts and contacts.

16:22And the email draft for an outreach task is already pre-ressearched and available for them to review. The human is still in the loop and actually adds their own judgment and taste um and sales secret sauce, but they're no longer starting from a blank sta slate.

16:37And this does more than one help one rep be productive. Um our goal is actually to raise the floor for the entire team. So a Neil sales rep coming in, they can learn the notion sales process, understand what signals are important to look for, um, understand which playbooks are effective, and basically know what good followup looks like.

17:01Reps who can are ramping can still learn from the patterns of the strongest reps without needing every lesson to be passed down manually. So, one of the questions that we came across along every step of the way is a classic question. Do we build or buy?

Build or buy, decided per layer

17:25And it's very tempting and trendy to say build everything. But what we found is that there are still key areas to build and rent access to at every single layer. Internal agents are actually cheaper and faster to build than most people assume.

17:40And so since we have the most data on our con on our data model um we build it there first and then we uh rented the generalizable parts later. So for us the build versus buy as a per layer decision. We will not build a lot of these tools like orchestration, email, CRM.

17:58Um vendors do that really well. We refuse to outsource the context layer because that's where our edge is. a generic tool can't capture all of our esoteric data models or workflows and we do not want that context layer to be something we can't um debug and so as I mentioned before that context layer is a notion it's built off of plain markdown a language that agents are fluent in and we have databases and hierarchies that they can navigate easily at the same time this is well designed for human um so this is what lets our engineers, agents, and GTM work off the same context.

18:40And this has all the data synced across sources. Ultimately, the reason to see if we can do all of this is to see if we could get a better throughput on deals. It's very early for us. We're still building this

Early numbers and takeaways

18:56out, but the initial signs are promising. In the last 13 weeks, we are already seeing enterprise reps have increased qualification or qualified opportunities. And on the life cycle marketing side, users who received contextaware recommendations were 63% more likely to take the next step.

19:12This is the early days with a lot more features we want to build, but our thesis that us building a single system on no, decide, act, and learn seems to be right so far. A few key takeaways. um from entering entering this world as an engineer in the last six months is that before you build shadow your best human.

19:34I talked to many sales reps and when I opened uh when they opened their computers I saw how many tabs and tools they were navigating between and that was a chaos but it was also the spec and so if you encode a mediocre process you get a mediocre agent.

19:50Start with the most legible workflow. That's the one that's documented and repeated. And let humans stay in the loop on where there are risky possibilities. Model GTM as primitives, entities, context, triggers, actions, eligibility rules, and the alien world becomes a system you can engineer.

20:10Last but not least, be headless by default and design for agents as operators and not just co-pilots. If humans and agents can't read from the same substrate, you're basically building two systems that will eventually drift apart. For us, that layer is notion.

20:30Right now, humans are the primary consumer of GTM data and agents are helping at the edges. Soon, agents will become primary first class consumers within the system, moving from drafting to acting within guard rails by creating the best context and substrate for humans and agents to collaborate together.

20:47Now, you're setting up your team to sprint faster. Um, yeah, and feel free to contact me if you guys want to ask more questions.