Window shopping may be enough to attract someone looking to make a splurge purchase, but buying B2B software is more like purchasing a vehicle:
Potential customers want to take your product for a serious test drive before committing.
But for technically complex software sales, facilitating a successful test drive is not as simple as tossing someone a set of keys.
To prevent important deals from falling through at the 11th hour due to legal redlines, security issues, and other stakeholder hangups, sales teams need to not only provide access to a product trial, but help guide the client through a successful product testing experience.
This is where a sales proof of concept comes in.
This guide will provide an overview of the components of effective sales proof of concepts, including tips for pitching and executing them, best practices, and a template you can start using today.
What is a sales proof of concept?
A sales proof of concept (POC) is a paid or free software trial where the seller provides hands-on implementation and technical support to the prospect testing the software. You might also hear them referred to as proof of value (POV), guided trials, or pilots.
The primary purpose of a sales POC is to get a commitment from a prospect to purchase following a successful trial period. To do this, you’ll need to work together with the prospect during the process to agree on:
- Success criteria: What needs to happen by the end of the POC to move forward with a long-term contract?
- Timeline: How long should the program be, when does it need to launch, and what are the key milestones?
- Project plan: What technical action, stakeholder signoff, and security reviews need to happen as part of the launch?
- Stakeholders: Who needs to be involved on the seller side and customer side, and who is making the final decision?
What makes a proof of concept different from a simple product trial is that it is not self-guided by the prospect, but rather a joint effort that builds on a pre-existing relationship they have with a selling team.
Sales POCs typically require a not-insubstantial investment of time and resources on both the seller’s and prospect’s side to ensure a successful outcome with the product and justify the cost as part of the sales process.
To increase the chance of success and drive a purchase following the completion of the pilot period, you’ll want to create formal sales POC documentation stating the problem to be solved, intended outcome, scope, stakeholders, and timeline for the trial period.
Why is a sales proof of concept valuable?
At the core of a sales POC is a commitment by the evaluating party to not simply passively try out the product, but actively use it in real-world scenarios with the intention to buy once the agreed-upon outcomes are met.
In other words, the goal of your POC plan is to help your prospective customer agree on what it will take to sign up as a customer, and establish a roadmap for proving that value and utility to them.
Once those success criteria are met, there are (in theory) no other objections that would need to be overcome and you can proceed with completing the sale.
When should you run a sales proof of concept?
There are several scenarios where sales POCs tend to add a lot of value to the sales process:
Highly technical products
For technical products, there’s often a large amount of real work involved in implementing the tool. Engineers on both sides need to set up API integrations, databases, or other architecture, and legal and security teams need to ensure the product will be compliant. This work is costly, so a sales POC helps ensure there’s some agreement on both sides about the outcome of the work.
For startups, a sales POC can help reduce some of the fear for a prospect of investing time in a product that is unproven and not market-tested. A POC is really helpful for startups to drive alignment around what success looks like while also gathering valuable user feedback on the path to finding product-market fit.
With a POC established, prospects have more ability to impact the roadmap of the product—for example, by weaving in future product updates into the milestones and deliverables of the POC.
Product-led growth (PLG) companies
For companies that rely on PLG, a sales POC can be a powerful way to get your foot in the door with a new logo before expanding. For example, you could run a POC project with one team or one product before expanding organization-wide or introducing new products.
Best practices for running a successful sales proof of concept
Executing a sales POC might seem complicated at first, but it’s achievable with careful planning, organization, and communication.
Here are some tips and best practices for running a successful proof of concept, broken down into three key activities:
- pitching the idea of doing a sales POC to a prospect,
- building out a sales POC plan, and
- executing a successful program.
1. Pitch the sales POC as a mutual success plan
How do you introduce the concept of a POC to a prospect? By positioning it as building a mutual success plan rather than as a sales trial.
If your prospect is showing signs of being ready for the next steps (you might hear them mentioning wanting to dig around your product, or mentioning bringing other people on their team into the sales conversation to get their expertise), it’s time to pitch a sales POC.
While it’s true that a sales POC requires a lot of customization and personalization to be successful, it’s important to position it as a professional, organized, well-oiled process—not as an ad hoc solution you’re coming up with on the spot.
Introducing it as common practice for how you onboard all of your customers can help instill confidence in the customer—especially if they’ve never participated in a proof of concept program before and are hesitant to try.
To get a “yes” on running a sales POC, you’ll want to anchor around your prospects’ success metrics—not force them into use cases or features that may be useful down the road with an expanded program, but won’t help close the deal in the short term.
To do this, ask questions upfront like:
- “If we were to run a proof of concept program with you, what would you need to have happened to consider it a success?”
- “What use cases are most important for you to test in our product right now?”
- “On our end, we’d like to involve [team members from sales, customer success, engineering] to make sure we get you set up in our product and help shorten your learning curve. Who should we involve in this process on your end for stakeholder input?”
- “After the proof of concept period is over, and assuming it is successful, would there be any other roadblocks on your end to continuing working with us?”
The conversation shouldn’t feel like sales, but rather building a shared project plan that leads to mutual success.
2. Run your POC from a single workspace
Once you have a commitment to start a POC, keeping tracking of progress against your stated goals in one centralized workspace is critical to measuring success of the program and communicating that success to the client.
You could do all this work in Google Docs or Sheets, but it can be messy to track progress or make adjustments as you go along.
Managing your POC with a customer collaboration platform like Dock instead gets you started on the right foot—instilling confidence in your client by providing a hub for them to track the progress of the POC.
Centralizing all communication, to-dos, documentation, and questions related to the ongoing POC in a single Dock workspace greatly simplifies the POC process for your client.
As a starting point, you can model your POC workspace from our Sales Proof of Concept Template.
While you can tailor your sales POC to specific clients, it should typically include these standard sections:
1. Overview: This section should include a statement of the problem that is being solved for the client during the program, and the approach the selling team will be taking to implement the pilot program.
2. Stakeholders: Here, you’ll want to outline both the partner team (your team) and evaluation team (your client’s team) stakeholders and decision makers. This ensures that everyone has the necessary context upfront and helps eliminate last-minute inclusions of people who should have been involved from the start.
- On the partner team side, include product and engineering team members to help with technical implementation, as well as a solutions architect, on top of the primary sales point of contact on the account.
- On the evaluation team side, mirror your partner team’s setup with people from engineering and product, but also include any procurement, legal, or security team members from the client.
3. Success criteria: These are the specific metrics (usually about 3-4 items) for determining whether the sales POC was a success. These should be co-created with the client, not dictated by one party to the other.
4. Milestones: This section contains all the required inputs and expected outputs, along with formalizing the success criteria to determine when the goals of the program have been met. You should also include a project plan section for tracking when these milestones will be hit with specific dates.
- In addition to milestones related to actual product testing and implementation, you’ll also want to include milestones for evaluating the success of the program and follow-on meetings to evaluate a long-term contract. This will help you make sure there’s no weird drop-off of contact after the program ends, and ensure the client is reminded of the commitment to move toward a purchasing decision.
5. Solution overview: Here, you should include all relevant resources, sales materials, walkthroughs, documentation, and other content that shows the value of the product to the client.
3. Execute the proof of concept program
Once you’ve got your sales proof of concept program underway, the work isn’t over! Here are some tips for executing a best-in-class sales POC program:
- Stay consistent: Don’t fudge on the dates you’ve committed to in the milestones section of your sales POC doc—this is the quickest way to lose trust. Schedule routine check-ins with an agenda shared ahead of time, and keep notes in your centralized hub to make sure items are followed up on by your partner team.
- Over-communicate: Never assume that hearing crickets from the client during the POC program means they’re having a seamless, enjoyable experience free of questions—chances are it’s the opposite. Proactively reach out to make sure they aren’t silently toiling in frustration or confusion about some aspect of your product, and quickly work to get rid of any obstructions.
- Surprise and delight: Seeing roaring success ahead of schedule? While you’ll want to be mindful of not overloading your team with extra work wildly out of scope, look for opportunities to show additional product functionality, demo beta features, or provide additional hands-on help that will build a lasting relationship and strengthen your alignment on your goals.
💡Tip: Dock’s analytics let you track how often your customer interacts with your POC workspace. That makes it easier to tell what type of quiet they are when they go quiet. Lots of engagement? They’re probably stuck on something technical. No engagement? Time for a follow-up.
Build your next sales proof of concept with Dock
If you’re ready to close more deals using a sales proof of concept program, use a customer collaboration tool like Dock to make it a success.
With Dock, you can:
- Collect all critical POC documentation in one place: Clarify the POC project scope, timeline, key contacts and project stakeholders, and success criteria all from one interactive hub page—and even keep a repository of recorded meetings, research documents, and more.
- Establish the next steps to take you from concept to approval: Get key contacts to complete the relevant steps, build your case for decision-makers, and use the gathered data to get the project go-ahead so you can focus on delivering an excellent product experience for your client, faster.
- See what you need to tweak: Get in-template feedback from users and see what links they click on most to make your POC process as simple and effective as possible.