SaaS POC and Pilot Scoping
Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.
Use When
- The buyer requires evidence before committing to a full SaaS implementation.
- The bid is competitive and a tight POC is a discriminator.
- The integration or regulatory risk is material and must be tested early.
- The buyer has had unsuccessful POC or pilot experiences and needs disciplined structure.
Do Not Use When
- The bid is a fixed-scope full implementation with no POC requirement.
- The proposal scope is too large for a POC to be meaningful (use phased implementation instead).
Required Inputs
| Artefact or fact |
Required? |
Source/provider |
If absent |
| The single risk hypothesis the POC must test (or the adoption hypothesis the pilot must validate). |
Required |
Buyer, ToR, approved records, or discovery |
Mark unavailable, request it, and qualify any affected claim or artefact. |
| The integration, data, and regulator context. |
Required |
Buyer, ToR, approved records, or discovery |
Mark unavailable, request it, and qualify any affected claim or artefact. |
| The named users or customers who will participate. |
Conditional |
Buyer, ToR, approved records, or discovery |
Mark unavailable, request it, and qualify any affected claim or artefact. |
| The decision the POC / pilot result must support. |
Conditional |
Buyer, ToR, approved records, or discovery |
Mark unavailable, request it, and qualify any affected claim or artefact. |
| The time-box and budget available. |
Conditional |
Buyer, ToR, approved records, or discovery |
Mark unavailable, request it, and qualify any affected claim or artefact. |
Workflow
- Decide the right artefact: Discovery POC (test a single risk), Technical POC (validate in buyer's environment), or Pilot (validate in production with a defined cohort).
- State the single hypothesis the artefact tests. POCs with three hypotheses prove none.
- Define written success criteria with binary pass/fail thresholds.
- Define written exit criteria: pass, partial-pass-with-mitigation, fail.
- Define the time-box. Discovery POC: 2–6 weeks. Technical POC: 4–8 weeks. Pilot: 8–16 weeks.
- Define the scope (in / out) explicitly. Production data, production users, custom development beyond configuration are typically out of scope for POC.
- Define the named cohort for a pilot — by branch, region, business unit, or customer segment.
- Define the team and effort on both sides.
- Define the commercial block: fixed fee, payment schedule, creditability against full implementation, and refundability rules.
- Produce the POC / Pilot block for the Methodology and Work Plan.
Stop condition: Stop before asserting scope, compliance, value, acceptance, or readiness when a load-bearing input is missing or contradicted.
Recovery: Record the gap, owner, and next evidence step; then return the narrowest qualified proposal content that remains supportable.
Quality Standards
- One artefact, one hypothesis.
- Success criteria are binary and measurable.
- Time-box is non-negotiable (extensions only with revised criteria).
- The agency does not offer a "free POC" — it destroys trade discipline.
- Pilot success criteria are co-authored with the buyer's named owner.
Anti-Patterns
- POC with no exit criteria (becomes an open sandbox). Fix: Define hypothesis, users, tenants, data, integrations, measures, thresholds, duration, exclusions, and a written exit decision.
- Pilot that quietly becomes the full rollout. Fix: Cap the pilot boundary and require a separate approved rollout plan, security review, budget, and cutover gate.
- POC run on a non-representative cohort. Fix: Select a cohort representative of target roles, data, load, integrations, risks, and operating conditions.
- "Free POC" — destroys the value defence. Fix: Charge or explicitly value the POC, tie it to buyer commitment, and credit fees only under stated conversion terms.
- POC budget that is invisible inside the implementation fee. Fix: Show POC labour, infrastructure, third-party, support, and contingency as a separate priced line or transparent allocation.
Outputs
| Artefact |
Consumer |
Observable acceptance condition |
| POC scoping block for Methodology. |
Proposal evaluator, buyer owner, and delivery team |
Content is complete, traceable to named inputs, and usable in its stated proposal section without an unsupported claim. |
| Pilot scoping block for Methodology. |
Proposal evaluator, buyer owner, and delivery team |
Content is complete, traceable to named inputs, and usable in its stated proposal section without an unsupported claim. |
| Success / exit criteria tables. |
Proposal evaluator, buyer owner, and delivery team |
Content is complete, traceable to named inputs, and usable in its stated proposal section without an unsupported claim. |
| Effort and commercial block for the POC / pilot. |
Proposal evaluator, buyer owner, and delivery team |
Content is complete, traceable to named inputs, and usable in its stated proposal section without an unsupported claim. |
Evidence Produced
| Evidence |
Consumer |
Acceptance condition |
| Input-and-assumption record |
Proposal lead and reviewer |
Every load-bearing claim maps to a source, approved assumption, or explicit gap. |
| Decision and review record |
Buyer owner and delivery lead |
The selected option, rationale, owner, stop condition, and approval status are visible. |
| Section acceptance check |
Evaluator-readiness reviewer |
Each output meets its stated acceptance condition and unresolved checks are not presented as passed. |
Capability and Permission Boundaries
This skill may read supplied tender, discovery, architecture, commercial, security, and operating evidence and draft proposal artefacts within the authorised workspace. It must not publish, send, certify compliance, accept contractual terms, change production systems, spend funds, or disclose confidential evidence without explicit authority. Review and analysis remain read-only by default.
Degraded Mode
If files, current legal or technical evidence, calculation tools, network access, or reviewers are unavailable, produce the narrowest useful qualified draft. Label assumptions and checks as not assessed, omit unsupported assurances or figures, and state the exact evidence and owner needed to complete the work. An unavailable check never becomes a pass.
Decision Rules
| Choice |
Action |
Failure or risk avoided |
| Success threshold |
Set the metric, dataset, owner, deadline, and production exit rule before work starts |
Open-ended pilot or subjective acceptance |
| Missing load-bearing evidence |
Stop the affected claim, record the gap and owner, and continue only with separable supported content. |
Fabricated assurance or hidden dependency |
| Conflicting buyer and supplier evidence |
Surface the conflict for decision; do not silently choose the favourable version. |
Misaligned scope, price, or acceptance |
| Irreversible, contractual, publishing, or production action |
Obtain explicit authority and preserve an approval record before acting. |
Unauthorised commitment or mutation |
Worked Example
For a claims-processing pilot, define the sample, baseline, error tolerance, user group, time box, exit evidence, and abort rule before pricing or promising rollout.
References
Adoption and experience proof
When the POC or pilot changes a user journey, include first-value and adoption
evidence alongside technical success: named cohort and role, baseline task
path, activation event, completion/abandonment definition, accessibility and
support guardrails, and the exit decision. Keep onboarding optional/contextual
where safe, and treat mandatory identity, consent, or security steps as
explicit scope with a reason and recovery path.
Practitioner cross-checks: Eleken mobile onboarding and SaaS launch. Do not copy their thresholds or case outcomes into a proposal without buyer-specific evidence.
1---2name: saas-poc-and-pilot-scoping3description: Use when a SaaS proposal needs a time-boxed POC or pilot with explicit scope, success measures, exit criteria, and a decision gate to implementation; use the AI-on-SaaS pilot skill when evaluation datasets or hallucination controls apply.4---56# SaaS POC and Pilot Scoping7Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.89<!-- dual-compat-start -->10## Use When1112- The buyer requires evidence before committing to a full SaaS implementation.13- The bid is competitive and a tight POC is a discriminator.14- The integration or regulatory risk is material and must be tested early.15- The buyer has had unsuccessful POC or pilot experiences and needs disciplined structure.1617## Do Not Use When1819- The bid is a fixed-scope full implementation with no POC requirement.20- The proposal scope is too large for a POC to be meaningful (use phased implementation instead).2122## Required Inputs2324| Artefact or fact | Required? | Source/provider | If absent |25|---|---|---|---|26| The single risk hypothesis the POC must test (or the adoption hypothesis the pilot must validate). | Required | Buyer, ToR, approved records, or discovery | Mark unavailable, request it, and qualify any affected claim or artefact. |27| The integration, data, and regulator context. | Required | Buyer, ToR, approved records, or discovery | Mark unavailable, request it, and qualify any affected claim or artefact. |28| The named users or customers who will participate. | Conditional | Buyer, ToR, approved records, or discovery | Mark unavailable, request it, and qualify any affected claim or artefact. |29| The decision the POC / pilot result must support. | Conditional | Buyer, ToR, approved records, or discovery | Mark unavailable, request it, and qualify any affected claim or artefact. |30| The time-box and budget available. | Conditional | Buyer, ToR, approved records, or discovery | Mark unavailable, request it, and qualify any affected claim or artefact. |3132## Workflow33341. Decide the right artefact: Discovery POC (test a single risk), Technical POC (validate in buyer's environment), or Pilot (validate in production with a defined cohort).352. State the single hypothesis the artefact tests. POCs with three hypotheses prove none.363. Define written success criteria with binary pass/fail thresholds.374. Define written exit criteria: pass, partial-pass-with-mitigation, fail.385. Define the time-box. Discovery POC: 2–6 weeks. Technical POC: 4–8 weeks. Pilot: 8–16 weeks.396. Define the scope (in / out) explicitly. Production data, production users, custom development beyond configuration are typically out of scope for POC.407. Define the named cohort for a pilot — by branch, region, business unit, or customer segment.418. Define the team and effort on both sides.429. Define the commercial block: fixed fee, payment schedule, creditability against full implementation, and refundability rules.4310. Produce the POC / Pilot block for the Methodology and Work Plan.444546**Stop condition:** Stop before asserting scope, compliance, value, acceptance, or readiness when a load-bearing input is missing or contradicted.4748**Recovery:** Record the gap, owner, and next evidence step; then return the narrowest qualified proposal content that remains supportable.4950## Quality Standards5152- One artefact, one hypothesis.53- Success criteria are binary and measurable.54- Time-box is non-negotiable (extensions only with revised criteria).55- The agency does not offer a "free POC" — it destroys trade discipline.56- Pilot success criteria are co-authored with the buyer's named owner.5758## Anti-Patterns5960- POC with no exit criteria (becomes an open sandbox). **Fix:** Define hypothesis, users, tenants, data, integrations, measures, thresholds, duration, exclusions, and a written exit decision.61- Pilot that quietly becomes the full rollout. **Fix:** Cap the pilot boundary and require a separate approved rollout plan, security review, budget, and cutover gate.62- POC run on a non-representative cohort. **Fix:** Select a cohort representative of target roles, data, load, integrations, risks, and operating conditions.63- "Free POC" — destroys the value defence. **Fix:** Charge or explicitly value the POC, tie it to buyer commitment, and credit fees only under stated conversion terms.64- POC budget that is invisible inside the implementation fee. **Fix:** Show POC labour, infrastructure, third-party, support, and contingency as a separate priced line or transparent allocation.6566## Outputs6768| Artefact | Consumer | Observable acceptance condition |69|---|---|---|70| POC scoping block for Methodology. | Proposal evaluator, buyer owner, and delivery team | Content is complete, traceable to named inputs, and usable in its stated proposal section without an unsupported claim. |71| Pilot scoping block for Methodology. | Proposal evaluator, buyer owner, and delivery team | Content is complete, traceable to named inputs, and usable in its stated proposal section without an unsupported claim. |72| Success / exit criteria tables. | Proposal evaluator, buyer owner, and delivery team | Content is complete, traceable to named inputs, and usable in its stated proposal section without an unsupported claim. |73| Effort and commercial block for the POC / pilot. | Proposal evaluator, buyer owner, and delivery team | Content is complete, traceable to named inputs, and usable in its stated proposal section without an unsupported claim. |7475## Evidence Produced7677| Evidence | Consumer | Acceptance condition |78|---|---|---|79| Input-and-assumption record | Proposal lead and reviewer | Every load-bearing claim maps to a source, approved assumption, or explicit gap. |80| Decision and review record | Buyer owner and delivery lead | The selected option, rationale, owner, stop condition, and approval status are visible. |81| Section acceptance check | Evaluator-readiness reviewer | Each output meets its stated acceptance condition and unresolved checks are not presented as passed. |8283## Capability and Permission Boundaries8485This skill may read supplied tender, discovery, architecture, commercial, security, and operating evidence and draft proposal artefacts within the authorised workspace. It must not publish, send, certify compliance, accept contractual terms, change production systems, spend funds, or disclose confidential evidence without explicit authority. Review and analysis remain read-only by default.8687## Degraded Mode8889If files, current legal or technical evidence, calculation tools, network access, or reviewers are unavailable, produce the narrowest useful qualified draft. Label assumptions and checks as **not assessed**, omit unsupported assurances or figures, and state the exact evidence and owner needed to complete the work. An unavailable check never becomes a pass.9091## Decision Rules9293| Choice | Action | Failure or risk avoided |94|---|---|---|95| Success threshold | Set the metric, dataset, owner, deadline, and production exit rule before work starts | Open-ended pilot or subjective acceptance |96| Missing load-bearing evidence | Stop the affected claim, record the gap and owner, and continue only with separable supported content. | Fabricated assurance or hidden dependency |97| Conflicting buyer and supplier evidence | Surface the conflict for decision; do not silently choose the favourable version. | Misaligned scope, price, or acceptance |98| Irreversible, contractual, publishing, or production action | Obtain explicit authority and preserve an approval record before acting. | Unauthorised commitment or mutation |99100## Worked Example101102For a claims-processing pilot, define the sample, baseline, error tolerance, user group, time box, exit evidence, and abort rule before pricing or promising rollout.103104## References105106- [Proposal skill router](../../SKILL.md) — routing, profile, reasoning, and final quality gates.107## Adoption and experience proof108109When the POC or pilot changes a user journey, include first-value and adoption110evidence alongside technical success: named cohort and role, baseline task111path, activation event, completion/abandonment definition, accessibility and112support guardrails, and the exit decision. Keep onboarding optional/contextual113where safe, and treat mandatory identity, consent, or security steps as114explicit scope with a reason and recovery path.115116Practitioner cross-checks: [Eleken mobile onboarding](https://www.eleken.co/blog-posts/mobile-app-onboarding-best-practices) and [SaaS launch](https://www.eleken.co/blog-posts/how-to-launch-a-saas-business). Do not copy their thresholds or case outcomes into a proposal without buyer-specific evidence.117118<!-- dual-compat-end -->119- [../references/saas-poc-scoping-template.md](../../profiles-sectors/references/saas-poc-scoping-template.md) — the template this skill operationalises.120- [../references/saas-demo-script-template.md](../../profiles-sectors/references/saas-demo-script-template.md) — the demo that precedes the POC.121- [../references/saas-mutual-action-plan-template.md](../../profiles-sectors/references/saas-mutual-action-plan-template.md) — placement of POC / pilot in the MAP.122- [../references/saas-business-case-and-roi-template.md](../../profiles-sectors/references/saas-business-case-and-roi-template.md) — the value case the pilot validates.123- [../saas-implementation-methodology/SKILL.md](../saas-implementation-methodology/SKILL.md) — full implementation methodology after pilot success.124- [../06-methodology/SKILL.md](../../pipeline/06-methodology/SKILL.md) — methodology section discipline.
peterbamuhigire