Controller-Led Orchestrated LLM System (n8n + OpenAI + Voiceflow)

SEEK AI – Project Scope
Lead-to-Revenue Orchestration System for Trades & Construction
1. System definition

SEEK AI is a lead-to-revenue orchestration system for the construction and trades market.

This system is not:

a chatbot

a booking widget

a form replacement

SEEK AI is designed to own and orchestrate the complete operational lifecycle around high-value jobs for contractors.

Operational loop owned by the system:

Advertising
→ Lead capture
→ Qualification
→ Inspection booking
→ Follow-up
→ Review
→ Feedback loop into advertising and operations

This loop is continuously active and integrated.

2. Core business value

The system delivers measurable value through:

Instant speed-to-lead (24/7 availability)

Consistent, rule-based qualification

Fewer wasted site visits

Higher inspection-to-job conversion

Reduced administrative workload

Clear, attributable ROI for contractors

3. Execution model (global, non-negotiable)

SEEK AI is built using a deterministic, controller-led architecture.

System roles

Voiceflow
Conversational user interface only

n8n
Central controller responsible for:

state management

rules and validation

flow control

retries and failure handling

integrations and side effects

LLM (OpenAI)
Used strictly for:

language interpretation

structured information extraction

response drafting

LLM constraints

Per user turn:

A single LLM invocation

The LLM may return:

structured signals (extracted fields, flags)

a message draft

The LLM must never:

decide conversation flow

call tools or APIs

mutate system state

perform bookings

accept or reject leads

All decisions are owned by deterministic logic in the controller.

4. System architecture model

The system is structured into two clearly separated layers.

A. Real-time, revenue-critical layer

This layer must be fast, predictable, and safe, as it directly affects revenue and trust.

Includes:

Lead intake

Qualification

Inspection booking

Immediate confirmations

B. Asynchronous value layer

This layer operates outside the live conversation and enhances long-term value.

Includes:

Follow-ups

Reminders

Review requests

Lead and advertising performance feedback

Contractor insights

These layers are architecturally separated but share structured data.

5. Lead intake & session handling

Leads enter from advertising channels or chat entry points

Each conversation is associated with:

a unique session

a specific contractor (tenant)

Conversation state is initialized and stored outside the LLM

6. Trade & service identification

The system must:

Identify the correct trade

Identify the service type (inspection-based work)

Ask clarification questions only when required

7. Progressive information collection

Information is collected progressively, only when needed:

Project description

Location

Timing / urgency

Contact details

The system must:

Avoid static forms

Avoid unnecessary questions

Adapt questions based on already known data

8. Qualification logic (controller-owned)

Qualification rules are contractor-specific, not global.

Examples:

Service area boundaries

Services offered

Minimum job size or seriousness

Basic feasibility constraints

The LLM may signal ambiguity or extracted values,
but final qualification decisions are deterministic.

9. Inspection booking (API-controlled)

Critical requirement:
End users must never see a calendar UI or booking link.

Booking behavior:

Available time slots are fetched via API
(GHL calendar preferred; Cal.com acceptable)

The system proposes 2–3 concrete time options in chat

The user selects a time in chat

The booking is created programmatically

Confirmation is sent automatically

The calendar functions strictly as a backend scheduling engine.

10. Post-booking actions

Immediately after booking:

CRM is updated

Status transitions are recorded

Confirmation messages are sent

Optional pre-inspection information may be delivered

11. Failure handling & resilience (mandatory)

The system must handle real-world failure scenarios, including:

User stops responding

Booking fails

Calendar is unavailable

Retry attempts are exhausted

Required behavior:

Explicit retry counters

Controlled retry timing

“Unreachable” state

Deterministic exit paths

No silent failures.
No infinite loops.

12. Follow-ups & reminders

The system must:

Send automated reminders prior to inspections

Nudge users who stop responding

Ensure messaging is status-aware and non-spammy

13. Reviews & quality feedback

After job completion:

Review requests are triggered automatically

Review status is stored

Quality signals (e.g. sentiment or NPS where applicable) are captured

14. Advertising & lead feedback loop

The system must support:

Tagging leads by source

Tagging lead outcomes (booked, rejected, no-show)

Feeding structured data back into:

advertising optimization

contractor reporting

A full analytics dashboard is not required,
but all data must be structured to support one.

15. Explicit exclusions

The system does not include:

Autonomous agent swarms

AI-driven ad optimization

Full custom SaaS frontend

Self-serve contractor onboarding portals

Automated pricing logic

Cross-trade optimization

16. Ownership & handover requirements

The system must be delivered with:

Clean, readable workflows

Consistent naming conventions

Documented state model

Documented failure and retry logic

Clear extension pathways

A different developer must be able to take over without reverse-engineering.

17. Design principles

Reliability over cleverness

Predictability over autonomy

Production realism over hype

Systems over isolated workflows

Final statement

SEEK AI is a production system, not an experiment.
This document describes the final operational behavior of the system as delivered.