diff --git a/nuxt/content/handbook/marketing/programs.md b/nuxt/content/handbook/marketing/programs.md index 8c2965f3f5..3c6651f54c 100644 --- a/nuxt/content/handbook/marketing/programs.md +++ b/nuxt/content/handbook/marketing/programs.md @@ -72,7 +72,7 @@ the value of our product. an excellent in-app experience. - **Sales-Led Proof of Concept (PoC)**: For larger or more complex deployments, prospective customers may engage in a structured Proof of - Concept. This is a [sales-led process](/handbook/sales/meetings/poc/) + Concept. This is a [sales-led process](/handbook/sales/meetings/pov/) designed to validate specific use cases. Marketing supports this motion by providing relevant content and materials like customer stories and technical documentation. diff --git a/nuxt/content/handbook/sales/demo-apps.md b/nuxt/content/handbook/sales/demo-apps.md new file mode 100644 index 0000000000..f7d8e88b67 --- /dev/null +++ b/nuxt/content/handbook/sales/demo-apps.md @@ -0,0 +1,43 @@ +--- +title: "Demo Apps" +navigation: + order: 13.7 + icon: i-lucide-layout-grid +--- + +## Demo Apps + +**Demo Apps** is our collection of public demo apps — a first-class asset alongside +the [PoV Workbook](/handbook/sales/pov-workbook/) and the +[FlowFuse Trial Environment](/handbook/sales/flowfuse-trial-environment/). Each use +case is its **own FlowFuse team**, named **`Demo App - {Use-case name}`**. + +The **use case registry will live on the FlowFuse website** (not inside FlowFuse): +the website catalogs every use case so a prospect can find one relevant to them and +explore it from the front end. The [Demo](/handbook/sales/meetings/demo/) then +becomes a walk through the *backend* of a use case they have already seen. Because +each use case is its own team and its own app, the collection shows FlowFuse is +truly a platform for solving many use cases — not a single tool. + +::callout{icon="i-lucide-hammer"} +**Planned — not yet built.** The use case registry is a page to be built on +flowfuse.com (intended location: `/demo-apps/`). The intent: a registry menu that +flips through the use cases; for each one, a breakdown of the **problem** (the +overarching use case detail), the **app or apps** that solve it, and the +**outcome** — with a link to open that demo app's Dashboard 2.0 front end. +:: + +## Publishing criteria + +Every use case added to Demo Apps must meet these criteria: + +1. **Its own team, named `Demo App - {Use-case name}`.** Each use case is a dedicated FlowFuse team using that exact naming convention — not a shared team, a personal instance, or a one-off environment. +2. **A PoV doc for the use case.** Every contributed use case has a [PoV workbook](/handbook/sales/pov-workbook/) defined that showcases FlowFuse's value *over Node-RED* — what the platform adds beyond the flows themselves. Source docs for use cases live in [this shared folder](https://drive.google.com/drive/folders/12BjizVCMc5O6KeBN5Ce7j1yxdHiq0wzM){rel="nofollow"}. +3. **Built with the app delivery methods.** The app uses one or both of FlowFuse's [app delivery methods](/application-guide/flowfuse/app-delivery-methods/). +4. **Conforms to an app pattern.** The app follows one of the app patterns in the Application Guide — a [hardware app](/application-guide/flowfuse/hardware-apps/) or a [software app](/application-guide/flowfuse/software-apps/). +5. **Listed in the website use case registry.** The use case is registered in the FlowFuse website's use case registry so prospects can discover it and explore it from the front end. +6. **A built-in architecture page.** The app must include an architecture page that is the PoV doc visualized on the front end of the app — so a prospect exploring the front end sees the same architecture the PoV describes. + +Together these make each demo app self-describing: a prospect finds a use case in +the website registry, sees its architecture and value on the front end, and the +sales [Demo](/handbook/sales/meetings/demo/) picks up from there in the backend. diff --git a/nuxt/content/handbook/sales/engagements.md b/nuxt/content/handbook/sales/engagements.md index cc9e933a3b..6c6d0d4937 100644 --- a/nuxt/content/handbook/sales/engagements.md +++ b/nuxt/content/handbook/sales/engagements.md @@ -160,7 +160,7 @@ as evidenced by a PO or signed quote, is the sole determinant. - Invite customer as owner to the team - Remove own email adress after sign up customer - _Self-Managed_ - - Generate a [license key](../sales/meetings/poc.md#generating-a-license) + - Generate a [license key](../sales/meetings/pov.md#generating-a-license) - Send the license key with the onboarding email to the customer, following this [HubSpot Template](https://app-eu1.hubspot.com/templates/26586079/edit/135404737?q=welco&page=1). diff --git a/nuxt/content/handbook/sales/flowfuse-trial-environment.md b/nuxt/content/handbook/sales/flowfuse-trial-environment.md new file mode 100644 index 0000000000..6f8da36cfb --- /dev/null +++ b/nuxt/content/handbook/sales/flowfuse-trial-environment.md @@ -0,0 +1,46 @@ +--- +title: "FlowFuse Trial Environment" +navigation: + order: 13.6 + icon: i-lucide-server +--- + +## FlowFuse Trial Environment + +The **FlowFuse Trial Environment** is the environment a customer uses to evaluate FlowFuse +during a Proof of Value — a first-class asset of the engagement, alongside the +[PoV Workbook](/handbook/sales/pov-workbook/). It is set up in the +[Solution](/handbook/sales/meetings/solution/) stage (it is item 5 of the +[Pre-PoV checklist](/handbook/sales/meetings/pov/#pre-pov-checklist)) and is where +the [PoV](/handbook/sales/meetings/pov/) is run. + +**Where FlowFuse lives defines it.** The architecture decision of where FlowFuse +itself runs — in the cloud, or on the customer's own infrastructure — is the same +decision as which trial environment they get. See +[Architectures](/application-guide/flowfuse/architectures/) in the Application Guide. + +## Two forms + +### Cloud trial + +The prospect self-services at https://app.flowfuse.com/account/create for a 30-day +trial of FlowFuse Cloud. To test Enterprise features, apply a coupon code to their +Stripe account and elevate their Tier after they create the trial account. + +### Self-hosted + +The customer installs FlowFuse on their own server. A self-hosted install needs a +trial [license key](/handbook/sales/meetings/pov/#generating-a-license) to unlock +paid-for features, and every self-hosted PoV call should have an engineer present. + +The licensing tasks — issuing a key and extending a trial — are covered on the +[PoV page](/handbook/sales/meetings/pov/#licensing). + +## When trial licenses are used + +Trial licenses are not a general giveaway — they exist to support the sales +process and help a customer understand the value of the platform. + +- **Open source** — any customer can use the open-source version of FlowFuse for whatever they want, no license required. +- **Cloud trial** — the FlowFuse Cloud trial area is free for 30 days by default, self-service, with no license needed. +- **Trial (Enterprise) licenses** — self-hosted trial license keys are handed out **only within a defined PoV process**. Their purpose is to let the customer evaluate the Enterprise platform during a scoped Proof of Value, not to provide free Enterprise use outside one. diff --git a/nuxt/content/handbook/sales/index.md b/nuxt/content/handbook/sales/index.md index 3b12a3a270..ba26137918 100644 --- a/nuxt/content/handbook/sales/index.md +++ b/nuxt/content/handbook/sales/index.md @@ -76,7 +76,10 @@ rules. - [Systems & Tools](./tools.md) — the commercial tech stack - [Onboarding & Development](./onboarding.md) — ramping and growing the team - [Processes](./processes/) — the process and methodology index -- [Sales Meetings](./meetings/) — [Discovery](./meetings/discovery.md), [Demo](./meetings/demo.md), [PoC](./meetings/poc.md) +- [Sales Meetings](./meetings/) — [Discovery](./meetings/discovery.md), [Demo](./meetings/demo.md), [Solution](./meetings/solution.md), [PoV](./meetings/pov.md) +- [PoV Workbook](./pov-workbook.md) — the deal document that spans the SE stages, and its shared definitions +- [FlowFuse Trial Environment](./flowfuse-trial-environment.md) — the running FlowFuse the customer tests in, and the trial-license policy +- [Demo Apps](./demo-apps.md) — the public FlowFuse team where our demo apps live, and the criteria for publishing to it - [Engagements & Pricing](./engagements.md) - [Forecast Review](./forecast-review.md) - [Sales Deck](./sales-deck.md) and [Pricing Decks](./pricing-decks.md) diff --git a/nuxt/content/handbook/sales/meetings/demo.md b/nuxt/content/handbook/sales/meetings/demo.md index 59f1824f63..2501b50231 100644 --- a/nuxt/content/handbook/sales/meetings/demo.md +++ b/nuxt/content/handbook/sales/meetings/demo.md @@ -1,17 +1,34 @@ --- title: "Demo" +navigation: + order: 2 --- # Demo This document explains the process of delivering a sales demo of the features of FlowFuse. It is not intended to cover all features but to give potential customers a good understanding of FlowFuse's value. The demo outlined below is tailored for customers who are already familiar with Node-RED. A separate demo flow for Node-RED-unaware audiences is currently in development. +## What the Demo establishes + +The Demo is where the customer first meets the **[FlowFuse Application Guide](/application-guide/flowfuse/overview/)**. Its job is to establish two things: + +- **Fundamentals** — what FlowFuse is and its core pieces. → [Foundations](/application-guide/flowfuse/foundations/) +- **App delivery methods** — shipping the whole app by pipeline, or publishing reusable components to the Team Library. → [App delivery methods](/application-guide/flowfuse/app-delivery-methods/) + +The use case shown in the demo is a **hook**, not the point — ideally something close or relatable to the customer's own problem from [Discovery](/handbook/sales/meetings/discovery/) — used to make the delivery methods concrete. Coming out of the Demo, the customer should understand the **fundamentals** and the **delivery methods**: enough to move into the [Solution](/handbook/sales/meetings/solution/) stage, where the rest of the guide is tailored to their environment. + ## Setup - Before the Demo We have a team prepared on FlowFuse Cloud called [Acme Manufacturing Corp](https://app.flowfuse.com/team/acme-man-corp/overview) which includes everything you will need to complete this demo. ## Script for FlowFuse Demo +> **Note:** This script is the current process and will be replaced soon, once the +> new demo infrastructure — the [Demo Apps](/handbook/sales/demo-apps/) team — is +> fully established. The emerging model is that a prospect first explores a use case +> on the front end of a demo app, and the demo becomes a walk through its backend. + + 1. **Introduction to FlowFuse** * Explain that FlowFuse is a platform that allows users to host and manage instances of Node-RED, a popular open-source flow-based programming tool. * Mention that FlowFuse can be deployed in the cloud (e.g., AWS), on-premises, or in air-gapped networks, and the workflows demonstrated will work the same way regardless of the deployment model. diff --git a/nuxt/content/handbook/sales/meetings/discovery.md b/nuxt/content/handbook/sales/meetings/discovery.md index 3dfc1fba38..f8857b00d5 100644 --- a/nuxt/content/handbook/sales/meetings/discovery.md +++ b/nuxt/content/handbook/sales/meetings/discovery.md @@ -1,11 +1,34 @@ --- title: "Discovery Meeting" +navigation: + order: 1 --- -The goal of the discovery call is to get to know the prospective client and the -problem that FlowFuse may be able to help them. +## Discovery + +The Discovery call is **stage 1** of the sales process — the first meeting the SE +and AE run together. Its goal is to get to know the prospective client and the +problem FlowFuse may be able to help them solve, and to turn that problem into a +**use case**. FlowFuse will use the "Discovery Call Playbook" in HubSpot, [Learn how to use playbooks](https://knowledge.hubspot.com/playbooks/use-playbooks#use-playbooks-in-contact-company-deal-ticket-or-custom-crm-records). +Discovery follows the [SPICED](https://docs.google.com/spreadsheets/d/1WKz_ll6bLxkkRlZ4K94Va1laGksHXleo8Pnv0aB08lU) framework — Situation, Pain, Impact, Critical Event, Decision — to surface not just the pain but what it is worth and how the customer will decide. + +## What Discovery produces + +Discovery owns the first portion of the [PoV Workbook](/handbook/sales/pov-workbook/): +the **use case** — the customer's pain, tied to its business impact. It may surface +candidate apps, but they don't take form yet; that happens once the customer +understands FlowFuse's fundamentals in the [Demo](/handbook/sales/meetings/demo/) +and the solution is shaped in [Solution](/handbook/sales/meetings/solution/). + +Discovery is also where you begin to place the customer in a **zone** — Node-RED +maturity against operational maturity — which shapes how the rest of the engagement +runs (see the [Customer Adoption Maturity Model](https://docs.google.com/document/d/1AICvYVRnVcAnY9rpcjjJMyOVqJRQQ3OFyMLD5aHP4Yo/edit)). There are dedicated Z2 and Z4 discovery playbooks for this. + +## Next step -The next step depends on the outcome of the call, but usually results in a more technical discussion, product demonstration, or sending relevant content to follow-up on at an appropriate time in the future. +The next step depends on the outcome of the call, but usually results in a more +technical discussion, a product [Demo](/handbook/sales/meetings/demo/), or sending +relevant content to follow up on at an appropriate time in the future. diff --git a/nuxt/content/handbook/sales/meetings/index.md b/nuxt/content/handbook/sales/meetings/index.md index 05a8ca0498..ca92de2548 100644 --- a/nuxt/content/handbook/sales/meetings/index.md +++ b/nuxt/content/handbook/sales/meetings/index.md @@ -26,10 +26,13 @@ The number of times FlowFuse will meet with a customer depends mostly on the customer. However, in all cases FlowFuse would like to have an initial [Discovery Call](/handbook/sales/meetings/discovery/). -A discovery call is generally followed by a [Demo](/handbook/sales/meetings/demo/). +A discovery call is generally followed by a [Demo](/handbook/sales/meetings/demo/). + +The Solutions Engineer then shapes the [Solution](/handbook/sales/meetings/solution/): +the specific apps, success criteria and plan that will be proven. To validate the solution to the problem the customer is experiencing, FlowFuse will -aid in a [POC](/handbook/sales/meetings/poc/). +aid in a [PoV](/handbook/sales/meetings/pov/). ## Using Fathom Notetaker diff --git a/nuxt/content/handbook/sales/meetings/poc.md b/nuxt/content/handbook/sales/meetings/poc.md deleted file mode 100644 index 2d7c7f2233..0000000000 --- a/nuxt/content/handbook/sales/meetings/poc.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Proof of Concept" ---- - -## Proof of Concept - -### Cloud trial - -If the prospect would like to trial FlowFuse Cloud, they are able to self-service at https://app.flowfuse.com/account/create. This will give them a 30-day trial of FlowFuse Cloud. If they would like to test with Enterprise features, you can apply a coupon code to their Stripe account and elevate their Tier, after they create their trial account. - -#### Extending a trial - -To extend the trial period, including if a trial has expired already, use the 'Extend Trial' button on the Team Settings page. This is only available to platform Administrators. If you do not have admin access, raise a [CloudProject change request](/handbook/operations/change/#flowfuse-cloud-change-control) with details. - -### Self-hosted trial - -If a self-hosted trial is desired, you need to [generate a license key](/handbook/sales/meetings/poc/#generating-a-license) to unlock paid-for features. -Every self-hosted POC call should have an engineer present. - -### POC Criteria - -During the initial POC meeting, the [POC Criteria document](https://docs.google.com/document/d/1Dr5S9b9dm7Zn84rx-xV9_AvpEwjUPxSk8ZfQDBgpBgQ/edit) should be completed by both FlowFuse and the prospective customer. This ensures both parties are clear about what needs to be technically validated and what the next steps are after the testing is complete. - -### Generating a license - -- Generate one by [filling out this form](https://energetic-sanderling-4472.flowfuse.cloud/dashboard/license){rel="nofollow"}. -- Trial license expiry date should be set for 30 days, even in cases where longer than 30 days may be warranted. -- Include 10 users, 10 teams, and 10 Node-RED instances on the Enterprise Tier. -- Trial extensions need to be approved by management. - -All generated licenses are added [to this sheet](https://docs.google.com/spreadsheets/d/1wM_o8IWjjkwi-WMRueKfS-lrmkQYzV83xm4BIzZNAO0){rel="nofollow"} automatically. diff --git a/nuxt/content/handbook/sales/meetings/pov.md b/nuxt/content/handbook/sales/meetings/pov.md new file mode 100644 index 0000000000..a6ff44c53a --- /dev/null +++ b/nuxt/content/handbook/sales/meetings/pov.md @@ -0,0 +1,92 @@ +--- +title: "Proof of Value" +navigation: + order: 4 +--- + +## Proof of Value + +A Proof of Value (PoV) is the stage where FlowFuse and the prospective customer +jointly prove that FlowFuse solves the specific problem uncovered during +[Discovery](/handbook/sales/meetings/discovery/) and shown in the +[Demo](/handbook/sales/meetings/demo/). Unlike a generic "kick the tyres" trial, +a PoV is scoped in the [Solution](/handbook/sales/meetings/solution/) stage — the +apps that will solve the use case, the success criteria they are judged against, +and the plan are all agreed before it starts — and it ends in a clear decision. + +## Where a PoV fits in the sales process + +A PoV is **[stage 4 — Validate](https://docs.google.com/spreadsheets/d/1WKz_ll6bLxkkRlZ4K94Va1laGksHXleo8Pnv0aB08lU/)** of the sales process: the technical heart of the +Evaluation phase, jointly owned by the **AE and SE**. It is where a deal moves +from *best case* into *forecast* — the customer has agreed the problem is worth +solving, and the PoV proves FlowFuse is the solution. A **completed installation** +and **technical validation** against the agreed criteria are the exit signals that +carry the deal out of Validate toward Commit. + +It runs in three arcs — the same three that shape the [Process](#process) below +and the workbook's **Plan** tab: + +| Arc | Sales stage | What happens | +|------|-------------|--------------| +| **Pre-PoV** | [Solution](/handbook/sales/meetings/solution/) (stage 3) | The gates are produced — use case and value understood, apps and success criteria defined, plan agreed, FlowFuse available (see the [Pre-PoV checklist](#pre-pov-checklist)). A PoV should not start until they are. | +| **PoV** | Validate (stage 4) | Prove each scoping criterion. Completed installation and technical validation are the exit criteria. | +| **Post-PoV** | Moving to Commit (stage 5) and Closing | A successful PoV feeds the business case, Economic Buyer alignment and paper process that carry the deal to close. | + +A PoV is run from the **[PoV Workbook](/handbook/sales/pov-workbook/)** — the single +document that spans the whole engagement — using the shared +[definitions](/handbook/sales/pov-workbook/#definitions) defined there. This page +covers the PoV stage itself: [where it fits](#where-a-pov-fits-in-the-sales-process) +in the sales process, and the [process](#process) of running one. + +## Process + +A PoV moves through a small number of phases, all tracked in the workbook's +**Plan** tab: **pre-PoV gates** clear, then **kickoff** (agree the plan and +success criteria, and schedule every check-in and the wrap-up), **install**, +**execute** (prove each scoping criterion in turn), and **wrap-up** (sign-off +against the criteria). The commercial follow-on lives in the **Post-PoV** section +of the same plan. + +### Pre-PoV checklist + +Before a PoV starts, five things must be true. The first four are the output of +the [Solution](/handbook/sales/meetings/solution/) stage (stage 3) — they are +produced there, not during the PoV — and the fifth is getting access. They are +also the gates tracked in the workbook's **Plan** tab. Starting a PoV before they +are met is the most common way one stalls. + +1. **The use case and its business impact are understood.** [Discovery](/handbook/sales/meetings/discovery/) has established the pain and what solving it is worth to the customer. +2. **The apps are defined.** The app or apps that will solve the use case are identified and follow FlowFuse's app delivery methods, so the PoV showcases FlowFuse as an app-building platform — not a test of Node-RED. +3. **Success criteria are well defined.** Each criterion has a concrete, agreed pass signal, so "success" is not open to interpretation when the PoV ends. +4. **The plan is agreed with the customer.** Tasks, owners and dates are agreed jointly, not just internally. +5. **FlowFuse is available to test.** The customer has either installed FlowFuse (self-hosted) or signed up for a Cloud trial — set up as the [FlowFuse Trial Environment](/handbook/sales/flowfuse-trial-environment/) during the Solution stage. + +### PoV meetings + +Every PoV meeting is scheduled up front, at the kickoff, so the cadence is agreed +and the wrap-up is already on the calendar before any testing begins. + +- **Kickoff** — the customer formally agrees to the PoV, the plan and success criteria are confirmed, and every subsequent meeting (the check-ins and the wrap-up) is scheduled. For a self-hosted PoV, this is where the customer receives the [trial license key](#generating-a-license) to install on their own server. +- **Check-ins** — a regular cadence agreed at kickoff. Each check-in reviews progress against the scoping criteria and clears blockers; open items are tracked in the workbook's **Questions** tab between calls. +- **Wrap-up / feedback meeting** — a final session, also booked at kickoff, to review the PoV against its success criteria, capture the customer's feedback, and agree the next step toward Commit. + +### Licensing + +Getting the customer a running FlowFuse — the +[FlowFuse Trial Environment](/handbook/sales/flowfuse-trial-environment/), a Cloud +trial or a self-hosted install — is set up in the Solution stage. The licensing +tasks the SE performs during the PoV live here. A **license key applies only to +self-hosting**; a Cloud trial never needs one. + +#### Generating a license + +- Generate one by [filling out this form](https://energetic-sanderling-4472.flowfuse.cloud/dashboard/license){rel="nofollow"}. +- Trial license expiry date should be set for 30 days, even in cases where longer than 30 days may be warranted. +- Include 10 users, 10 teams, and 10 Node-RED instances on the Enterprise Tier. + +All generated licenses are added [to this sheet](https://docs.google.com/spreadsheets/d/1wM_o8IWjjkwi-WMRueKfS-lrmkQYzV83xm4BIzZNAO0){rel="nofollow"} automatically. + +#### Extending a trial + +- **Cloud** — use the 'Extend Trial' button on the Team Settings page (platform Administrators only). Without admin access, raise a [CloudProject change request](/handbook/operations/change/#flowfuse-cloud-change-control) with details. +- **Self-hosted** — issue a new license key with a later expiry. Trial extensions need to be approved by management. diff --git a/nuxt/content/handbook/sales/meetings/solution.md b/nuxt/content/handbook/sales/meetings/solution.md new file mode 100644 index 0000000000..e6ef7bc52e --- /dev/null +++ b/nuxt/content/handbook/sales/meetings/solution.md @@ -0,0 +1,72 @@ +--- +title: "Solution" +navigation: + order: 3 +--- + +## Solution + +The Solution stage is **stage 3** of the sales process and the point where the +Solutions Engineer turns a understood problem into a concrete, testable plan. +[Discovery](/handbook/sales/meetings/discovery/) established the pain and the +[Demo](/handbook/sales/meetings/demo/) proved FlowFuse is credible against it; +Solution is where we decide *exactly* what we will build, how we will prove it, +and how we will run the [Proof of Value](/handbook/sales/meetings/pov/). + +Everything the PoV depends on is produced here. The +[Pre-PoV checklist](/handbook/sales/meetings/pov/#pre-pov-checklist) is really the +**exit criteria of the Solution stage** — a PoV only starts once this stage has +done its job. + +## Zone shapes how much Solution work is needed + +The first job is to identify the customer's **zone** — where they sit on Node-RED +maturity against operational maturity. The zone decides how much shaping the +solution needs. See the +[Customer Adoption Maturity Model](https://docs.google.com/document/d/1AICvYVRnVcAnY9rpcjjJMyOVqJRQQ3OFyMLD5aHP4Yo/edit) +for the full model. + +- **Z4 — NR Scale, Ops-Immature** is the one zone that can start from the **pre-canned PoV workbook** (the Node-RED-scale template). The customer already runs a Node-RED estate doing real work, so the use case is essentially operating it safely at scale, and the PoV proves *both* app delivery methods against their existing flows. The Solution phase here is light — mostly confirming scope. +- **Every other zone needs a solid Solution phase.** There is no ready-made use case: you have to define the specific operational problem and the apps that matter to the customer before a PoV can start. Z2 (strong on outcomes, new to Node-RED) especially depends on anchoring a credible, solution-led use case rather than a generic scaling story. + +## Designing the solution with the Application Guide + +The [Demo](/handbook/sales/meetings/demo/) already introduced the +**[FlowFuse Application Guide](/application-guide/flowfuse/overview/)** and +established the [fundamentals](/application-guide/flowfuse/foundations/) and the +[app delivery methods](/application-guide/flowfuse/app-delivery-methods/). Solution +is where FlowFuse stops being a demo and becomes an **application platform**: the +SE and customer take those fundamentals and **tailor them to the customer's +environment**, working through the rest of the guide. + +Work through, in roughly this order — each decision narrows what the PoV will prove: + +1. **App pattern** — decide the shape each app takes: a [hardware app](/application-guide/flowfuse/hardware-apps/) running on a device, or a [software app](/application-guide/flowfuse/software-apps/) running on the platform (three shapes each). Naming the pattern is what makes the PoV a test of *applications*, not of Node-RED. +2. **Data plane** — before deciding where things run, decide how data is handled in their environment. → [Data plane](/application-guide/flowfuse/data-plane/) +3. **Architecture** — the defining decision is **where FlowFuse itself lives**: in the cloud, self-hosted on-prem, or air-gapped; serving the wider organisation from [IT](/application-guide/flowfuse/it-architectures/), sitting in [OT](/application-guide/flowfuse/ot-architectures/) near the equipment, or distributed across [IIoT](/application-guide/flowfuse/iiot-architectures/) edge nodes ([overview](/application-guide/flowfuse/architectures/)). Where FlowFuse lives sets the rest of the architecture — and is the same decision as which [FlowFuse Trial Environment](/handbook/sales/flowfuse-trial-environment/) the customer gets. This becomes the architecture stack on the PoV workbook's **Use Cases** tab. + +Which delivery method(s) the PoV proves is settled here too, against the use case — +Z4 deals prove both; everyone else picks what fits. The output of this design work +— the app pattern, the delivery method(s) and the architecture, tailored to their +environment — is exactly what the PoV sets out to prove, and what makes the case +that FlowFuse is an app platform rather than a way to run Node-RED. + +## What the SE produces in Solution + +1. **A confirmed use case and its business impact.** The pain from Discovery is written up as a use case, with the value of solving it quantified or bounded so the deal can be forecast. +2. **The apps that will solve it.** The app or apps are scoped against FlowFuse's [app delivery methods](/application-guide/flowfuse/app-delivery-methods/) and app patterns (above), so the PoV showcases FlowFuse as an app-building platform — not a test of Node-RED. One use case may take one app or several. +3. **Well-defined success criteria.** Each thing the PoV must prove is written as a concrete pass signal both sides agree on, so "success" is settled before testing starts. +4. **An agreed plan.** The tasks, owners and dates are agreed *with the customer*. +5. **A ready environment.** The customer is set up to test in a [FlowFuse Trial Environment](/handbook/sales/flowfuse-trial-environment/) — a Cloud trial or a self-hosted install. Its form follows the architecture decision above: where FlowFuse lives. + +These five outputs are the same five gates as the +[Pre-PoV checklist](/handbook/sales/meetings/pov/#pre-pov-checklist): Solution's job +is to produce all of them. + +## Handoff into the PoV + +When those five are in place the deal is ready to move from Solution (stage 3) +into **Validate** (stage 4) — the [Proof of Value](/handbook/sales/meetings/pov/). +The output of this stage becomes the opening tabs of the PoV workbook — the use +case, the apps, the scoping criteria and the plan — running in the +[FlowFuse Trial Environment](/handbook/sales/flowfuse-trial-environment/). diff --git a/nuxt/content/handbook/sales/pov-workbook.md b/nuxt/content/handbook/sales/pov-workbook.md new file mode 100644 index 0000000000..9b1160d926 --- /dev/null +++ b/nuxt/content/handbook/sales/pov-workbook.md @@ -0,0 +1,63 @@ +--- +title: "PoV Workbook" +navigation: + order: 13.5 + icon: i-lucide-clipboard-list +--- + +## PoV Workbook + +The **PoV workbook** is the single document that runs a Proof of Value — the +"FlowFuse PoV Collaboration" Google Sheet. **Start from the +[FlowFuse — POV Template](https://docs.google.com/spreadsheets/d/1QAglAay1ikyBdWJRGSEiQfHCsFDz9TCt4lyJ4x0Ds38/edit){rel="nofollow"}** — +copy it per engagement, don't edit the template. Completed workbooks and the +source docs for the use cases we build live in +[this shared folder](https://drive.google.com/drive/folders/12BjizVCMc5O6KeBN5Ce7j1yxdHiq0wzM){rel="nofollow"}. +It is the through-line across the whole +engagement: every [sales meeting](/handbook/sales/meetings/) stage either *produces* +or *executes* a portion of it. Because it spans all the stages, it — and the shared +vocabulary below — live here rather than inside any one stage. + +It is filled out *with* the customer, not for them — the conversation is the point. +Complete it live on the calls, tie every criterion back to a Discovery pain, and +agree the next step before testing starts. + +## How the stages fill the workbook + +Each SE stage owns a portion of the workbook: + +| Stage | Portion of the workbook | +|-------|-------------------------| +| **[Discovery](/handbook/sales/meetings/discovery/)** | The **use case** — the pain. May surface candidate apps, but they don't take form yet. | +| **[Demo](/handbook/sales/meetings/demo/)** | No workbook portion directly — introduces the [Application Guide](/application-guide/flowfuse/overview/), establishing the **fundamentals** and **app delivery methods** via a relatable use-case hook, so the apps *can* take form in Solution. | +| **[Solution](/handbook/sales/meetings/solution/)** | Tailors the guide to the customer's environment (**app pattern, data plane, architecture**), then fills the **apps**, **scoping criteria / pass signals** and **plan** — the bulk of it. | +| **[PoV / Validate](/handbook/sales/meetings/pov/)** | **Executes** the workbook: proves each criterion, runs the plan, works the Questions. | + +## Definitions + +| Term | Meaning | +|------|---------| +| **Proof of Value (PoV)** | A time-boxed, criteria-driven engagement to prove FlowFuse delivers the value the customer needs. Formerly a "PoC" (Proof of Concept) — we say PoV to keep the focus on business value, not just technical feasibility. | +| **Use case** | A defined customer *pain*. A customer may have many use cases, but a PoV usually covers **one** — proving we can solve it is what the PoV is for. | +| **App** | The *solution* delivered on FlowFuse. A single use case may take one app or several to solve — the pain defines the use case, the apps are how we address it. | +| **Scoping criteria** | The specific things the PoV sets out to prove for the use case. Each one ties back to a pain raised in Discovery. | +| **Pass signal** | The concrete, observable outcome that shows a criterion is met (e.g. "a change made centrally reaches every target instance through a pipeline, with no one logging into an edge node"). Not a feature — a demonstrated result. | +| **Pre-PoV gate** | Something that must be true before the PoV can start (licenses issued, plan agreed, environment ready). Gates are tracked as a checklist and block kickoff until cleared. | +| **Delivery method** | How an app reaches the edge. The two we prove are **Whole App Pipeline** (promote dev → staging → production) and **Edge App + Components** (publish reusable components to the Team Library and consume them by reference). | +| **Sponsor / champion** | The customer owner of the PoV outcome, who takes the business case to the budget holders after a successful exit. | +| **Cloud trial** | A 30-day self-service trial of FlowFuse Cloud. | +| **Self-hosted trial** | A trial run on the customer's own infrastructure, unlocked with a trial license key. | + +## The tabs + +The workbook is deliberately split into tabs, each handled its own way. The value +is in *why* each tab exists: + +| Tab | What it's for | Why it matters | +|-----|---------------|----------------| +| **Overview** | The team (FlowFuse and customer roles), the commercial picture, and the key links — one place for who's involved and what the deal looks like. | Names the sponsor and the budget holders up front, so a successful PoV has a clear path to a decision instead of stalling. | +| **Use Cases** | The use case (usually one per PoV), its goal and architecture stack, and the **scoping criteria** — each pain paired with the pass signal that proves it's solved. | This is the contract of the PoV. It defines the pain and what "success" means so there is no ambiguity when the PoV ends, and it keeps testing anchored to real pains, not a feature tour. | +| **App** (one or more tabs) | Defines one app — its **delivery method**, **app pattern**, where it runs, its component architecture, and its own success criteria. A PoV may have several — one per app or delivery method being proven. | Turns the use case into concrete, working apps the customer can see and run — the proof that FlowFuse builds and ships real applications, not just manages Node-RED. | +| **Plan** | The pre-PoV gates, the scheduled tasks by phase, and the post-PoV commercial steps. | Turns "let's try it" into a dated plan with owners. Gates stop a PoV starting before it can succeed; the post-PoV section keeps the commercial motion moving the moment testing passes. | +| **Timeline** | A visual (Gantt-style) view of the Plan. | Gives the sponsor something concrete to take to stakeholders and set expectations against. | +| **Questions** | An async channel for open technical, functional and commercial questions, each with an owner, date and status. | Keeps blockers out of scattered email threads and visible to both sides, so nothing quietly stalls the PoV. | diff --git a/nuxt/content/handbook/sales/solution-engineering.md b/nuxt/content/handbook/sales/solution-engineering.md index 98421f035a..4d1cbba881 100644 --- a/nuxt/content/handbook/sales/solution-engineering.md +++ b/nuxt/content/handbook/sales/solution-engineering.md @@ -87,7 +87,7 @@ Solution Engineering performance is measured by: This page defines **what Solution Engineers own**. Detailed guidance on *how* SEs execute lives in the process and meeting pages: -- [Sales Meetings](/handbook/sales/meetings/) — [Discovery](/handbook/sales/meetings/discovery/), [Demo](/handbook/sales/meetings/demo/), [PoC](/handbook/sales/meetings/poc/) +- [Sales Meetings](/handbook/sales/meetings/) — [Discovery](/handbook/sales/meetings/discovery/), [Demo](/handbook/sales/meetings/demo/), [Solution](/handbook/sales/meetings/solution/), [PoV](/handbook/sales/meetings/pov/) - [Processes](/handbook/sales/processes/) — the process and methodology index This separation keeps ownership clear and execution flexible. diff --git a/nuxt/redirects.ts b/nuxt/redirects.ts index ce06a7be8a..715dd5e13f 100644 --- a/nuxt/redirects.ts +++ b/nuxt/redirects.ts @@ -101,6 +101,7 @@ export const redirects: Record = { '/handbook/marketing/education/': { redirect: { to: '/handbook/marketing/', statusCode: 301 } }, '/handbook/sales/org/account-executives/': { redirect: { to: '/handbook/sales/sales-team/', statusCode: 301 } }, '/handbook/sales/org/': { redirect: { to: '/handbook/sales/', statusCode: 301 } }, + '/handbook/sales/meetings/poc/': { redirect: { to: '/handbook/sales/meetings/pov/', statusCode: 301 } }, '/blog/2025/04/building-oee-dashboard-with-flowfuse-part-1/': { redirect: { to: '/blog/2025/04/what-is-an-oee-dashboard/', statusCode: 301 } }, '/blog/2025/04/building-oee-dashboard-with-flowfuse-2/': { redirect: { to: '/blog/2025/04/build-manufacturing-oee-dashboard/', statusCode: 301 } }, '/blog/2025/04/building-oee-dashboard-with-flowfuse-part-3/': { redirect: { to: '/blog/2025/04/design-and-scale-oee-dashboard/', statusCode: 301 } },