Alignment review · journey-map parent orchestrator · service-blueprint framework
FormForge Service Blueprint Findings Review
This page renders the Stage 2 service-blueprint working packet for review. Approval will let the parent `$journey-map` orchestrator write `research/journey-map-service-blueprint.md`; it will not finalize the unified journey map yet.
Approval Context
Consumed YAML: The framework-selection gate was approved with no unanswered required questions. Selected frameworks are `service-blueprint` and `user-story-map`.
State transition: The parent wrote the run manifest and entered State C. This page is the findings review for the first pending framework, `service-blueprint`.
| Framework | Intermediate path | Status |
|---|---|---|
| service-blueprint | research/journey-map-service-blueprint.md | Pending approval from this page |
| user-story-map | research/journey-map-user-story-map.md | Pending future framework run |
Scope And Inputs
This packet maps the FormForge client-intake service in flat `research/` mode for the approved ICP: client-service solo consultants, coaches, and small agencies doing client intake/onboarding.
Research Sources
research/icp.mdresearch/competitive-analysis.mdREADME.mdandCLAUDE.md
Code Sources
src/server/ai/generate-form.tssrc/server/db/schema.tssrc/server/trpc/routers/form.tssrc/server/trpc/routers/response.tssrc/app/api/submit/[slug]/route.tssrc/app/f/[slug]/client.tsxsrc/server/responses/csv-export.ts
Primary source gap: No `research/customer-feedback.md` exists. The blueprint can ground product mechanics in code and buyer needs in approved research, but it cannot claim live customer success.
Proposed Canonical Summary
FormForge's current service is strongest from "describe the needed intake form" through "publish a public link" and "receive structured submissions." The visible product loop already supports AI-generated fields, visual editing, conditional logic, immutable published snapshots, public submission, response review, basic response status, analytics, notification email, and CSV export.
The highest operational risk is after the respondent submits. ICP and competitive evidence both say the value of intake depends on reducing back-and-forth and moving answers into client work systems. The observed implementation currently provides response review, status labels, email notification, and CSV export, but no native Sheets/Notion/CRM/Zapier/Make/webhook/project-doc handoff. That makes post-submission routing the biggest service blueprint gap for the approved ICP.
Service Stages
| Stage | Customer Action | Evidence/Touchpoint | Backstage Action | Support Process |
|---|---|---|---|---|
| Trigger and evaluation | Consultant, coach, or agency realizes they need a client intake form for a new client, service, cohort, or project. | ICP trigger events; competitive gap framed as deeper than generic builders but lighter than suites. | Make the first-use promise legible: describe, generate, edit, publish, submit, review/export. | Positioning and onboarding content are not represented in code evidence; demand signal is research-backed, not customer-validated. |
| Sign-up and workspace entry | User creates or accesses an account and enters dashboard. | Auth and dashboard routes exist. | Protected procedures associate forms with authenticated user. | User context, database ownership, plan-limit checks. |
| AI-assisted draft creation | User describes the intake form they need. | README core loop; AI generation accepts natural-language prompt. | OpenAI call parses JSON into form schema; generated form and fields are persisted as draft. | OpenAI API, schema validation, database writes, slug generation, plan-limit enforcement. |
| Visual edit and form configuration | User adjusts fields, required flags, conditional logic, settings, theme, and publication readiness. | Editor, field palette, conditional-logic builder, settings, and theme routes/components exist. | Field records, settings, themes, and AI regeneration update draft form. | Drizzle schema stores fields, validation, conditional logic, settings, theme, and status. |
| Publish and share | User publishes and sends link to external client/respondent. | Publish requires at least one field and creates a version snapshot; public route renders by slug. | Immutable form version snapshots preserve what respondents saw. | `formVersions` stores title, settings, theme, and fields snapshot. |
| Respondent completion | External client completes the intake without being buyer. | Public client renders form, theme, Turnstile, completion timing, success redirect. | Submit API validates and stores response; sends notification when configured. | Rate limiter, Turnstile, conditional logic, localized validation, database inserts, email service. |
| Response review and triage | User reviews answers, marks status, exports, and decides next step. | Response list/detail/stats/analytics/status/delete/export exist. | Dashboard queries aggregate response and field values. | Database relations, analytics builder, CSV export with 10,000-row cap. |
| Handoff into service delivery | User copies or exports answers into project docs, CRM, Notion, Sheets, kickoff notes, or client workspace. | ICP rates copy/paste pain high; competitive analysis says handoff is battleground. | Current product can export CSV and send email, but no native external work-system handoff is observed. | CSV builder, notification email, and manual user process. |
| Retention and reuse | User duplicates, edits, regenerates, reuses, and monitors forms across clients/offers. | Duplicate, regenerate, close, statuses, analytics, themes, response review exist. | Forms can be cloned or regenerated; response history is tied to forms and versions. | Ownership, versioning, analytics, plan limits, theme validation. |
| Billing and expansion | User may hit limits or choose paid features after repeated use. | Stripe billing and plan fields exist; README says defer billing until core loop validation. | Checkout/webhook updates customer/subscription metadata and plan state. | Stripe integration, webhook handling, user plan records. |
| Support and failure recovery | User or respondent encounters validation, bot, limit, version, or submission errors. | Submit route returns localized error states; dashboard error route exists. | Errors are localized; internal submission errors are logged. | i18n utilities, validation, rate limit, Turnstile, server logging. No support workflow evidence. |
Lines Of Interaction
Line Of Interaction
Buyer/user interacts with dashboard for prompt generation, editing, publishing, settings, response review, and export. Respondent/client interacts with the public form for link open, field completion, validation, bot challenge, and success message or redirect.
Line Of Visibility
Buyer can see status, fields, settings, theme, public slug, responses, status labels, analytics, CSV export, and configured notification path. Respondent sees form, fields, help text, validation, Turnstile, and success state.
Weak Visibility
The product does not clearly show whether submitted answers are kickoff-ready, whether all assets are complete, whether exported answers reached the actual work system, or whether follow-up has happened.
Internal And Implementation Lines
Backstage processes depend on AI generation, database ownership, plan-limit enforcement, field persistence, version snapshots, public submission validation, email dispatch, analytics, and CSV export. The main internal handoff is from published form snapshot to response records; the missing internal handoff is from response records into external client-work systems.
Implementation infrastructure includes Next.js App Router, tRPC, PostgreSQL through Drizzle ORM, OpenAI, authenticated user context, Cloudflare Turnstile, email notification, and Stripe billing records. Deferred or absent infrastructure includes durable provider integrations, webhooks/API handoff, CRM/project-management routing, and customer-feedback/support lifecycle.
Operational Gap Analysis
| Gap Type | Stage | Description | Severity | Evidence |
|---|---|---|---|---|
| Evidence gap | Trigger and evaluation | The repo has strong desk research and product code but no direct customer-feedback file, interviews, win/loss notes, analytics, or support tickets. | High | Missing `research/customer-feedback.md`; ICP and competitive analysis both flag customer-validation gaps. |
| Fail point | AI-assisted draft creation | AI-generated forms may omit service-specific intake details, ask weak questions, or produce conditional logic that needs human correction. | Medium | `generate-form.ts` uses schema validation and conditional-logic hints, but there is no customer-quality evidence for generated intake forms. |
| Fail point | Publish and share | Publishing checks non-empty fields and snapshots, but not whether the intake is complete enough for kickoff. | Medium | ICP pain is missing details/assets, not only missing fields. |
| Wait point | Respondent completion | Turnstile, required fields, file-upload expectations, conditional logic, or validation can slow completion. | Medium | Public submit path validates Turnstile, visible fields, rules, limits, and close date; ICP says respondent friction matters. |
| Bottleneck | Response review and triage | The owner-operator still has to inspect new submissions and decide whether they are ready for kickoff. | High | Response statuses exist, but no automated completeness scoring, missing-asset workflow, or follow-up loop is observed. |
| Handoff gap | Handoff into service delivery | CSV export and notification email do not by themselves move answers into project docs, CRM, Notion, Sheets, kickoff notes, or task systems. | High | ICP rates manual copy/paste high; competitive analysis calls integrations and handoff a battleground; README defers integrations and webhooks. |
| Evidence gap | Handoff into service delivery | The service does not expose status that a submission has been transferred, assigned, reconciled, or used in kickoff. | High | Schema tracks response status only as new/read/starred/archived; no downstream sync state is visible. |
| Fail point | Notification and support | Notification email is fire-and-forget and a missed notification may not be surfaced to the user. | Medium | Submit route sends notification asynchronously and catches errors with `console.error`; no retry/support path observed. |
| Bottleneck | Billing and expansion | Premature billing emphasis could distract from journey validation. | Low-medium | README says defer Stripe billing until core loop validation. |
Evidence Matrix
| Claim | Evidence Source | Evidence Type | Inference | Confidence | Decision Impact |
|---|---|---|---|---|---|
| The active ICP needs client intake/onboarding, not generic form creation. | `research/icp.md` primary ICP and trigger events. | Approved research | Blueprint should center client-service intake stages. | High | Approve scope unless ICP has changed. |
| Current product loop covers describe, generate, edit, publish, submit, review, and export. | README; observed routes and routers. | Observed plus stated product boundary | Service can be mapped as a functioning product loop. | High | Approve product-exists framing. |
| AI generation creates structured form definitions. | `src/server/ai/generate-form.ts`. | Observed code | AI draft is a real backstage service step. | High | Preserve in canonical intermediate. |
| Published forms use immutable snapshots. | Form router, schema, submit route. | Observed code | Response interpretation is protected after edits. | High | Include as operational strength. |
| Public submission has reliability controls. | Submit route. | Observed code | Failure controls exist, though they can add completion friction. | High | Frame as both support process and possible wait point. |
| Response review exists but downstream workflow handoff is thin. | Response router, README deferred integrations, absent native CRM/Sheets/Notion/Zapier/Make routing. | Observed code plus product boundary | The service may still leave the buyer with manual post-submission work. | High | Approve as top operational gap if accurate. |
| Handoff is the most important service gap for the ICP. | ICP pain map; competitive analysis handoff battleground. | Approved research plus inference | Value depends on intake data reaching client work systems. | Medium-high | Should shape later user-story-map and synthesis. |
| Customer success and generated-form quality remain unvalidated. | Missing customer feedback and usage evidence. | Source absence | Blueprint findings should keep confidence limits visible. | High | Do not overclaim adoption or quality. |
Assumptions And Confidence
| Assumption | Status | Confidence | What Would Change It |
|---|---|---|---|
| Product-exists mode is appropriate. | Approved in YAML and supported by code evidence. | High | User changes mode or product boundary. |
| Highest-value journey is client intake for consultants, coaches, and small agencies. | Approved ICP. | High | New ICP approval or customer evidence contradicting Candidate A. |
| Post-submission handoff is more operationally important than billing for the first validated loop. | Inferred from ICP, competitive analysis, and README deferral note. | Medium-high | Interviews showing paid conversion fails before handoff matters, or usage showing exports are enough. |
| CSV/email notification is enough for initial validation but not durable differentiation. | Inferred from current product boundary and competitor integration breadth. | Medium | Buyers validate CSV/email as sufficient for repeated paid use. |
| AI-generated first drafts reduce blank-page work but need human review. | Supported by code and ICP pain, but not customer validated. | Medium | Usability tests show generated output is consistently ready-to-send, or often unusable. |
Source Coverage Gaps
- No real customer language beyond secondary/desk research.
- No observed onboarding analytics for first prompt, first publish, first response, or first export.
- No failed-submission telemetry, notification-delivery data, or support cases.
- No hands-on competitor trial comparing actual intake setup and handoff time.
- No proof that external clients complete FormForge forms at higher rates or with better completeness than Google Forms, Tally, Typeform, or manual questionnaires.
Proposed File Changes After Approval
- Write `research/journey-map-service-blueprint.md` with the proposed canonical artifact rendered in this page and the working packet.
- Archive `research/_working/preliminary-service-blueprint-research.md` after approval.
- Archive the review page snapshot after approval.
- Leave `research/_working/journey-map-run.yaml` as selection-only state; completion is inferred by the new canonical intermediate existing.
- Recalculate pending frameworks. The next pending framework should be `user-story-map`.
Compile Responses
Answer the required gates above, optionally add section feedback, then compile YAML for the next fresh `$journey-map` session.