diff --git a/contents/handbook/growth/sales/new-sales.md b/contents/handbook/growth/sales/new-sales.md index 76e6f4bd19bf..0b7d1dc3e8ac 100644 --- a/contents/handbook/growth/sales/new-sales.md +++ b/contents/handbook/growth/sales/new-sales.md @@ -6,7 +6,9 @@ showTitle: true This is our playbook for managing inbound sales, ie. customers who have contacted the sales team directly. -Three principles to bear in mind: +We [build PostHog for product engineers](/handbook/who-we-are-building-for). While many non-technical folks use PostHog successfully every day, our inbound sales process is built with technical folks in mind. Once implemented, a customer may use PostHog for all manner of things (and we hope they do!). + +Three other general principles to bear in mind: - Aim to **drive the sales process** as much as possible. Most of our customers in our core segment don't regularly buy software like PostHog, so you will need to guide them through the process - for fast growing startups, this may be their first time. Even for much larger customers, this still may be the case. Remember that we've sold software hundreds of times - it's ok to guide the customer here. Inbound leads =/= the customer wants to drive. - **Discovery is an ongoing process** - you want to be finding out useful information at each stage, not just going through a checklist at the beginning. Asking 'why' can be a really powerful tool, and you should be curious throughout, not just selling. @@ -19,7 +21,7 @@ Selling software, especially to larger companies, can be a complex process with * Pain - Do they have a problem? * Is it painful enough right now that they are willing to adopt a new solution to solve it? * Will PostHog solve this problem for them? -* Timeline - When do whey want to have a contract signed/solution in place? +* Timeline - When do they want to have a contract signed/solution in place? * Pricing - We should know the rough size of the opportunity, and that that is in line with expectations and budget of the customer. * Champion - Are you working with a champion who is going to sell internally? * Are they the buyer (see below) or do they know who the buyer is? @@ -45,11 +47,12 @@ This is an overview for what you should actually be doing with a customer at eac 1. People contact us 2. We assign and qualify -3. Initial demo -4. Product evaluation -5. Security & legal review (only if asked - skip otherwise) -6. Commercial evaluation -7. Closed - Won or Lost +3. First call (30 minutes) - Discovery & initial demo +4. Second call (60 minutes) - Technical deep dive (if needed) +5. Product evaluation +6. Security & legal review (only if asked - skip otherwise) +7. Commercial evaluation +8. Closed - Won or Lost ### 1. People contact us @@ -57,14 +60,17 @@ Most people fill in the [form](/talk-to-a-human) via the website. Some email sal ### 2. We assign and qualify -Info on how leads are assigned can be [found here](https://posthog.com/handbook/growth/sales/crm#how-we-do-lead-assessment). Once you have been assigned a lead, you'll want to qualify them - don't just immediately go out and offer a demo every time. Things to consider: +Info on how leads are assigned can be [found here](handbook/growth/sales/crm#how-we-do-lead-assignments). Once you have been assigned a lead, you'll want to qualify them before scheduling a call. Things to consider: - What is their [Lead Score](/handbook/growth/sales/lead-scoring)? - Which products are they looking to use? What's their use case? - How large is their company? Revenue? Have they raised funding? (ie. will they pay >$20k for PostHog?) - What is the role of the person who filled out the form? +- Are engineers already involved in the sales process, or will they need to be brought in? + +Most companies add friction here by making customers jump on a call first to qualify them. We don't do this when we are confident that product engineers are, or will become, involved in the sale. We may ask for a 2nd call with the engineers involved if we're confident that PostHog can help and want to make sure they agree. -Most companies add friction here by making customers jump on a call first to qualify them - we don't do this because it's annoying to the customer. However, it's totally fine to ask them questions over email in advance of the demo to make sure you're making the best use of their time - just be specific. A few clarifying questions is fine, a 30 question survey is not. +It's also totally fine to ask a customer questions over email in advance of the demo to make sure you're making the best use of their time - just be specific. A few clarifying questions is fine, a 30 question survey is not. > **Examples of good discovery questions - this is not a script, just ideas!** > - What is the problem? What is this problem affecting? @@ -77,7 +83,7 @@ Most companies add friction here by making customers jump on a call first to qua > - Who owns that data stack? Do you have a data team or data engineers? > - Who will be the consumers of PostHog data? How are they currently answering their questions, and how easy is it for them to do so with existing tooling? -If you're pretty sure that they should be qualified out, you should still be helpful over email - some customers just use the form to get in touch and don't want to actually have a demo (e.g. they have a billing question or are asking about compliance things like HIPAA.) +If you're pretty sure that they should be qualified out of our sales process, you should still be helpful over email - some customers just use the form to get in touch and don't want to actually have a demo (e.g. they have a billing question or are asking about compliance things like HIPAA.) #### Requests for Proposals (RFPs) @@ -86,19 +92,20 @@ There are two types of RFPs: - We have context on what they're trying to accomplish and where we have qualified their specific needs ahead of time. These are *solicited* RFPs, and we generally reply to these. - We just get an RFP randomly without any context. These are *unsolicited* RFPs, and we generally don't reply to these. -If it's an unsolicited RFP where we haven't had any prior contact or usage from the company then it is **highly likely** that you will burn a lot of time for nothing and you are free to decline. If you find the unsolicited RFP otherwise compelling and want to proceed, the suggested approach here is to see if anyone from the company has recently signed up to PostHog. If so, then make contact with them to see if they are aware of the RFP and can provide more information on PostHog's inclusion. +If it's an unsolicited RFP where we haven't had any prior contact or usage from the company then it is **highly likely** that you will burn a lot of time for nothing and you are free to decline. If you find the unsolicited RFP otherwise compelling and want to proceed, the suggested approach here is to see if anyone from the company has recently signed up to PostHog. If so, then make contact with them to see if they are aware of the RFP and can provide more information on PostHog's inclusion. -If you can't identify anyone who has recently signed up to PostHog, then ask the person who sent you the RFP for a call to gather more context before making a decision on whether to fill it in. If they aren't willing to get on a call then it's likely that we are not their vendor of choice, and they are using us to make up the numbers in a tender process. As such, we shouldn't spend time on this kind of activity. If you choose to spend time with these, timebox your effort to ensure you are not devoting a week to a 500 question RFP where we have very slim chances of success. Your time is your most valuable asset. +If you can't identify anyone who has recently signed up to PostHog, then ask the person who sent you the RFP for a call to gather more context before making a decision on whether to fill it in. If they aren't willing to get on a call then it's likely that we are not their vendor of choice, and they are using us to make up the numbers in a tender process. As such, we shouldn't spend time on this kind of activity. If you choose to spend time with these, timebox your effort to ensure you are not devoting a week to a 500 question RFP where we have very slim chances of success. Your time is your most valuable asset. -If it's a solicited RFP, you're free to proceed so long as the opportunity is qualified as a whole and you carefully balance the level of effort required in the RFP against the opportunity for you & PostHog. Again, a 500 question RFP may not be worth it if they plan on spending <$20k for PostHog (a 50 question RFP may not even be worth it in this instance)! Use your best judgement, and it is generally still wise to timebox your effort. +If it's a solicited RFP, you're free to proceed so long as the opportunity is qualified as a whole and you carefully balance the level of effort required in the RFP against the opportunity for you & PostHog. Again, a 500 question RFP may not be worth it if they plan on spending <$20k for PostHog (a 50 question RFP may not even be worth it in this instance)! Use your best judgement, and it is generally still wise to timebox your effort. -#### Startups +#### Startups If they're eligible for the [Startup Plan](/startups), route them to the application form and disqualify them as it's not an immediate opportunity (but we sincerely hope they grow into loyal PostHog customers). If their usage will burn through their credits quickly, you should feel free to switch their lead status to `Nurture` and keep close tabs on them. Per our [usual approach to sales](/handbook/growth/sales/overview), we want to make sure they're successful in this "high-use" scenario and are building with us for the long-term. You can also redirect them to use the In-app support modal if they have a product-related question - this will then be routed to the right team, as well as showing them CTAs to upgrade for high priority support. #### Leads below the sales assist threshold (less than $20K ARR) + We often get requests for demos from leads or existing customers who are below our sales assist threshold, and who don't have a defined use case for PostHog. It usually comes in the form of "show me all the features" or "I need someone to demo to me." These can be large time sinks because they are non-technical, don't have a clear idea of what they want, and are unlikely to ever grow into a sales-assist level customer. *We also want to be helpful to our current or potential customers, regardless of spend.* Time permitting, we can offer a demo if they are willing to give us the information we need to put something together: @@ -107,51 +114,142 @@ We often get requests for demos from leads or existing customers who are below o - What features / products are you interested in? - What questions do you have? -This makes the the demo actually valuable and can be an opportunity for you to learn more and get some demo practice. You'll also find that 90% of these requesters never respond because they are either unable or unwilling to engage with the questions, which allows you to avoid the biggest time sinks. +This makes the demo actually valuable and can be an opportunity for you to learn more and get some demo practice. You'll also find that 90% of these requesters never respond because they are either unable or unwilling to engage with the questions, which allows you to avoid the biggest time sinks. + +If you realize that they will be too small (<$20k) to go through our sales-led process and you are unable to get this information from them, you should route to [self-serve](/handbook/growth/sales/crm#self-serve-opportunity-record-type). + + +### 3. First call (30 minutes) - Discovery & initial demo + +Your goals on this call depend on who shows up. You should know who's coming ahead of time and be prepared to change your approach based on the actual attendees. + +The ideal outcome is getting engineers to be hands-on with PostHog as quickly as possible. + +#### **Path A: Engineers are present on the first call** + +When you have engineers on the call from a qualified company (ICP fit or otherwise highly qualified), your goal is to get them using PostHog immediately. + +**Structure:** +1. **Intro & Qualification** (5-10 min) + - Friendly banter + - Focused discovery on their use case + - Articulate PostHog's vision and how it relates to their needs + - Show PostHog in a technical demo as soon as possible + +2. **Technical Demo** (15 min) + - Highly tailored to their use case + - Light on pitching, heavy on showing docs and GitHub + - Use our [Demo Project](https://eu.posthog.com/project/30021/) linked to [Hogflix](https://hogflix.dev/) + - Start with their biggest problem first, stay there until they're happy + +3. **Call Close** (5-10 min) + - **Part 1:** Confirm they agree PostHog solves their problem; scope what success looks like for their trial; answer questions, particularly around pricing: Secure [BANT](/handbook/growth/sales/new-sales#BANT) + - **Part 2:** Ask for trial signup or PostHog org conversion; confirm next steps on the call; ensure that any "give" by PostHog receives a "get" from the customer (typically feedback on the trial at this phase) + - Answer questions and objections + +**Success looks like:** +- They commit to using PostHog in a reasonable timeframe +- You have a plan to get their feedback on the product as soon as they use it -### 3. Initial demo +#### **Path B: No/minimal engineers present (non-technical stakeholders)** -This is basically a combo of discovery and demo call - your objectives here are to: +When engineers aren't on the call, your goal is to earn a second call with their engineering team, while also being helpful to the non-technical stakeholders in discussing PostHog. -- Show the customer PostHog and get them excited about working with us -- Find out as much as you reasonably can about them -- Have a solid plan for next steps in place +**Structure:** +1. **Intro** (5 min) + - Friendly banter + - Get [BANT](/handbook/growth/sales/new-sales#BANT) info upfront (Budget, Authority, Need, Timeline) + - Articulate PostHog's vision + - Scope their use case -We have various slide templates - ask someone on the Sales team for an invite to our Pitch account so you can create customized versions with your name etc. You should general use the deck as scaffolding, pulling out the relevant slides (e.g. pricing). Do not spend the demo presenting a deck - most people at PostHog spend 90% of the demo call actually in product or talking to the customer about their needs. +2. **Qualify or Disqualify** (10 min) - we do this politely and constructively. The customer's time is valuable and we know best who succeeds with PostHog, so we're driving the sale. + - **Qualify if:** They have technical capability to succeed, engineers will be involved in the sales process, and there's product/solution fit + - **Disqualify if:** They're non-technical with no engineer involvement, or there's no product/solution fit -We have a [Demo Project](https://eu.posthog.com/project/30021/) linked to [Hogflix](https://hogflix.dev/) that you can use. Before you demo, make sure there is enough data to properly showcase our features. If needed, you can use [Hogbot](https://github.com/PostHog/hogbot) to generate more synthetic data. This is built by the sales team for the sales team, so if you see anything you want to improve, don't hesitate to submit a PR! +3. **Demo** (10 min) + - **If qualifying:** Show enough to validate required functionality and earn the next call with engineers + - **If disqualifying:** Show what's needed to validate the lack of fit + +4. **Call Close** (5 min) + - **If qualifying:** Schedule the next call, ensure engineer attendance, set initial scope for technical demo + - **If disqualifying:** Direct them to better resources, politely thank them for their time, ask them to reach back out when engineers are involved + +**Success looks like:** +- **If qualifying:** You have a call with their engineers on the calendar (Step 5 below) and they understand why it will be helpful +- **If disqualifying:** They understand why PostHog isn't a fit right now and appreciate your helpful transparency + +> **Important:** If you can't get a second call scheduled, be skeptical of the opportunity. Keep the task in nurture status until it's on the calendar - only convert to an opportunity after the call is confirmed. + +#### General demo tips + +We have various slide templates - ask someone on the Sales team for an invite to our Pitch account. Use the deck as scaffolding, pulling out relevant slides. Do not spend the demo presenting a deck with an engineering team - most people at PostHog spend 90% of the demo call actually in product or talking to the customer about their needs. But sometimes, there is a legitimate need for a deck. + +Before you demo, make sure there is enough data to properly showcase our features. If needed, you can use [Hogbot](https://github.com/PostHog/hogbot) to generate more synthetic data. This is built by the sales team for the sales team, so if you see anything you want to improve, don't hesitate to submit a PR! You should give a relevant and pointed demo - don't just throw everything in, as the customer will get overwhelmed. If you don't show what's important first, people on the call will become distracted. -For example, a customer may say "we need to see how our customers our using our platform". In this case, a good approach is to go straight to Session Replay, then tie Replay into Analytics, then go from there. +For example, a customer may say "we need to see how our customers are using our platform". In this case, a good approach is to go straight to Session Replay, then tie Replay into Analytics, then go from there. > Start with what their biggest problem/request is, stay there until they are happy, then move on to point two. We don't want to fall into the trap of doing the same demo for each customer regardless of what they say at the beginning. Make sure you cover: -- Who is there and what their roles are - in particular, are they the decision-makers at their company? +- Who is there and what their roles are - in particular, are they the decision-makers? - Why do they _need_ PostHog? -- Opportunity for them to ask up-front questions and get direct answers to them -- Demo specific product features according to what they have asked for - _this is really important, don't just chat about PostHog's vision or give a high level product overview_ +- Demo specific product features according to what they asked for - Consider complementary products, e.g. analytics + replay; analytics + warehouse; surveys + flags - Don't [promise](/handbook/growth/sales/overview#enterprise-customers) things we can't/don't want to deliver - - Also use this as further discovery to see if PostHog is a good fit for them. -- How pricing works with an indication on their potential spend if you have enough information +- How pricing works with an indication of their potential spend if you have enough information - Next steps - this is really important, don't just end the demo with no clear follow-up action -To help you decide on whether and when to suggest a hands-on evaluation you should have a good idea about the following by the end of the call: +### 4. Second call - Path B (60 minutes) - Technical deep dive + +This call happens when engineers weren't on the first call. Your goal is to qualify the opportunity through the engineers and get them hands-on with PostHog. + +**Structure:** + +1. **Intro** (5 min) + - Friendly banter + - Confirm everyone's roles and responsibilities + - Set context from the previous call + - Reiterate PostHog's vision + +2. **Discovery** (15 min) + - Confirm use case(s) relative to the engineer's understanding + - Dig into the engineer's role in shipping and their workflow + - Confirm [BANT](/handbook/growth/sales/new-sales#BANT), particularly timeline as it relates to the PostHog implementation + - Understand their technical stack and how PostHog fits in + +3. **Technical Demo** (30 min) + - Given the likely mixed audience, you can take a broader view of PostHog and how it supports technical and non-technical users alike. + - Even so, cater to the engineer's role in the project and the power of PostHog for product/engineering teams + - Show relevant documentation and GitHub integrations + - Check for engagement from the buyer persona - note any disengagement + - Start with what their biggest problem is, stay there until they're happy, then move on + +4. **Call Close** (10 min) + - Ask for trial signup or PostHog org conversion - be specific in asking for clarity here. + - Ensure that any "give" by PostHog receives a "get" from the customer + - Answer questions and objections as they arise, particularly around pricing. + - Be specific about next steps + +**Success looks like:** +- You've met the engineers and understand their role +- You've qualified the customer's use case and involvement in the project +- You know when the engineers hands will be on keyboards trying PostHog +- You know how/when the opportunity will convert -1. Need - from this initial discussion is PostHog a good fit for them? Be honest if we are not so as not to waste your and the customer's time. -2. Budget - with usage-based pricing it can be hard to calculate where they may end-up pricing wise. You can calculate and share rough ballpark figure to set the right expectations based on: - * Which products they are looking to use - * Number of active users/sessions per month -3. Timeline - when are they looking to make a decision/have a contract in place? +#### BANT -If you realize that they will be too small (<$20k) to go through our sales-led process, you should route to [self-serve](/handbook/growth/sales/crm#self-serve-opportunity-record-type). +By the end of either the 1st or 2nd call with a customer, you should have a defined idea about: +1. **Budget** - Calculate and share a rough ballpark figure based on which products they'll use and their expected usage. Articulate the process by which a sales-led trial will help them refine the estimate. +2. **Need** - Is PostHog a good fit? Be politely honest if we're not, to avoid wasting everyone's time. +3. **Authority** - Who will make the decision at the customer organization? Who holds the budget? +4. **Timeline** - When does the trial start? When are they looking to make a decision/have a contract in place? -### 4. Product evaluation +### 5. Product evaluation -If you think they are a good prospect for our sales-led process, your first priority is to try and get them into [a shared Slack channel](/handbook/growth/sales/slack-channels) as quickly as possible. If you close them, this will also be their primary channel for support. Add the Pylon app to the channel and it will automate the support bot and channel description. React with a 🎫 to customer messages or tag `@support` to create a ticket in a thread. +Once qualified, and if you think they are a good prospect for our sales-led process, your first priority is to try and get them into trial of PostHog with [a shared Slack channel](/handbook/growth/sales/slack-channels) as quickly as possible. If you close them, a shared Slack channel will also be their primary channel for support. Add the Pylon app to the channel and it will automate the support bot and channel description. React with a 🎫 to customer messages or tag `@support` to create a ticket in a thread. Some customers may wish to use MS Teams rather than Slack - we can sync our Slack with Teams via Pylon to do this. First you will need an MS Teams licence - ask Simon for one. Then, set up [a Slack channel](/handbook/growth/sales/slack-channels). Then, [follow the instructions here](https://docs.usepylon.com/pylon-docs/integrations/chat/microsoft-teams) to get set up. Before adding the customer into the channel, remember to test it on both sides to ensure the integration is working correctly. @@ -208,7 +306,7 @@ The [Contracts](/handbook/growth/sales/contracts) page has full guidance on the Don't be the AE who gets to this point and suddenly realizes you have no idea who the buyer is! You should already know this, their budget, their purchasing process etc. already as part of your discovery - if you're finding out now, hopefully it's not too late... -By this point, you may have started running into some objections. These are the most common, and how to handle: +By this point, you may have run into some additional objections. These are the most common, and how to handle: - Gap in the product - introduce the customer to the relevant product engineer to build together (but first agree with product team if it’s a reasonable ask). We have found this approach works exceptionally well for our newer products. - Pricing issue - understand their budget; our [discounts](/handbook/growth/sales/contracts#discounts) section had the different levers you can pull to get a customer to the right price point. You can also help them tune their usage to lower costs. We don't buy customers out of existing contracts, and we don't do deals where year 1 is super cheap then we ratchet up the price in year 2.