AskLibra AI Lead Nurture & Appointment Booking Platform
A state-driven AI lead nurture app built inside AskLibra's AI Apps platform. The system combines Next.js, Prisma, Supabase, n8n, Gmail or SMTP, Google Calendar, and AI-assisted message generation to manage follow-up, reply handling, booking clarification, appointment creation, activity logging, and app runtime state while keeping AskLibra as the canonical source of truth.
Role
Product Architect, Automation Engineer, Full-Stack Developer, AI Workflow Designer
Category
Business Automation
Status
Completed
Year
2026
Private customer and automation data
The production environment contains private lead, email, calendar, credential, and workflow data. This case study focuses on product architecture, automation behavior, safeguards, and tested outcomes without exposing personal records or secrets.
Overview
AI Lead Nurture is a focused AI application inside AskLibra's broader AI Apps platform. It was built to turn lead follow-up into a state-driven operational system instead of a collection of disconnected automation chains.
The app keeps AskLibra and its database as the canonical source of truth while n8n acts as the execution and orchestration engine. Lead state, nurture status, installation context, connections, credentials, activity history, and booking outcomes remain platform-owned.
The implemented flow was manually tested end-to-end, including scheduled follow-up, reply detection, repeat-reply handling, duplicate-processing protection, booking-intent detection, timezone resolution, availability checks, Google Calendar event creation, attendee invitation, booking clarification, unavailable-time handling, activity logging, and booked-state transitions.
Business problem
Lead nurture becomes unreliable when follow-up, replies, scheduling, and customer context are split across email, calendars, automation tools, and manual review.
- Leads can be forgotten after the first contact
- Follow-up timing becomes inconsistent
- Long-running automation wait chains are difficult to maintain safely
- Replies can arrive after automation state has already changed
- Duplicate webhook or Gmail events can trigger repeated side effects
- Booking requests may contain incomplete or ambiguous date and time information
- Calendar availability and timezone context must be verified before creating an appointment
- Successful business actions must not be reported as failures when secondary logging fails
- Email and calendar credentials must remain platform-owned rather than embedded in workflow logic
- App activity needs to remain isolated to the correct tenant, installation, and product context
Product objective
Build a reusable AI lead nurture product that can follow up automatically, understand replies, assist with scheduling, create appointments, and preserve trustworthy state across the platform.
The system uses database-backed nurture state and scheduled polling rather than relying on long-running n8n Wait chains. Automation decisions use current state at execution time, which makes retries, replies, booking, and lifecycle transitions easier to reason about.
- Automate timely lead follow-up
- Stop scheduled nurture after meaningful replies
- Continue handling booking conversations after the first reply
- Prevent duplicate reply and booking effects
- Parse booking intent without inventing dates or times
- Check real calendar availability before booking
- Create calendar events and invitations automatically
- Keep email and calendar access behind platform-owned connection services
- Centralize activity and error logging
- Preserve deterministic lead and nurture state
Lead nurture lifecycle
The app separates scheduled nurture, reply handling, and appointment booking into state-driven workflows that coordinate through the AskLibra database.
- 1
Capture or activate lead
A lead enters the AI Lead Nurture app and receives an active nurture state tied to the platform's tenant and app context.
- 2
Send initial outreach
The app prepares and sends the first nurture email through the platform email service.
- 3
Persist nurture state
Current status and nextFollowUpAt are stored in the database so future execution uses durable state rather than an in-memory workflow timer.
- 4
Find due nurture states
The scheduler queries ACTIVE nurture states that are due for follow-up.
- 5
Check eligibility
Current lead and nurture state are re-evaluated before another message is generated or sent.
- 6
Generate follow-up
The follow-up writer uses lead context and nurture state to prepare the next appropriate message.
- 7
Send and advance state
Successful delivery is logged and the nurture state advances to the next follow-up point.
- 8
Monitor incoming replies
The reply monitor searches for responses connected to ACTIVE or already-REPLIED nurture states.
- 9
Record reply idempotently
The shared activity logger writes a deterministic idempotency key so a repeated Gmail event cannot trigger the same downstream action twice.
- 10
Detect booking intent
A reply is analyzed for scheduling intent without treating AI output as authoritative permission or state.
- 11
Resolve calendar context
Stored calendar metadata supplies trusted timezone and calendar identity before parsing a requested appointment.
- 12
Clarify incomplete requests
If a concrete date or time is missing, the system asks the lead for clarification rather than inventing a booking.
- 13
Check availability
The Google Calendar service verifies the requested slot before any event is created.
- 14
Create appointment
When the slot is available, the app creates the calendar event and invites the lead.
- 15
Mark nurture BOOKED
The successful appointment updates the canonical nurture state to BOOKED and records the outcome.
Automation workflow
Automate the repeatable parts of lead nurture and scheduling while preserving deterministic state, clear safeguards, and trustworthy business outcomes.
Previous manual process
Receive lead -> manually remember follow-up -> monitor inbox -> interpret replies -> check calendar -> confirm availability -> create appointment -> send invite -> update lead status -> remember to stop further follow-up.
Connected systems
Trigger
- Lead activation, scheduled nurture due time, or incoming lead reply
Captured inputs
- Lead identity
- Email address
- Lead context
- Current nurture status
- nextFollowUpAt
- Conversation or reply content
- Connected email account
- Connected Google Calendar
- Calendar timezone
- App installation context
Decision logic
- Only ACTIVE nurture states are eligible for normal scheduled follow-up.
- A meaningful first reply transitions an ACTIVE nurture state to REPLIED.
- Already-REPLIED leads can still be processed when later messages contain booking information.
- Duplicate reply activity stops downstream booking or clarification behavior.
- Booking intent alone is not enough; required date, time, and trusted timezone context must exist.
- Incomplete scheduling requests enter clarification rather than guessing.
- Calendar availability is checked before event creation.
- Successful calendar booking remains BOOKED even if secondary activity logging later fails.
- Send success and send failure use separate branches so failed messages do not create false EMAIL_SENT activity.
Outputs
- Initial and follow-up nurture emails
- Durable lead nurture state
- Reply activity records
- Booking-intent classification
- Clarification email when scheduling context is incomplete
- Unavailable-time response when a slot cannot be booked
- Google Calendar availability result
- Calendar event with attendee invitation
- BOOKED nurture state
- Shared activity log
- Shared error log
Human review points
- Review leads and conversation history
- Adjust nurture configuration
- Inspect automation failures
- Take over a conversation when needed
- Review appointments
- Pause or stop nurture
- Change lead lifecycle state
- Handle cases outside registered automation behavior
Safeguards
- Database-backed state instead of long-running Wait chains
- Deterministic activity idempotency keys
- Duplicate Gmail event protection
- Separate send-success and send-error branches
- Shared SS - Error Logger workflow
- Shared SS - Activity Logger workflow
- Provider-normalized email results
- Trusted calendar metadata and timezone resolution
- Availability verification before event creation
- Clarification for incomplete booking requests
- Best-effort secondary logging after successful business actions
- Platform-owned email and calendar credentials
Product layers
The app is organized as a focused AI product running on top of shared AskLibra platform services and an external automation engine.
Lead nurture engine
Controls the state-driven follow-up lifecycle and determines when another nurture action is eligible.
- Lead nurture states
- Scheduler
- Eligibility checks
- Follow-up generation
- State advancement
Reply intelligence
Monitors incoming email, associates replies with the correct nurture state, and prevents duplicate downstream processing.
- Reply monitor
- ACTIVE and REPLIED lookup
- Reply activity
- Idempotency
- Booking-intent detection
Appointment booking
Turns concrete scheduling requests into verified calendar appointments while routing incomplete requests through clarification.
- Booking request parser
- Timezone resolution
- Availability checks
- Clarification
- Unavailable-time handling
- Calendar event creation
- Attendee invitations
Platform connections
Keeps email and calendar integrations behind AskLibra-owned connection and credential services.
- WorkspaceConnection
- Email sender service
- Gmail
- SMTP
- Google Calendar OAuth
- Calendar metadata
Operational safety
Uses shared logging and deterministic state transitions so retries and partial failures do not create misleading outcomes.
- SS - Activity Logger
- SS - Error Logger
- Idempotency keys
- Normalized provider responses
- Partial-success handling
- Canonical database state
AI Apps architecture
Packages AI Lead Nurture as a focused application inside AskLibra's broader app platform rather than as a standalone collection of workflows.
- App manifest
- App platform runtime
- Entitlements
- Installation lifecycle
- Connections
- Capabilities
- Marketplace foundation
Gallery
Product media can be added here without changing the page renderer.
AI Lead Nurture app
The focused app interface for managing lead nurture activity, booking state, and automation outcomes.
Reply and booking automation
The reply-monitoring workflow detects responses, prevents duplicate processing, identifies booking intent, and routes valid requests into the appointment-booking flow.
Appointment booking
A successfully created Google Calendar appointment with the lead invited as an attendee after availability and booking context were validated.
My role
I designed the product architecture, lead nurture lifecycle, app-platform integration, state model, automation boundaries, reply-monitoring logic, booking flow, provider abstractions, calendar integration, idempotency safeguards, and operational logging. I used AI-assisted development to accelerate implementation, debugging, workflow iteration, migration repair, and documentation while manually validating the end-to-end automation behavior and booking results.
AI-assisted, human-directed development
AI-assisted development accelerated architecture review, TypeScript implementation, n8n workflow construction, expression debugging, API-contract design, Prisma migration repair, test planning, and documentation. Product direction, architecture decisions, workflow behavior, integration choices, safeguards, manual testing, and final acceptance remained human-directed.
AI accelerated
- TypeScript implementation support
- n8n workflow scaffolding
- Expression construction and debugging
- API contract review
- Booking-flow iteration
- Error-path review
- Prisma migration troubleshooting
- Documentation drafting
- Test scenario planning
Human direction and ownership
- Product vision
- AI app architecture
- Lead nurture lifecycle
- State model
- Tool and provider selection
- Booking behavior
- Access-model decisions
- Data ownership rules
- Security boundaries
- Manual testing
- Interpretation of failures
- Final implementation approval
Architecture and stack
Technology stack
Technical challenges
Replacing long-running Wait chains
The nurture system was redesigned around persisted state and nextFollowUpAt so execution could survive retries, deployments, replies, and lifecycle changes without depending on long-lived n8n workflow instances.
Reply processing after state changes
A lead must stop normal nurture after replying, but later replies can still contain booking information. Lookup and mutation behavior were separated so REPLIED conversations remain actionable without repeating the ACTIVE-to-REPLIED transition.
Duplicate message protection
Repeated Gmail events and workflow retries could otherwise create duplicate clarification messages or appointments. LeadActivity idempotency keys were introduced and verified to stop duplicate downstream effects.
Booking without hallucinating schedule details
The booking parser needed to distinguish concrete scheduling information from vague intent and use trusted calendar timezone metadata rather than inventing missing dates, times, or timezones.
Partial-success handling
Calendar creation, nurture state, and activity logging have different importance. The workflow preserves a successful BOOKED result even when secondary logging fails and reports the logging issue separately.
Provider-independent email contracts
Gmail and SMTP return different provider payloads, so the platform email service was normalized around a shared result shape consumed by n8n.
Calendar connection architecture
Google Calendar OAuth, metadata, timezone, availability, and event creation were routed through platform-owned connection services instead of embedding credential ownership inside workflow logic.
Prisma migration-history repair
Historical migration gaps and drift prevented clean schema replay. The migration chain was reconstructed and reconciled until the full history replayed successfully against a fresh shadow database and produced an empty schema diff.
Results
Qualitative workflow outcomes
State-driven nurture
Scheduled follow-up now uses durable database state instead of long-running automation wait chains.
Reply-aware automation
Incoming replies stop ordinary nurture while still allowing later booking messages to be processed.
Duplicate-safe processing
Idempotent activity logging prevents repeated Gmail events from producing duplicate clarifications or bookings.
Calendar-backed booking
Concrete booking requests are validated against Google Calendar availability before event creation and attendee invitation.
Clarification before guessing
Incomplete scheduling requests are routed through clarification instead of inventing missing date, time, or timezone details.
Shared email abstraction
Gmail and SMTP use one normalized platform send-result contract for downstream automation.
Canonical platform state
Lead state, nurture state, connections, installation context, credentials, and booking outcomes remain owned by AskLibra rather than n8n.
End-to-end tested
Follow-up, replies, duplicate protection, booking intent, availability, event creation, invitations, clarification, unavailable-time handling, and booked-state updates were manually validated.
Project takeaways
The main lessons from turning lead follow-up and appointment scheduling into a reusable AI application instead of a collection of one-off automations.
State should outlive workflow execution
Long-running workflow timers make nurture fragile when replies, retries, deployments, or lifecycle changes occur. Persisting nurture state in the application database makes the next action depend on current truth rather than an old workflow snapshot.
Replies and nurture state are related but not identical
The first meaningful reply should stop scheduled nurture, but that does not mean the conversation is finished. Later messages can still contain scheduling information, so reply discovery and state mutation need separate rules.
Booking requires deterministic context
AI can help interpret scheduling language, but timezone, entitlement, installation state, calendar availability, and final booking status must remain deterministic platform decisions.
Secondary failures should not rewrite business truth
If an appointment is successfully created and the nurture state is BOOKED, a later activity-log failure should be reported as a warning rather than changing the business outcome to failure.
The app should remain a product, not a workflow bundle
n8n executes the work, but AskLibra owns the app lifecycle, state, connections, credentials, capabilities, and customer-facing experience. This keeps AI Lead Nurture reusable as a focused product inside the broader AI Apps platform.
Next product phase
The working automation is now ready to be connected to the broader self-service app lifecycle: public discovery, app entitlement, tenant provisioning, installation, onboarding, focused app access, and app-scoped assistant capabilities.
What this project demonstrates
This project demonstrates how an AI lead nurture workflow can evolve into a reusable platform product with durable state, reply-aware automation, duplicate-safe processing, calendar-backed appointment booking, provider abstractions, operational safeguards, and a clear separation between customer-facing app behavior and the underlying execution engine.
- State-driven automation architecture
- AI app product architecture
- Lead nurture lifecycle design
- Reply-aware workflow orchestration
- Deterministic idempotency
- Email provider abstraction
- Google Calendar integration
- Booking clarification design
- Partial-success error handling
- Platform-owned credential boundaries
- Prisma migration-history repair
- AI-assisted full-stack development
More work is being documented.