Lurnet Docs

Appearance

Lurnet - Product Specification ​

Detailed product spec covering personas, use cases, requirements, data model, and UX flows. Scope is the productized validation MVP after Phase 0 discovery, spanning Phase 1 Narrative Validation and Phase 2 Demand Capture. References concept.md for vision and planning.md for architecture; this document does not duplicate them.

1. Vision ​

Multi-product B2B SaaS companies usually market the flagship product well and under-market the rest of the catalog. Modules, integrations, vertical packages, and add-ons typically have weak landing pages, generic positioning, stale outbound copy, and unclear lead routing. The products are not always weak; the GTM system is not built to give each one a real motion.

Lurnet ingests the product catalog and gives every catalog entry its own GTM workspace. AI generates ICP, positioning, landing-page copy, and outbound assets per product. Humans approve customer-facing claims. Lurnet captures intent, routes leads with product context, and learns which narratives convert by product, segment, and channel.

The unit of work is the product catalog entry, not the campaign or the prospect.

The starting product is assisted, not autonomous. We earn the right to automate by first owning the workflow and the product-level memory layer.

2. Problem and Opportunity ​

2.1 Problem statement ​

In a B2B SaaS company with 20-200 marketable products, modules, integrations, packages, or vertical bundles, marketing capacity is finite. Most teams have one or two product marketers serving the entire catalog. Concrete failure modes:

  • A new integration ships but never gets a real landing page.
  • Vertical-package positioning is reused from a generic page; conversion underperforms.
  • Outbound emails reference the flagship product even when the prospect is researching a module.
  • Leads captured for niche products lack context and get routed to the flagship sales pod.
  • Performance reports do not break out by product; the long tail is invisible.

The combined effect: capable products generate less revenue than they could because they don't have their own GTM motion.

2.2 Opportunity ​

LLMs make it economical for the first time to generate per-product narratives, page copy, and outbound at the granularity B2B SaaS catalogs require. The remaining gap is workflow: ingestion, review, approval, capture, routing, and outcome measurement organized around the product catalog rather than the campaign.

Lurnet fills that gap. The bet is that catalog-level workflow with human approval is more valuable today than autonomous content generation, and that the per-product data we accumulate becomes a defensible asset over time.

3. Personas ​

Two layers: economic buyers and end users. The same person can play both roles at early-stage customers; in mid-market they separate.

3.1 Buyer personas ​

B1 - Head of Product Marketing (PMM lead)

  • Title examples: VP Product Marketing, Director of Product Marketing, Head of PMM.
  • Company shape: 50-500 employees, multi-product B2B SaaS, $5M-$100M ARR.
  • Reports to: CMO or COO.
  • KPIs: product launch performance, message effectiveness, sales enablement quality, pipeline contribution by product.
  • Why they buy Lurnet: their team cannot keep up with the catalog. Launches stall. Outdated positioning erodes win rates. They are accountable for product-level pipeline but lack capacity to influence it across every SKU.
  • Internal pitch they make: "We can give every product its own page, ICP, and outbound without hiring four more PMMs."
  • Risk they fear: AI output that misrepresents the product and creates brand or legal damage. Lurnet's approval gates address this directly.

B2 - Head of Demand Generation / Growth Marketing

  • Title examples: VP Demand Gen, Head of Growth, Director of Marketing Operations.
  • Company shape: same as B1, often a peer.
  • KPIs: pipeline volume, MQL→SQL conversion, cost per pipeline dollar.
  • Why they buy Lurnet: the long tail of products generates no inbound and no outbound; pipeline targets force them to over-invest in flagship promotion. They want to convert dead weight into pipeline contribution.
  • Internal pitch: "We can capture demand for products that get zero attention today."
  • Risk they fear: another tool that promises content at scale and underdelivers; deliverability or compliance damage from autonomous outbound.

B3 - Head of RevOps

  • Title examples: VP Revenue Operations, Head of Sales Ops, Director of RevOps.
  • KPIs: lead routing accuracy, sales-cycle efficiency, CRM data quality, forecast accuracy.
  • Why they buy Lurnet: leads arrive in CRM without product context; sales reps assume flagship interest and waste cycles. Lurnet attaches product narrative to every captured lead.
  • Internal pitch: "Reps will know what the prospect actually wants before the first call."
  • Risk they fear: integration burden, dirty webhook data, dedupe failures.

In early design partners B1 typically signs the contract; B2 often champions; B3 sits on the integration call.

3.2 End-user personas ​

U1 - Product Marketer

  • Day-to-day: writes positioning briefs, runs launches, supports sales enablement, edits landing pages with web team, manages competitive battle cards.
  • How they use Lurnet: every catalog entry surfaces in the workspace. They open one, review the AI-generated GTM kit, edit positioning and proof points, approve or reject, hit publish.
  • Frustrations Lurnet must avoid: waiting on engineering for page edits, fighting brand-style mismatches, regenerating from scratch when input is wrong.
  • Frequency of use: weekly, sometimes daily during launches.

U2 - Growth Marketer / Demand Gen Operator

  • Day-to-day: campaign planning, channel mix decisions, conversion analysis, ad copy briefs.
  • How they use Lurnet: pulls per-product analytics, exports approved outbound copy for sequence builds in HubSpot/Outreach, reviews routing rules.
  • Frustrations: copy that reads generic, slow regeneration cycles, lack of A/B variants until Phase 4.
  • Frequency: weekly to monthly.

U3 - Marketing Ops / Web Producer

  • Day-to-day: keeps web pages live, manages tracking, owns marketing-tech stack hygiene.
  • How they use Lurnet: configures publish targets (subdomain, slugs), wires HubSpot webhook, monitors page health, manages templates.
  • Frustrations: brittle integrations, opaque error states.
  • Frequency: setup-heavy at onboarding, then monthly.

U4 - RevOps Analyst

  • Day-to-day: maintains routing rules, lead-to-account matching, SLA monitoring, revenue analytics.
  • How they use Lurnet: defines routing rules per product line, monitors webhook delivery, validates that product context lands cleanly in CRM.
  • Frustrations: webhook silence, dedupe collisions, rule drift.
  • Frequency: setup-heavy, then ad hoc.

3.3 Jobs To Be Done ​

Top-level JTBD for the buyer:

"Help me give every product in my catalog a real GTM motion without hiring four more marketers."

Component JTBD:

  1. "When I launch a new module, I want a publish-ready landing page within a day."
  2. "When sales asks about a niche product, I want positioning, ICP, and proof points already documented."
  3. "When a prospect submits a form for a specific product, I want sales to know that without any hand-off process."
  4. "When I review marketing performance, I want to see what's working at product granularity."
  5. "When AI drafts customer-facing claims, I want to approve them before they go live."

The MVP must satisfy 1, 2, 3, and 5 strongly, and 4 directionally. JTBD #4 deepens in Phase 4.

4. Use Cases and User Stories ​

Eight scenarios anchor Phase 1 and Phase 2 development.

UC-1: Bulk catalog onboarding ​

  • Actor: PMM lead (B1/U1).
  • Goal: Get all 60 products imported and tagged for activation priority within the first day.
  • Story: "I upload our integration catalog as CSV, map columns to Lurnet fields, see validation errors row-by-row, fix the file, retry, and end with 60 products in my workspace tagged by product line."
  • Success: import finishes in under 10 minutes; validation errors point at specific rows; partial imports possible only when required fields are present; user can retry without duplicating valid rows.

UC-2: First narrative review ​

  • Actor: Product marketer (U1).
  • Goal: Review and approve a generated GTM kit for one specific module.
  • Story: "I open the workspace for our SOC 2 reporting module. I see the generated ICP hypothesis, positioning statement, three messaging pillars, two competitive angles, landing-page copy, and three outbound snippets. I edit the positioning to soften a claim, mark one competitive angle as risky, regenerate just the outbound, and approve the kit."
  • Success: edit-in-place works; regenerate scope is granular (one section, not whole kit); approval state is per-section; risky-claim flag is explicit and reviewable.

UC-3: Publish a product page ​

  • Actor: Product marketer + marketing ops (U1/U3).
  • Goal: Publish a hosted landing page for an approved product within minutes.
  • Story: "After approving the kit, I select the landing-page template, preview the page, set the slug to /products/soc2-reporting, configure the form to ask for name + email + company, and publish. I share the URL with sales."
  • Success: preview-to-published in under 2 minutes; slug uniqueness enforced per tenant; published version locked to the approved artifact version.

UC-4: Capture and route a lead ​

  • Actor: RevOps analyst (U4) for setup; prospect for capture.
  • Goal: A prospect submits the form on a published page; the lead lands in HubSpot with product context within seconds.
  • Story: "RevOps configures the HubSpot webhook with API credentials and a routing rule: 'route SOC 2 leads to the compliance sales pod.' A prospect submits the form. Lurnet captures the lead, dedupes against the last 7 days, fires the webhook, and shows the routing event in the dashboard. The HubSpot contact has product=soc2-reporting and the approved positioning attached as notes."
  • Success: webhook delivery success rate >99% in MVP; dedupe configurable per tenant; failed webhooks retry with exponential backoff.

UC-5: Catalog change refresh ​

  • Actor: PMM lead (B1/U1).
  • Goal: Update the catalog after a product rename and have only the affected narrative regenerate.
  • Story: "Our 'Audit Logs' product was renamed 'Compliance Logs.' I re-import the CSV. Lurnet detects only this one product changed. The workspace shows the artifact as stale and offers regenerate. I regenerate, review, approve."
  • Success: change detection by row hash; stale state is visible; regenerate cost is bounded to changed entries.

UC-6: Weekly portfolio review ​

  • Actor: PMM lead (B1).
  • Goal: Identify which products are underperforming and which narratives are converting.
  • Story: "Each Monday I open the analytics view filtered to the last 7 days. I see products imported, kits approved, pages published, page visits, form fills, and routed leads, ranked. Three products jump out: high visits, low form fills. I flag those for narrative iteration."
  • Success: filters work; rankings are reliable; CSV export available; product-level drill-down works.

UC-7: Sales handoff with product context ​

  • Actor: Sales rep (downstream consumer; not directly a Lurnet user).
  • Goal: Open a HubSpot lead and immediately understand what product they care about and how to pitch it.
  • Story: "A new lead lands. I see product=compliance-logs in the contact properties, the approved positioning in the notes, two suggested talking points, and a link back to the Lurnet workspace for the product. I prepare for the call in 3 minutes."
  • Success: product-level context visible in HubSpot; link back to Lurnet works; positioning is current with the published artifact.

UC-8: Concierge bulk activation ​

  • Actor: Lurnet team during concierge phase + design-partner PMM (B1/U1).
  • Goal: Activate 20 products in 5 business days during the concierge test.
  • Story: "Lurnet's team imports the design partner's catalog, generates kits in bulk, walks the PMM through review, approves at 60% acceptance, publishes pages, wires HubSpot webhook, and shows live form fills by day 5."
  • Success: the concierge gates from planning.md are met. This is not a self-serve flow; it is a measured human-assisted activation.

5. Functional Requirements ​

Organized by the six MVP product surfaces from planning.md. Every requirement carries a priority: P0 (productized validation MVP must-have), P1 (follow-on), P2 (later). Requirements are tagged with FR-XX identifiers for traceability.

5.1 Catalog Import ​

  • FR-01 (P0) Accept CSV upload up to 5 MB / 5,000 rows.
  • FR-02 (P0) Map source columns to Lurnet schema fields with a guided UI.
  • FR-03 (P0) Validate per-row; flag missing required fields, format issues, duplicate keys.
  • FR-04 (P0) Allow partial import only when required fields are present; rejected rows reported with reason.
  • FR-05 (P0) Persist import history with file, mapping, timestamp, user, validation report.
  • FR-06 (P0) Detect changed rows on re-import via hashing; mark affected entries as stale.
  • FR-07 (P1) JSON API ingestion endpoint with the same validation semantics.
  • FR-08 (P1) Schema mapping templates per beachhead vertical (MarTech/AdTech, AI platform, vertical SaaS).
  • FR-09 (P2) PIM and marketplace connectors (Salsify, Productsup, equivalents).

5.2 Product Workspace ​

  • FR-10 (P0) Per-tenant product list with filter, search, sort by activation state.
  • FR-11 (P0) Per-product detail page showing source fields, generated artifacts by section, approval state, version history.
  • FR-12 (P0) Edit source fields (overrides) without re-importing the catalog.
  • FR-13 (P0) Tag products by line, segment, owner, activation priority.
  • FR-14 (P1) Bulk operations (regenerate, approve, publish) across selected products.

5.3 Narrative Review ​

  • FR-15 (P0) Render generated GTM kit by section: ICP, positioning, messaging pillars, competitive angles, landing-page copy, outbound snippets.
  • FR-16 (P0) Inline edit per section with rich text where appropriate.
  • FR-17 (P0) Regenerate per section without affecting other sections; show generation cost estimate.
  • FR-18 (P0) Highlight risky claims (unsupported, comparative, regulated) with explanatory notes.
  • FR-19 (P0) Show diff between artifact versions.
  • FR-20 (P1) Side-by-side comparison of two narrative variants.
  • FR-21 (P1) Comment threads per section for review collaboration.

5.4 Approval Workflow ​

  • FR-22 (P0) Approve, reject, or request-changes per section; per-product overall state derived from sections.
  • FR-23 (P0) Block publishing until all customer-facing sections are approved.
  • FR-24 (P0) Capture approver identity, timestamp, and comment.
  • FR-25 (P0) Lock published artifact version; new edits create a new version requiring re-approval.
  • FR-26 (P1) Multi-approver workflow (PMM + legal + brand) configurable per tenant.
  • FR-27 (P1) Auto-flag claims that match user-defined risky-language rules.

5.5 Landing and Capture ​

  • FR-28 (P0) Hosted landing-page template parameterized by approved artifact.
  • FR-29 (P0) Configurable slug per product within tenant subdomain.
  • FR-30 (P0) Capture form (name, email, company, optional question) with validation.
  • FR-31 (P0) Lead dedupe by tenant + email within configurable time window.
  • FR-32 (P0) Page analytics: visits, form fills, conversion rate.
  • FR-33 (P1) Custom CSS overrides per tenant for brand match.
  • FR-34 (P1) Multiple page templates (long-form, short-form, comparison).
  • FR-35 (P2) Custom domain (CNAME to Lurnet) with TLS.

5.6 Routing ​

  • FR-36 (P0) HubSpot webhook integration: contact create / update with product context properties.
  • FR-37 (P0) Generic webhook fallback with retry policy and signing.
  • FR-38 (P0) Routing rules per product line, segment, region.
  • FR-39 (P0) Webhook delivery dashboard: success, failure, retry, last error.
  • FR-40 (P1) Salesforce integration with the same semantics.
  • FR-41 (P2) Bidirectional CRM sync (status, opportunity stage feeding back).

5.7 Analytics ​

  • FR-42 (P0) Per-product metrics: imports, approvals, pages published, visits, form fills, routed leads.
  • FR-43 (P0) Time-range filter (last 7 / 30 / 90 days).
  • FR-44 (P0) CSV export of metric tables.
  • FR-45 (P1) Cohort comparison (products launched in week X vs Y).
  • FR-46 (P2) Narrative-variant performance attribution.

5.8 Cross-cutting ​

  • FR-47 (P0) Tenant isolation: all data scoped by tenant; no cross-tenant queries.
  • FR-48 (P0) RBAC: admin / editor / viewer roles per tenant minimum.
  • FR-49 (P0) Audit log of approval, publish, configuration, and delete events.
  • FR-50 (P0) Configurable AI provider with cost reporting per tenant.
  • FR-51 (P1) SSO (Google, Microsoft) at tenant level.
  • FR-52 (P2) SCIM provisioning for enterprise.

6. Non-Functional Requirements ​

6.1 Performance ​

  • NFR-01 Catalog import of 1,000 rows completes in under 60 seconds (excluding generation).
  • NFR-02 Single-product GTM kit generation completes in under 90 seconds for the 4-step pipeline using mid-tier models.
  • NFR-03 Workspace page loads in under 2 seconds for catalogs up to 500 products.
  • NFR-04 Published landing pages serve in under 500 ms p95 globally (CDN-backed).
  • NFR-05 Webhook delivery initiated within 5 seconds of form submission.

6.2 Reliability ​

  • NFR-06 API uptime target 99.5% during MVP; 99.9% by Phase 2.
  • NFR-07 Published landing-page uptime 99.9% from first public page launch.
  • NFR-08 Webhook delivery retry with exponential backoff up to 24 hours; persistent failure surfaces as alert.
  • NFR-09 No silent generation failures: every failed generation shows a user-visible error and a retry option.
  • NFR-10 Daily Postgres backups with 30-day retention; tested restore quarterly.

6.3 Security ​

  • NFR-11 All data encrypted at rest and in transit.
  • NFR-12 Tenant isolation enforced at the database layer (row-level security or per-tenant schemas, decided at scaffold time).
  • NFR-13 Webhook signing with shared secret; reject unsigned or expired signatures.
  • NFR-14 API auth: session cookies for web app, signed JWT for programmatic access.
  • NFR-15 Secrets stored in a managed secret store or deployment vault; no plaintext credentials in repos or images.
  • NFR-16 Penetration test before any enterprise contract.

6.4 Compliance and Privacy ​

  • NFR-17 GDPR-compliant data handling for EU prospects: lawful basis, opt-out, export, delete.
  • NFR-18 Security-readiness review target by end of Phase 2; formal SOC 2 timing depends on enterprise demand.
  • NFR-19 Lead data retention configurable per tenant (default 24 months).
  • NFR-20 AI-generated content marked as such in API responses for auditability.
  • NFR-21 Audit log retention 12 months minimum, immutable.

6.5 Accessibility and i18n ​

  • NFR-22 Workspace UI meets WCAG 2.1 AA for color contrast and keyboard navigation.
  • NFR-23 Published landing pages meet WCAG 2.1 AA out of the box.
  • NFR-24 UTF-8 throughout; product names, copy, form fields support full Unicode.
  • NFR-25 English-only in MVP; multilingual generation deferred to Phase 5.

6.6 Observability ​

  • NFR-26 Structured logs with tenant id, user id, request id on every API request.
  • NFR-27 Metrics for generation latency, generation cost, webhook delivery, page latency, error rates per tenant.
  • NFR-28 Per-tenant cost dashboard for AI usage; alert on spike beyond plan.

6.7 Cost ceilings ​

  • NFR-29 Per-product GTM kit generation budget under $0.50 amortized at MVP scale.
  • NFR-30 Per-tenant infra cost target under $200/month at 100 products / 5,000 visits / 50 leads.

7. Data Model ​

Expanded from the planning.md sketch. All entities are tenant-scoped unless noted.

7.1 Core entities ​

Tenant

  • id (uuid, pk)
  • name
  • subdomain (unique)
  • plan (pilot | growth | enterprise)
  • settings (jsonb): branding, defaults, AI provider config
  • created_at, updated_at

User

  • id (uuid, pk)
  • tenant_id (fk)
  • email (unique within tenant)
  • role (admin | editor | viewer)
  • created_at, last_login_at

CatalogEntry

  • id (uuid, pk)
  • tenant_id (fk)
  • external_id (provided by import; unique per tenant)
  • name
  • category (nullable: module | integration | package | add_on | etc.)
  • description (text)
  • audience (text, nullable)
  • pricing_tier (text, nullable)
  • existing_url (text, nullable)
  • competitors (jsonb array of strings)
  • proof_points (jsonb array)
  • owner_user_id (fk, nullable)
  • routing_hints (jsonb)
  • source_hash (sha256 of source row content for change detection)
  • state (active | archived)
  • created_at, updated_at

CatalogImport

  • id (uuid, pk)
  • tenant_id (fk)
  • source_type (csv | json_api | connector)
  • source_filename (nullable)
  • mapping (jsonb)
  • validation_report (jsonb)
  • entry_count, error_count
  • imported_by_user_id (fk)
  • created_at

GtmArtifact

  • id (uuid, pk)
  • tenant_id (fk)
  • catalog_entry_id (fk)
  • kind (icp | positioning | pillars | competitive | landing_page | outbound_snippets)
  • current_version_id (fk to ArtifactVersion)
  • created_at, updated_at

ArtifactVersion

  • id (uuid, pk)
  • artifact_id (fk)
  • version_number (int, auto-increment per artifact)
  • body (jsonb; structure varies by kind)
  • model_metadata (jsonb): provider, model, tokens, cost, generation_pipeline_id
  • source_input_hash (sha256 of inputs used)
  • approval_state (draft | pending | approved | rejected)
  • approved_by_user_id (fk, nullable)
  • approved_at (nullable)
  • comment (text, nullable)
  • created_at

PublishedPage

  • id (uuid, pk)
  • tenant_id (fk)
  • catalog_entry_id (fk)
  • slug (unique within tenant)
  • template (text)
  • artifact_version_ids (jsonb; locked snapshot of approved versions used)
  • state (draft | published | unpublished)
  • published_at (nullable)
  • created_at, updated_at

Lead

  • id (uuid, pk)
  • tenant_id (fk)
  • catalog_entry_id (fk)
  • published_page_id (fk)
  • email (text)
  • name (text, nullable)
  • company (text, nullable)
  • form_data (jsonb)
  • dedupe_key (text)
  • captured_at

RoutingEvent

  • id (uuid, pk)
  • tenant_id (fk)
  • lead_id (fk)
  • destination (hubspot | webhook)
  • payload (jsonb)
  • delivery_state (pending | delivered | failed | retrying)
  • last_attempt_at (nullable)
  • attempt_count (int)
  • last_error (text, nullable)
  • created_at, updated_at

MetricEvent

  • id (uuid, pk)
  • tenant_id (fk)
  • catalog_entry_id (fk, nullable)
  • published_page_id (fk, nullable)
  • kind (visit | form_fill | approval | publish | route_success | route_failure | reply | meeting)
  • payload (jsonb)
  • occurred_at (timestamp)

AuditLog

  • id (uuid, pk)
  • tenant_id (fk)
  • user_id (fk, nullable)
  • action (text; e.g., "artifact.approve", "page.publish", "lead.delete")
  • resource_type (text)
  • resource_id (uuid)
  • before (jsonb, nullable)
  • after (jsonb, nullable)
  • created_at

7.2 Relationships ​

  • Tenant 1-N User, CatalogEntry, CatalogImport, PublishedPage, Lead, RoutingEvent, MetricEvent, AuditLog.
  • CatalogEntry 1-N GtmArtifact, PublishedPage, Lead, MetricEvent.
  • GtmArtifact 1-N ArtifactVersion (with one current).
  • PublishedPage references frozen ArtifactVersion ids.
  • Lead 1-N RoutingEvent.

7.3 Lifecycle states ​

  • ArtifactVersion approval state machine: draft → pending → (approved | rejected). Approval is one-way per version; new edits create a new version starting at draft.
  • PublishedPage state machine: draft → published → unpublished. Republish allowed only with approved artifacts.
  • RoutingEvent state machine: pending → delivered (terminal) or pending → retrying → (delivered | failed). Failed is terminal after retry budget exhausted.
  • CatalogEntry stale flag: computed property based on current source_hash vs hash at last successful generation. Not a state; a derived signal.

7.4 Multi-tenancy ​

All queries scoped by tenant_id. Implementation options to evaluate at scaffold time:

  • Row-level security via Postgres RLS.
  • Per-tenant schemas (heavy at scale).
  • Application-layer scoping with mandatory tenant filter (most common for B2B SaaS at this stage).

Recommendation: application-layer scoping with mandatory tenant filter, plus a static-analysis check that fails PRs which omit it.

8. Critical UX Flows ​

Five flows that span the MVP. Each described step-by-step.

Flow 1: First-time tenant setup ​

  1. Founder/admin signs up, creates tenant, picks subdomain (lurnet.app/{subdomain} for hosted pages).
  2. Configures HubSpot integration (API key) or generic webhook URL.
  3. Configures default branding (logo, primary color).
  4. Sees empty workspace with onboarding checklist: import catalog, generate first kit, publish first page.

Flow 2: Catalog import → first artifact ​

  1. User clicks "Import Catalog," uploads CSV.
  2. Lurnet auto-detects column types and proposes mapping.
  3. User reviews mapping, fixes mismatches, hits "Validate."
  4. Validation report shows errors; user fixes file or accepts partial import.
  5. On import success, products land in workspace with state=imported.
  6. User selects up to 10 products and clicks "Generate."
  7. Generation runs in background; user sees per-product progress.
  8. On completion, user opens one product → workspace shows ICP, positioning, pillars, competitive angles, landing-page copy, outbound snippets, all in draft state.

Flow 3: Review → approve → publish ​

  1. User opens product workspace.
  2. Reads each section; edits where needed.
  3. Marks risky claim flagged by AI as addressed or rewrites.
  4. Approves each section; overall state moves to "ready to publish."
  5. User clicks "Publish landing page," picks template, sets slug, configures form fields.
  6. Preview renders in iframe; user proofs.
  7. Publish button locks current artifact versions; page goes live at lurnet.app/{subdomain}/products/{slug}.
  8. User shares URL with sales / posts to LinkedIn / adds to email signature.

Flow 4: Lead capture → routing → CRM ​

  1. Prospect visits published page.
  2. Page registers visit MetricEvent.
  3. Prospect submits form.
  4. Lurnet validates input, dedupes, persists Lead, registers form_fill MetricEvent.
  5. Routing engine selects destination based on rules (defaults to tenant HubSpot if configured).
  6. RoutingEvent created with payload including product context, approved positioning excerpt, page URL.
  7. Webhook fires; on 2xx response, RoutingEvent → delivered.
  8. HubSpot contact appears with custom properties: product_id, product_name, lurnet_workspace_url, captured_positioning.
  9. Sales rep sees full context on first touch.

Flow 5: Catalog refresh after change ​

  1. User re-uploads catalog CSV (one product renamed, two added).
  2. Lurnet computes per-row hash, identifies 1 changed + 2 new.
  3. Imports finalize: 1 entry updated (state=stale), 2 entries created.
  4. Stale entry shows banner: "Source fields changed; artifacts may be out of date."
  5. User clicks "Regenerate stale" → 1 product regenerates.
  6. Re-approves sections, republishes page; previous published version archived.

9. Out of Scope (MVP) ​

To keep scope honest, the following are explicitly out for the productized validation MVP:

  • LinkedIn automation
  • Paid ad creative generation or buying
  • A/B test orchestration UI (variant performance is logged; UI is Phase 4)
  • Multi-tenant self-serve onboarding (assisted in MVP)
  • Bidirectional CRM sync (status changes flowing back)
  • Voice agents / outbound calling
  • Asset translation (English only)
  • Mobile-first workspace UX (responsive yes; mobile-optimized later)
  • Marketplace / PIM connectors (CSV/JSON only in MVP)
  • Public catalog connectors (AppExchange, AWS Marketplace listings)

10. Open Questions ​

  • What is the minimum useful catalog size (10 entries? 25?) for the first design partner?
  • Do we publish on Lurnet-hosted preview URLs in MVP or push to customer subdomains via CNAME?
  • Approval workflow depth: single approver in MVP or multi-approver from day one?
  • Risky-claim detection: rule-based, LLM critique pass, or both?
  • Webhook signing: HMAC-SHA256 (standard) or per-tenant rotating keys?

These should resolve during Phase 0 discovery + concierge validation before Phase 1 build begins.