Product Requirements Document (PRD)

AI-Powered Lead Qualification Chat

Project: AI-powered lead qualification chat
Version: 1.0
Status: Final — stakeholder sign-off complete, engineering review complete; TRD and CDD complete (May 2026); all open questions resolved; development start gates fully satisfied
Last updated: May 2026
Owner: Product / AI Engineering Team

---

1. Executive Summary

1.1 The Problem

The company website receives consistent inbound traffic but converts poorly into
qualified leads. The only conversion mechanism is a static contact form that cannot
engage visitors, answer questions, or differentiate between a CTO actively evaluating
vendors and a curious researcher. The sales team receives cold leads with no context.

Full problem definition in problem-statement.md.

1.2 The Solution

An AI-powered conversational chat widget embedded in the company landing page that
acts as an always-on acquisition channel. The chat responds to visitor questions with
the depth of a knowledgeable company representative, qualifies leads progressively
through natural conversation, and routes hot leads to the sales team in real time.

1.3 The MVP Hypothesis

An intelligent conversational interface converts more visitors into qualified leads
than a static contact form, and produces leads with a higher qualification rate.

This PRD defines the minimum viable implementation needed to validate that hypothesis.
It is not the complete system — it is the smallest version of the system that produces
a meaningful signal.

1.4 Success Metrics

Contact capture rate should not be read in isolation. Low capture rate paired with high conversation depth may indicate the approach is building brand value that does not show up in immediate conversions. A strategy re-evaluation is warranted only when both contact capture rate and conversation depth are below expectation simultaneously.

---

2. Background and Strategic Context

2.1 Why This, Why Now

The company’s growth depends on converting inbound interest into sales conversations.
The current form-based approach creates a high-friction, low-context entry point
that is misaligned with how technical buyers — the primary company audience — make
vendor decisions. They research deeply, ask specific questions, and move on quickly
if they do not find confidence-building answers.

Simultaneously, AI-powered chat is becoming table stakes for B2B service companies
competing for technical buyers. This is not a novel experiment — it is a catch-up
investment with a clear commercial rationale.

2.2 Alignment with Company Positioning

The chat reinforces three core elements of the company’s positioning:

Senior engineers. The chat speaks with technical depth and specificity,
not marketing language. It demonstrates the quality of thinking the visitor
can expect from the team.

AI expertise. A well-executed AI chat product is itself a proof point.
It signals that the company builds AI systems that work in production.

European timezone coverage. The outside-hours flow converts this
differentiator into a tangible experience — visitors understand the timezone
advantage before they speak to anyone.

---

3. Target Users

Full persona definitions in user-personas. This section summarises the
implications for product scope.

3.1 Target Personas

3.2 Negative Personas

3.3 Persona-Specific Tone

The chat adapts its register to the visitor profile it detects, within the
boundaries of the overall company voice.

With P1: Technically confident, peer-level. Uses engineering vocabulary without
explanation. Gets to the point. Does not over-explain what the company does.

With P2: Patient, educational, honest about complexity and cost. Does not
oversell. Acknowledges when something is a bigger conversation than a chat can handle.

With P3: Direct and efficient. Minimal qualification friction. Prioritises
connecting them with the right person quickly.

Overall voice: Professional but not corporate. Warm but not casual. The register
of a senior company engineer talking to a peer — not a sales assistant reading
from a script.

---

4. Feature Scope — MoSCoW

4.1 Must Have — MVP v1

These features are required to validate the core hypothesis. Without them,
the experiment cannot produce meaningful signal.

M1 — Conversational interface
A chat widget embedded on the company landing page. Visible as a passive icon
on page load. Opens into a full conversational interface on click. Responsive
on desktop and mobile.

M2 — Contextual question answering with selective RAG
The chat answers questions about the company’s services, engagement models, team
structure, and expertise using a hybrid knowledge architecture (Option B):

• System prompt layer: Conversation behaviour, qualification logic, tone
  guidelines, and persona instructions. Never contains domain content — only
  instructions. This layer is stable and controlled.
• RAG layer: Company-specific domain knowledge — case studies, service
  descriptions, team profiles, engagement models — stored as embeddings in a
  vector store and retrieved selectively at query time.

The system decides per turn whether to retrieve from the vector store or respond
directly from instructions. Questions about the company’s work, expertise, or specific
case studies trigger retrieval. Questions about conversation process, pricing
deflection, or handoff logic are handled from the prompt layer only.

Knowledge base scope for v1: publicly available company case studies (no NDA-protected
content), service offering descriptions, team and location profile, engagement model
documentation. Content audit required before build (see OQ-01) — only content already
published on the company website qualifies for v1 ingestion.

M3 — Progressive qualification
The chat detects fit signals across four dimensions (problem, authority, company,
timing) incrementally through natural conversation. It maintains a qualification
state object per session and escalates when the hot lead threshold is reached.
Full logic defined in qualification-signals.md.

M4 — Three-stage conversation model
Every conversation follows the respond → advance → propose sequence defined
in chat-behaviour.md. The system does not ask for contact
information before providing value. It proposes the next step proactively
when maturity signals are detected.

M5 — Hot lead escalation (business hours)
When a hot lead is detected during business hours, the chat proposes a
connection to the company team and collects the visitor’s email. It delivers
the context packet to two channels simultaneously: a Slack message to
#new-leads (for immediate visibility) and a new row in the leads table in the
existing PostgreSQL instance via PostgresCRMClient (for record and follow-up
tracking — see ADR-009). Email to sales@ is a fallback only if both
primary channels are unavailable. The sales team follows up by email or phone
within 2 business hours of receiving the Slack notification. No self-serve
booking tool is used — all scheduling is handled by the sales rep directly.

M6 — Outside-hours capture flow
When a hot lead or explicit handoff request occurs outside business hours,
the chat is transparent about availability, makes a specific follow-up
commitment, captures email, and optionally sends a relevant resource.
The company timezone is framed as a feature, not an apology.

M7 — Negative persona handling and disqualification
The chat does not escalate visitors classified as N1 or N2, and handles the
broader set of no-fit visitors defined in the disqualification path
(individual contractors, geography or regulatory mismatches, and any context
that clearly falls outside the company’s ICP).

For N1 (competitor): responds only with publicly available information;
does not engage with operational or pricing probes.

For N2 (researcher): helpful, no escalation, no contact push.

For all other no-fit visitors: acknowledges the mismatch honestly, offers
a relevant resource where possible, and closes the conversation with a positive
impression. The chat never pretends a visitor is a fit and never requests
contact information from a visitor who will not convert.

Full disqualification criteria and example responses in
chat-behaviour.md.

M8 — Existing client deflection
When a visitor identifies as an existing company client seeking support, the
chat recognises the out-of-scope context and routes them to the appropriate
contact (account management), not to the sales team.

M9 — Pricing deflection
The chat does not give specific pricing. When asked, it acknowledges the
question honestly and explains why scoping is needed before any number is
meaningful. It offers a call as the natural next step. It does not sound evasive.

M10 — CRM lead record creation
At the point of any escalation or capture handoff, the system creates a new
lead record pre-populated with the full context packet (conversation summary,
qualification state, lead level, trigger, visitor data, timestamp). In v1, the
leads table in the existing PostgreSQL instance is the system of record for
leads (see ADR-009).

Example response pattern:

“We don’t publish standard rates — the right engagement structure really
depends on what you’re building, your timeline, and how you work best with
external teams. A 20-minute conversation with one of our engineers would
give you a much more useful number than anything I could tell you here.
Want me to set that up?”

4.2 Should Have — MVP v1 if capacity allows

S1 — Proactive greeting trigger
After a visitor spends more than 45 seconds on the page without interacting,
the chat icon displays a subtle prompt (e.g. “Have a question about AI
engineering?”). Does not auto-open the chat — respects the visitor’s agency.

S2 — Conversation summary email to visitor
After a handoff, the chat sends the visitor a brief email summarising the
conversation and confirming next steps. Increases trust and reduces no-shows
on booked calls.

S3 — Relevant case study surfacing
Within the static knowledge base, the chat proactively surfaces the most
relevant case study based on the visitor’s described problem, rather than
waiting to be asked.

4.3 Could Have — Backlog v2

C1 — RAG over full case study library
Dynamic retrieval from a structured knowledge base of all company case studies,
enabling precise matching between visitor problems and relevant work. Requires
a content audit and embedding pipeline before implementation.

C2 — A/B testing framework
Infrastructure to test different greeting approaches, conversation opening
lines, and escalation timing. Requires a baseline dataset from v1 before
meaningful experiments can be designed.

C3 — Multi-page context awareness
The chat knows which page the visitor is on and adjusts its opening approach
accordingly (homepage vs. services page vs. a specific case study).

C4 — Returning visitor recognition
If a visitor has chatted before, the chat acknowledges the previous conversation
and picks up from where they left off, rather than starting cold.

4.4 Won’t Have — Explicitly out of scope

W1 — Support channel for existing clients.
The chat is an acquisition tool. Client support is a different product
with different requirements.

W2 — Autonomous deal closing.
The chat qualifies and connects. It does not negotiate, quote, or close.

W3 — Voice or video interface.
Text only in v1.

W4 — Integration with third-party chat platforms (Intercom, Drift, etc.)
Custom build in v1 to maintain full control over conversation logic and data.

W5 — Self-serve calendar booking.
All handoff flows end with email collection. Scheduling is handled by the sales
rep directly — no Calendly or equivalent integration in v1.

---

5. Functional Requirements

5.1 Conversation System

5.2 Qualification and Escalation

5.3 Knowledge Base and RAG

5.4 Handoff and Capture

---

6. Non-Functional Requirements

6.1 Performance

6.2 Availability

6.3 Security and Privacy

6.4 Observability

---

7. Technical Constraints and Candidates

7.1 Stack Candidates — v1

No technology decisions are final at this stage. This section lists the
candidate options for each component, the key evaluation criteria, and the
open decision. Final selections are made in the Technical Requirements Document
and recorded in the corresponding ADR.

---

LLM Provider

Decision: Anthropic Claude Haiku 4.5 via the Anthropic API — ADR-001 (Accepted, April 2026). Selected for instruction-following reliability under a complex system prompt, EU data processing endpoint availability (Frankfurt), function calling support for RAG triage (EC-01), and cost profile at MVP volume.

---

Conversation Orchestration

Decision: LangGraph (StateGraph) — ADR-002 (Accepted, April 2026). Selected for native stateful graph execution, explicit node/edge control suited to the qualification state machine, support for deterministic programmatic nodes alongside LLM nodes, and built-in observability of graph execution.

---

Knowledge Architecture

Decision: Selective RAG — Option B (agreed in PRD). See M2 for rationale.
Component decisions resolved — ADR-003 (Accepted, April 2026) and ADR-004 (Accepted, April 2026).

---

Frontend Widget

Decision: Custom web component (<growth-chat> element, embeds via a <script> tag on the company site) — ADR-005 (Accepted, April 2026). Selected for minimal bundle footprint (≤ 200KB gzipped), no framework dependency on the host site, full control over streaming UX, and straightforward embedding without a site rebuild.

---

Notification and Lead Capture

Decision: Both Slack webhook (#new-leads) and PostgresCRMClient are required in V1 — Slack for speed, leads table for record (see M5, M10, FR-19). Email to sales@ is fallback only on dual-channel failure. No self-serve booking tool — all scheduling handled by the sales rep directly. OQ-04 resolved by ADR-009 (Accepted 2026-05-15): no external CRM in v1; PostgresCRMClient persists the full ContextPacket to the leads table in the existing Neon instance. The CRMClient interface is preserved — a HubSpotCRMClient or equivalent is a drop-in swap in v2.

Decision: Slack webhook for real-time notification + PostgresCRMClient / leads table for structured lead persistence. Evaluation criteria met: reliable context packet delivery (FR-13), zero new infrastructure, operational simplicity for MVP.

---

Data Storage

Decision: PostgreSQL — single storage backend for all persistence needs (ADR-003, ADR-004).

No separate vector store service is needed. PostgreSQL handles both the knowledge index and session state, keeping the infrastructure footprint minimal.

---

Rate Limiting, Cost Controls, and Context Window Management

Resolved in TRD Section 8 and Section 10 (May 2026) — EC-12, EC-13.

Rate limiting and cost controls (EC-12 — resolved): Per-IP rate limiting via Cloudflare Rules (30 req / 10 min); per-session rate limiting via slowapi middleware (20 messages / 5 min); per-session token budget of 16,000 tokens (MAX_TOKENS_PER_SESSION); monthly cost cap of $50 with alerting at 80% (MONTHLY_COST_CAP_USD); bot prevention via Cloudflare Bot Score, API key validation, and 2,000-character message size limit. See TRD Section 8.

Context window management (EC-13 — resolved): Sliding window strategy — CONTEXT_WINDOW_TURNS = 10 exchange pairs (configurable environment variable). Qualification state is stored independently on SessionState and is never evicted from the window, so the LLM never loses qualification context regardless of conversation length. See TRD Section 10.

---

Cloud Provider

Decision: Fly.io (fra) + Neon (eu-central-1) + Cloudflare — ADR-006 (Accepted, April 2026). Full EU data residency at every processing step; low operational overhead for a small team.

All components — LLM API (Anthropic EU endpoint), embeddings (OpenAI EU endpoint), session state, and knowledge index — process and store data within EU territory, satisfying GDPR Article 44 without relying on Standard Contractual Clauses.

---

7.2 Key Technical Risks

---

8. Definition of Done

A feature is complete when it meets all of the following:

• Functional requirement implemented and verified against the acceptance criteria
• Unit tests covering the qualification state logic
• Conversation tested against all five persona profiles with at least 10 simulated conversations each
• Edge cases documented and handled (stall, frustration, out-of-scope, negative persona)
• Analytics events firing correctly for all defined event types
• No hallucination on company knowledge base content (verified by manual review of 70–80 structured test conversations: 10 per persona × 5 personas + 20–30 adversarial cases covering out-of-scope questions, competitor probes, and absent-content queries). Test cases must have defined expected outputs and be run through a repeatable eval framework.
• RAG retrieval verified: relevant questions return above-threshold results; irrelevant questions do not trigger retrieval
• Prompt layer and RAG layer correctly separated — no domain content in system prompt
• p95 TTFT (time-to-first-token) < 3 seconds verified under a stress test of 10 concurrent sessions sustained for 10 minutes (TRD Section 7 — ~40× expected peak production concurrency). Streaming must be enabled; full-response latency is not the target metric.
• GDPR data notice displayed on first interaction
• Graceful degradation tested (AI service down → fallback form)
• Sales notification verified end-to-end on hot lead detection: Slack message delivered to #new-leads and row inserted in leads table
• Conversation end is consistently defined in code and analytics as: explicit close action, 15-minute inactivity timeout, or session expiry — all three cases fire the conversation-ended event with the correct termination type field.

---

9. Open Questions

All open questions are resolved. Entries are retained for traceability.

---

10. Referenced Documents

---

This PRD defines the scope of the company website chat MVP. It is a living document
and will be updated as open questions are resolved and decisions are made during
development. The Conversation Design Document and the Technical Requirements Document
are complete — the TRD is the authoritative reference for all technology decisions
and implementation specifications.