Product Requirements Document (PRD)

AI-Powered Lead Qualification Chat

Project: AI-powered lead qualification chat
Version: 1.0
Status: Draft — pending engineering and stakeholder review
Last updated: April 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: all available company case studies, service offering
descriptions, team and location profile, engagement model documentation.
Content audit required before build (see OQ-01).

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 immediately. It collects email and optional
preferred time. It delivers the context packet to two channels simultaneously:
a Slack message to #new-leads (for immediate visibility) and a new lead
record in the CRM (for record and follow-up tracking). Email to sales@ is a
fallback only if both primary channels are unavailable. Target: < 5 minutes
from detection to notification.

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.

M10 — CRM lead record creation
At the point of any escalation or capture handoff, the system creates a new
lead record in the company CRM pre-populated with the full context packet
(conversation summary, qualification state, lead level, trigger, visitor data,
timestamp). The CRM is the system of record for all leads — the Slack
notification links to it so the sales rep does not need to reconstruct context.
Specific CRM platform to be confirmed pending OQ-04.

M11 — Calendly self-serve booking for hot leads
When a hot lead confirms they want to connect during business hours, the chat
presents a Calendly link for a 30-minute intro call with a two-day advance
booking minimum. The two-day buffer gives the assigned rep time to review the
context packet before the call. Calendly is not offered for warm or cold
capture handoffs — those flows end with email collection and human follow-up
only.

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.

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.

---

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 owner: AI Engineering Lead — ADR-001 (pending)

Key evaluation criteria: instruction-following quality, GDPR compliance posture,
cost at projected conversation volume, streaming latency, function calling support
for qualification state management.

---

Conversation Orchestration

Decision owner: AI Engineering Lead — ADR-002 (pending)

Key evaluation criteria: ability to maintain an explicit qualification state
object across turns, support for conditional branching (hot/warm/cold logic),
observability and debuggability of conversation state.

---

Knowledge Architecture

Decision: Selective RAG — Option B (agreed in PRD). See M2 for rationale.
Component-level decisions below remain open — ADR-003 (pending)

Key evaluation criteria: retrieval quality on technical B2B content, data
residency requirements, cost per query at projected volume, operational complexity.

---

Frontend Widget

Decision owner: Frontend / Full-stack Lead — ADR-004 (pending)

Key evaluation criteria: bundle size impact on company website load time,
ease of embedding without company site rebuild, streaming response support,
mobile responsiveness.

---

Notification and Lead Capture

Decision: Both Slack webhook (#new-leads) and CRM integration are required in V1 — Slack for speed, CRM for record (see M5, M10, FR-19). Email is fallback only. Calendly integration required for hot lead self-serve booking (M11, FR-24). Specific CRM platform to be confirmed pending OQ-04. ADR-005 to document final implementation choices.

Key evaluation criteria: delivery speed (< 5 min SLA from FR-19), structured
context packet support (FR-13), operational simplicity for MVP. Slack and CRM
are both required; the evaluation focuses on which CRM and which Slack
integration approach.

---

Data Storage

Constraint: minimal in v1. No CRM. Session logs and captured leads only.

Key evaluation criteria: ability to store structured conversation logs and
qualification state, query capability for post-launch analytics, operational
simplicity, cost at MVP scale.

---

Cloud Provider

Decision owner: Engineering Lead + Operations — ADR-006 (pending)

The cloud provider choice affects data residency (GDPR), latency for European
and US visitors, operational complexity for the team, and long-term cost. Three
candidates are under evaluation.

Key evaluation criteria:

• GDPR / data residency: Can all components — LLM API, vector store, conversation
  logs, lead data — run within EU boundaries? Azure has the clearest answer if
  Azure OpenAI Service is used. AWS and Fly.io require careful configuration
  to achieve the same guarantee.
• Operational overhead for MVP: Fly.io has the lowest setup cost for a small
  team. AWS has the highest. Azure sits in between, particularly if the team
  has existing Microsoft familiarity.
• LLM integration: If Azure OpenAI Service is selected as the LLM candidate,
  Azure as the cloud provider creates a natural, low-friction integration.
  If Anthropic or Groq is selected, provider choice is more neutral.
• Path to v2: AWS and Azure have broader managed services for CRM integration,
  advanced monitoring, and scaling. Fly.io is a good MVP platform but may require
  migration as the system grows.

Interaction with LLM candidate decision: The cloud provider and LLM provider
decisions are partially coupled. See dependency note in ADR-001 and ADR-006.

---

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 20 test conversations)
• 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
• Response latency p95 < 3 seconds verified under simulated load
• GDPR data notice displayed on first interaction
• Graceful degradation tested (AI service down → fallback form)
• Sales notification received within 5 minutes of hot lead detection (tested end-to-end)

---

9. Open Questions

These questions remain unresolved and require input before or during development.

---

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 next documents in the series are the Conversation Design Document
and the Technical Requirements Document.