We're an early-stage startup and just starting to build out our sales motion. A few months ago, we considered adopting a CRM. We asked our friends, advisors, and investors for advice, and we got two types of answers:
- "Get Salesforce"
- "We started on X but eventually ended up using Salesforce anyway"
They also came with a warning — “It might be too early for that” — and a recommendation to stick with Excel for now. We decided to make do with what we have and invest in Salesforce later once we have our first sales hire.
However, our company is not built on Excel, but Notion. We use it for engineering tickets, hiring pipeline, design docs, meeting notes, policies — pretty much everything. It also serves as our CRM, where we manually keep track of every conversation with a customer.
At product-led growth (PLG) companies, the sales conversations usually start with self-serve teams (free or paid). We wanted to make sure that they made their way into our Notion database and enrich the entries with some product metrics and revenue information.
While we don't have our CRM all figured out just yet, in the spirit of building in public, we want to share some of our learnings so far. In this article, I will share how you can build a PLG CRM database in Notion on your own, including:
- How to think about leveraging your warehouse and modeling your data
- How to stitch things together
- Workflows that your Notion CRM enables
- Key challenges and tradeoffs you should consider
Designing our Notion CRM solution
The architecture of our Notion CRM integrates the following components:
- The two key data sources are our app data and Stripe. We use Segment and Stitch to get the data into our data warehouse, where we do some enrichment on the top. For example, we add lists of domains that belong to universities and free email providers to distinguish potential sales prospects from students and hobbyists.
- We define models (for revenue, engagement, segments, and position in the user journey) using dbt and refresh data in our data warehouse on a daily basis.
- Then we use Deepnote to connect to both BigQuery and Notion, join the data, and update the Notion records every day.
Modeling our data
First, we'll need to prepare the data we'd like to add to the CRM. After chatting with Rez Khan and Justin Dignelli about their time building out the PLG motion at MongoDB, we learned it's a good idea to think about it in three steps:
1. Define the important metrics
What are the key actions that users take to get value from your product? For example, for a product like Deepnote, the key metrics are the number of created projects, the number of executed blocks, the number of team members, and whether users connected any integrations to the platform.
2. Define the customer journey
An example journey could be split into these steps, qualified by metrics defined in the previous step:
- Sign-up
- Activation
- Engagement
- Growth
Many of the important metrics are defined on a user level, and it's a good idea to think about how to aggregate them at a team level. Sometimes you may want a simple sum (how many projects did all team members create in total?) and other times the number of users who satisfied certain conditions (what proportion of team members executed at least five blocks?).
3. Define your segments
Once you've defined the customer journey and associated metrics, you can include additional information about user segments. For us, there are three big segments: business users – which are further split by the company size — individual users and hobbyists, and students.
Keeping our Notion CRM up to date
👉 Have a look at the example notebook here.
While you could get more granular information in the dedicated tools (Stripe, Mixpanel, etc.), the main value is in having a bigger picture in a centralized place that everyone can access.
This is where Deepnote comes into play.
Deepnote is a collaborative data notebook that can help you query the modeled data in the warehouse, fetch databases from your Notion pages through the Notion API, join and transform them as a combination of SQL and Python, and finally, update the relevant Notion fields.
What workflows does this enable?
Flag teams that need attention
We created a few new columns in our CRM for teams that might need attention that week. When a new company with many users signs up, we want to talk to them. When an older team of three expands to 15, we want to know. This integration allows us to capture these events using the defined metrics, assign the right tags in Notion, and get the attention of the right person.
Quick overview
We recently hired a new Vice President of Product at Deepnote. One of his questions was where to find the top 50 customers and a list of churned teams. After pointing to three sources with a hand-wavy explanation of caveats (e.g., "Stripe only includes recurring revenue in the list of top 100 customers, but a good portion of our revenue is usage-based, so you need to look here"), we realized we needed a source of truth that's easy to digest.
👉 If you'd like charts for things like the size of your pipeline, you can define them in Deepnote and embed them back to Notion. Read more.
Challenges & trade-offs to consider
Joining the data
We didn't have sufficient IDs in our Notion database before — we mostly used the name of the company and the email of the person we talked to, but this didn't always match the name of their team or the email of the team owner. There was a little manual work to add them to every existing entry.
Billing accounts
With our current data model, each team is also a billing account. While we might separate these in the future and allow multiple teams under one billing account, at the moment, there are companies with multiple teams. For the sake of simplicity, we keep each team as a separate entity in the CRM and link them to each other. This is not ideal, but we likely want to model the billing accounts in a more robust way than through a notebook.
Building your own CRM
Are we reinventing the wheel here? We might be. However, I think at the moment the effort required to implement the automation was a lot smaller than the team effort we'd need to adopt an existing tool — whether it’s an established player like Salesforce or one of the up-and-coming PLG CRM vendors.
In our current situation, the additional benefits of those tools do not seem to outweigh that additional effort. I’m certain that’s bound to change in the months to come, but for now, this is a really neat solution.
👉 At Deepnote, we're building a new kind of data notebook. It serves as a powerful interface on top of your data warehouse that allows you to create interactive applications and automate your daily work. Try it out!