AI in GTM at Notion — Flora Liu

0:01 [music] Well, 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

0:22 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.

0:33 GTM 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

0:46 last few months, a small team and myself, um, we've been trying to turn this spider web into a unified GTM system. We're still in the midst of it, but we've learned a ton that I'd like to

0:57 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,

1:10 sales automations, customer data, and onboarding. But the solutions were fragmented because the underlying technology forced them to be. Then over the winter break, our CEO Ivan

1:23 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. At the same time, our

1:36 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

1:49 now be sorted. So, what we found is that GTM had become a systems problem. That made us realize we could chip away at this holistically. In case you don't know, notion's

2:02 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. Notion's business moves

2:15 between self-s serve growth and sales assist. Um, and customers move between these two motions all the time. The problem is that customers experience one journey, but internally it is

2:29 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. For example, sales

2:42 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,

2:55 doing research, drafting follow-up, they were spending less time with our customers and customer problems. Most companies have separate systems for sales assist and productled growth. And

3:07 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

3:20 decisions separately. So 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

3:34 is cohesive. Our vision is for this system to be programmable, proactive and continuous. When we started, we were faced with some

3:46 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

3:58 decade of the most important context lived in notes and meeting docs. Yes, our sales reps do use notion for that too. Notion employees were actively using MCPs and their own agents to solve

4:10 problems already, but they were innovating within their own departments. So it was single player mode or you could say here single department mode. Marketing built tools for tool uh

4:21 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.

4:34 When 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

4:46 lose trust for sales rep. Secondly, data latency. Every 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.

5:00 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

5:12 again. Um 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

5:24 it, it could do something catastrophically wrong. So our project team consisted of CX, RevOps, product, engineering, sales. And after brainstorming together, we all

5:38 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

5:50 happen next? How do we execute that safely? And did it work? That became our architecture. So the system has four layers. Know a context layer we can trust about every

6:04 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

6:20 watch what happened and feed it back into the decisioning so that it's a loop. But this architecture is missing something important.

6:31 The most important part is that humans and agents are operating on the same loop. Concretely, this means that the context needs to be displayed so that humans and agents can read and operate

6:43 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

6:54 context, researching, drafting recommendations, and writing artifacts. Humans provide the judgment, adding nuance, deciding what to do next, and if a recommendation is correct. and owning

7:07 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

7:18 within the same system as humans. Before 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

7:31 to 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

7:45 security dimension too. If a prospect fills out a contact sales form online, we treat that as untrusted user input. And so trust boundaries don't break down, especially because there is an

7:57 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

8:09 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

8:22 segmentations or signal signal definitions and then a single classifier will route what the customer should do and this will actually prevent double sends from our system and create very

8:34 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

8:47 not build our own email vendor or enrichment services like Clay. We use Clay and we believe that we understood our customers the best. So we will not um give that away.

9:01 So let's get into what we built. The first step was to gather a consolidated view of all of our customers. Snowflake, which is our data warehouse,

9:11 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

9:23 versioned entities and these are accounts, contacts, workspaces, eligibility, and facts. And this also has clear ownership of what teams or uh tools they come from and like

9:35 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

9:47 quickly query in milliseconds with no joins. We also persist agent uh persisted uh or generated artifacts and these are research snippets, summarized notes, rolling summaries and these

10:00 unstructured data are also keyed by the same ids so that downstream systems can read all of this in one shot. So this data was normalized and of course we brought it into notion so that

10:14 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

10:24 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:36 And 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

10:48 to explore context, investigate investigate accounts, answer questions, and they could even take actions like sending to Nooks or um sending to outreach. This is a tool that they were

11:01 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.

11:13 In a very literal sense, we are using notion to grow notion. The next primitive we decided that we needed was a way to turn customer events into actions. The unit here is a signal.

11:29 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

11:41 out to contact contact sales. But 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

11:53 their tech stack. Those external signals are what allowed us to be proactive instead of reactive. So this is the signal service that watches the customer profile, decides

12:06 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

12:19 agent. If 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

12:30 we built our GTM systems is that if there is no signal about a customer, the marketing component of our system kicks in. We have a predictive engine that will recommend product features most

12:42 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.

12:55 So diving deep into a small slice of what happens when we decide what action should be emitted. Um this is for like the sales workflow and we shadowed our best reps to capture something that was

13:09 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

13:22 enrichment web search draft generation and more. Each 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

13:37 while it will handle the retries, ddupes um and handling and going back to exactly where failures left off. and one malformed transcript can't take down the whole batch which was really important

13:50 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

14:04 so they're scored and then a review agent will pick the highest scoring one and make any updates if necessary. And this also operates on a loop um so that the email drafts are improved. And then

14:16 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. Our

14:29 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

14:44 for that. Every LLM step is traced so that we can evaluate quality and improve over time. The third layer is what turns this automation into a system that

14:57 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

15:10 understand if the output of this could be better. The rebuilt version of this is wiring our engagement history back into the decision layer so that the system decides whether or not to

15:21 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. So these verification loops are really critical

15:34 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

15:45 here and see the product usage, the recent activity and get an answer using that same data. They used to find all of this across many different tabs and now they can just come here each day. The

15:57 rep can ask an agent and the agent will reply uh querying our context layer. We can also use notion custom agents which are sharable across companies to access this data context for recurring

16:11 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. And the

16:25 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

16:37 sauce, but they're no longer starting from a blank sta slate. And this does more than one help one rep be productive. Um our goal is actually to raise the floor for the entire team. So

16:51 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

17:04 good followup looks like. Reps who can are ramping can still learn from the patterns of the strongest reps without needing every lesson to be passed down manually.

17:16 So, one of the questions that we came across along every step of the way is a classic question. Do we build or buy? And it's very tempting and trendy to say build everything. But what we found is

17:30 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. And so since we have the

17:43 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

17:56 of these tools like orchestration, email, CRM. Um 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

18:09 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

18:24 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

18:37 lets our engineers, agents, and GTM work off the same context. And 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

18:52 a better throughput on deals. It's very early for us. We're still building this out, but the initial signs are promising. In the last 13 weeks, we are already seeing enterprise reps have

19:03 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. This

19:15 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.

19:26 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. I talked to many sales reps and when I opened uh

19:39 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

19:50 mediocre agent. Start 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.

20:02 Model GTM as primitives, entities, context, triggers, actions, eligibility rules, and the alien world becomes a system you can engineer. Last but not least, be headless by default and design

20:16 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

20:28 layer is notion. Right now, humans are the primary consumer of GTM data and agents are helping at the edges. Soon, agents will become primary first class consumers

20:39 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. Now, you're setting up your

20:51 team to sprint faster. Um, yeah, and feel free to contact me if you guys want to ask more questions. >> [music]