How should an enterprise software startup design its proof-of-concept pilot?

Illustrative situation: a startup sells invoice-matching software. The head of accounts payable at a prospect agrees to a six-week proof of concept (POC). The startup creates a tenant, loads a demo dataset and sends invitations. In week three the security lead asks where the pilot’s data lives, the finance director asks what “success” was agreed, and nobody can say how many invited people have logged in. The scene is invented. It shows the gap this guide covers: the pilot gets run as a sales activity, and its product experience belongs to nobody.

Humbleteam, a digital product design agency, publishes this guide. It treats the pilot as a product surface with its own readers, data, clock and exit, and it includes a plan worksheet and an invented worked example. Vendor behavior below is described as of October 30, 2026 and can change.

Who judges a pilot, and what does each person need to see?

Gartner’s May 2025 release on B2B buying groups says these groups range from five to 16 people across as many as four functions. In a survey of 632 buyers, groups that reached consensus were 2.5 times more likely to call their deal high quality. The MEDDICC sales methodology names two of those people: the economic buyer, who holds overall authority over the decision, and the champion, who has power, influence and credibility inside the customer.

Our suggestion is to design for four evaluators, each with a different question:

• The champion asks whether the pilot makes the case internally. The champion needs progress against the agreed goals and something to forward.
• End users ask whether they can do real work faster. They need their own tasks, not a product tour.
• The economic buyer asks whether the result is worth the price. The buyer needs one page in the buyer’s own measures.
• IT and security ask whether the product can run safely. They need the admin items in one place.

Give each a named role in the pilot tenant so the product shows each person what that person needs. Our roles and permissions guide covers the role model.

What should the pilot plan say before anyone logs in?

Camunda’s guidance on judging a POC says to document objectives and key performance indicators at the start, confirm with users and stakeholders that their interests are covered, and keep a requirements matrix. Each row holds the requirement, how to test it, the expected result and a pass or fail. MEDDICC defines metrics as quantifiable measures of value and decision criteria as the requirements an organization uses to decide.

The design step is to put the agreed criteria inside the product, not in a slide. Our suggestion is a goals panel on the tenant home page. Each criterion shows its owner, baseline, target, current value and a link to the evidence. The champion and the evaluators then argue about the same numbers.

Should the pilot use sample data or the customer’s own data?

Both, in order. Vendors show three levels. Snowflake supplies a shared sample database that uses no storage in the customer’s account. Salesforce describes sandbox types with no data, with a sample of production data, or with all of it. Atlassian says copying production data into a sandbox can take up to 14 days depending on size. It does not copy webhooks or OAuth tokens, and it disables third-party app links and notification emails, so production and its users are not affected.

Three design consequences, all our suggestions:

• Run day one on seeded data shaped like the customer’s industry. A copy or import that takes days would otherwise eat the pilot.
• Label the source on every screen: a “Sample data” badge that becomes “Your data, imported on [date]”. Never mix the two in one chart.
• Make the switch a visible event that can be undone. Hide sample data after the import and delete it only at conversion.

Keep outbound email, webhooks and integrations off until the customer enables each one, as Atlassian does in its sandboxes. If the customer’s data includes personal data, the contract decides what you may hold and for how long. That paper process is outside this guide.

What should the workspace show in week one?

A home page can have five parts: the goals panel, the end date with days left, the people (invited, joined and active, by role), the data source and its status, and one next step per person. Snowflake shows a tile with the remaining trial balance, and Databricks puts a Manage trial button in the top bar. Both keep the clock inside the product, which is the habit to copy.

Invited evaluators arrive in a workspace someone else built. Our second-user onboarding guide covers that first visit.

IT and security will check single sign-on, roles, the audit trail and data handling during the pilot. We only name them here. What the design team owns is findability: one Security and admin page that says where each item lives, who owns it on your side, and what is not switched on in the pilot tenant yet. A plain line such as “Single sign-on: available, enabled at conversion” answers the question before anyone emails it.

What should the champion get as reporting?

We suggest a weekly report generated from the tenant, in two parts. The first is usage: who was invited, who is active, and which tasks were completed, by role. The second is outcomes: each criterion with baseline, current value, target and status. State what is off track and why. A raw count of events gives the champion nothing to forward.

Make the report readable without a login, because the champion will send it to people who never open the product. Camunda advises gathering feedback from the users who tried the POC, so add a one-question prompt after key tasks and put the answers in the report.

How long should a pilot run, and what happens at the end?

No source read for this guide sets a standard length for a paid pilot. Self-serve trials give a reference, and their endings differ.

Snowflake, Databricks and Fabric share a pattern: the work stays attached to the same account or workspace when it is upgraded. For the pilot, we suggest three endings, each a screen the champion can reach from the goals panel.

• Convert. Same tenant, same links, same people and roles. Work the customer created, such as saved views, rules and imported data, stays. Sample data goes. Show a “what changes” list before the final click.
• Extend. Allowed once, with a reason and a new date that appears in the goals panel.
• Close. The customer chooses export, deletion or both. Under GDPR Article 28, a processor deletes or returns personal data at the controller’s choice when the service ends, so the screen should ask which. Confirm in writing what was deleted and, if backups linger, for how long.

Add notices as the end date approaches, and finish with a decision page: each criterion met or missed, with evidence. It is the document the economic buyer signs.

Illustrative worked example: a six-week pilot for invoice-matching software

Everything here is invented. Tallowmere is a fictional invoice-matching product. Brindlecombe Foods is a fictional customer. The evaluators are Ines Varga (head of accounts payable and champion), two accounts-payable clerks, Tomas Reeve (finance director and economic buyer) and a security lead.

In week zero the team agrees three criteria and enters them in the goals panel: at least 80 percent of invoices matched without manual work on a 500-invoice sample, the baseline being 61 percent; clerk time per invoice cut by a third; and every security checklist item closed. Days one to three run on seeded invoices under a “Sample data” badge. On day four Ines Varga uploads 500 real invoices and the badge changes to “Brindlecombe data”.

The week-three report shows 74 percent matched, names the three supplier formats that fail, and shows four of five clerks active that week. Tomas Reeve opens it from a link, with no login. The security page lists single sign-on as “enabled at conversion” and the audit trail as “available in the pilot”.

At week six, the decision page shows two criteria met and the match rate at 77 percent. Ines Varga picks Extend, once, for two weeks, and the reason is recorded. Two weeks later the match rate reaches 82 percent and the team picks Convert. The “what changes” list shows that the 500 invoices and saved matching rules stay, the sample invoices go, and the invitation limit lifts. Had Brindlecombe chosen Close, the dialog would have asked for export, deletion or both.

Where do these defaults stop working?

The sources are a Gartner release, sales-methodology pages, and vendor documentation for self-serve trials. None of them studies paid enterprise pilots or pilot workspaces, and no such study was found. Self-serve trials are not negotiated pilots, so treat their lengths and endings as reference points. The contract, security questionnaire, procurement and pricing of a paid pilot are outside this guide, as are customers who require a dedicated or on-premise environment.

What can you produce now?

Six things, before anyone draws a screen:

1. An evaluator map: the people on the customer side, their role in the tenant and their question.
2. The pilot plan worksheet, filled in for your next real prospect.
3. A spec for the goals panel: fields, owners and update rules.
4. A data plan: what is seeded, what is imported, when the badge changes and what stays off.
5. The three ending screens with their copy: Convert, Extend and Close.
6. A champion report template with its usage and outcome parts.

With those, you can decide the open questions: who judges the pilot, how long it runs and what a clean ending looks like. If you plan to bring in outside designers, ask each team to fill in the worksheet for one evaluator and sketch the Close screen. Our comparison of UX/UI agencies that design complex B2B SaaS platforms shows which studios publish work on screens like these.