How A Self-Running Sales Pipeline Was Built By Partnering With AI

Introduction

Part 3 of the series: "Building a Production EdTech Platform on Lovable"

In Part 2, chat and voice agents were capturing leads. This post covers what happens after that, when those leads hit the CRM and turn into a self-running pipeline.

Here's an unpopular opinion: a website doesn't close deals. A CRM does.

A beautiful landing page gets attention. But if lead data ends up in a spreadsheet, or worse, in someone's memory, the deal is already lost. The real revenue infrastructure is invisible: it's the system that captures, qualifies, enriches, and converts leads without anyone having to touch a keyboard.

That's what was built for Progression School. And the CRM chosen, Zoho CRM, turned out to be the perfect backbone for a fully automated pipeline.

The entire integration, webhooks, lead creation, identity resolution, lifecycle tracking, payment-to-deal conversion, and EMI tracking, was built through a partnership with Lovable.

• Not outsourced to a CRM consultant.
• Not delegated to an integration developer.

Built collaboratively, sharing business context, describing what should happen, and letting Lovable handle the API orchestration, webhook wiring, and error handling.

The founder's role was that of a domain expert and strategic partner; Lovable's role was that of a full-stack CRM engineer who never needed a Zoho API reference doc.

Building CRM Integrations With AI: The Partnership Model

CRM APIs are notoriously complex. Zoho CRM alone has separate endpoints for Leads, Contacts, Deals, Notes, and Accounts, each with different field schemas, validation rules, and error codes. Traditionally, this requires hiring a specialized CRM developer or spending weeks reading API documentation.

With Lovable, the workflow was fundamentally different. The founder shared business context, the student journey, the sales process, the enrollment workflow, and Lovable translated that into working integrations. The conversation never involved API endpoints or HTTP methods:

• ❌ "Make a POST request to /crm/v2/Leads with these 15 fields in the request body."
  
  
• ✅ "When a student fills the brochure form, create a lead in Zoho with their details, classify the interaction as 'Downloaded Brochure', and append it to their lifecycle trail."

Lovable handled the OAuth token refresh, field mapping, error recovery, and the peculiar quirks of Zoho's API (like how DUPLICATE_DATA errors return the existing record ID in a nested array), all without being explicitly told about these mechanics.

The iterative partnership was the key. The first version of the lead creation function worked for happy-path submissions. Then edge cases surfaced one by one: returning users, duplicate accounts, missing emails, parent payment methods, and each was fixed through a new conversation turn.

The founder brought the "what" and "why"; Lovable brought the "how." Over dozens of iterations, what started as a simple form-to-lead pipeline evolved into a comprehensive identity-resolution system. At no point did the founder need to read Zoho's API documentation, configure webhook endpoints manually, or debug HTTP response codes.

The Architecture: One Contact, Many Interactions

The fundamental design principle is that every person gets one master Contact record in Zoho CRM, no matter how many times they interact with the platform.

A student might:

1. Download a brochure (Tuesday)
2. Chat with the AI assistant (Wednesday)
3. Register for a free workshop (Thursday)
4. Apply for a paid program (Friday)
5. Pay and enroll (Saturday)

Each of those is a different interaction, but it's the same person. The system needs to know that, and build a complete picture.

This architecture decision was made by the founder. The implementation, the deduplication logic, the identity graph, and the field seeding were entirely Lovable's work, built from a simple description of the desired behavior.

Layer 1: Form Submission → Lead Creation

Every form on the site: brochure downloads, consultation requests, workshop registrations, program applications, submits data through a Zoho embedded form (iframe). When the form completes, a backend edge function fires, doing much more than just "create a lead."

Lovable built and managed the entire webhook infrastructure. The edge functions that listen for form submissions, the routing logic that determines what type of interaction it is, the CRM API calls that create and update records, all of it was generated and iterated through conversation. The founder never engineered a webhook configuration panel or wrote a line of serverless function code.

Smart Classification

The system reads the form's hidden utm_form field and classifies the interaction:

This isn't just metadata; it drives everything downstream: email automations, sales follow-ups, and conversion tracking.

How This Was Built

The founder described the classification rules in plain English: "Parse the utm_form field. If it contains 'Brochure', the lifecycle stage is 'Downloaded Brochure'. If it contains 'Application', the stage is 'Enrolled for [Program]'."

Lovable generated the keyword-matching logic and the mapping table, and wired them into the edge function. When new form types were added later (workshops, consultations), extending the classifier was a single conversation turn, share the new rule, and Lovable updated the function.

The Lifecycle Trail

Every interaction appends to a single CRM field called Lifecycle_Trail:

Downloaded Async AI Brochure > Applied for Zero-to-AI Product Bootcamp > Paid for Zero-to-AI Product Bootcamp

This field is the single source of truth for a lead's entire journey. Zoho Workflow Rules use CONTAINS conditions on this field to trigger automated emails, task assignments, and stage transitions.

Layer 2: Identity Resolution, The "Returning User" Problem

Here's the scenario every CRM dreads: a student downloads the Async AI brochure in January, then applies for the Bootcamp in March. Are they a new lead? An existing contact? Both?

The Solution

When a form submission comes in, the backend:

1. Searches for an existing Contact by email
2. If found, pulls their full profile, college, degree, year, stream, city, role, company, experience, LinkedIn
3. Creates a new Lead but seeds it with all that existing profile data
4. Logs the new interaction as a timestamped Note on both the Lead and the Contact

The result: the sales team sees a new Lead (because it's a new interaction worth following up on), but the Lead already has complete context. No one asks, "So what's your college name again?"

Fields That Get Seeded

As an example, for a prospective lead from IIT Guwahati, the following field will get seeded into the CRM

The partnership in action: This was one of the more complex conversations with Lovable, and a perfect example of how the collaboration worked. The founder explained the business problem: "Returning students shouldn't feel like strangers. When they interact again, their profile should carry forward."

Lovable asked clarifying questions about which fields mattered, then generated the search-then-seed logic across the Zoho Contact and Lead APIs. Then, the founder's job was to define the 10 profile fields to copy and explain why each mattered for the sales team.

Lovable handled the API orchestration, searching Contacts, mapping fields between modules, handling null values, and creating the Lead with pre-populated data. The entire identity resolution system was built without the founder ever seeing a Zoho API endpoint.

Layer 3: Payment → Contact Conversion + Deal Creation

This is where the CRM magic really happens. When Razorpay confirms a successful payment (via webhook), the backend orchestrates a multi-step process:

Step 1: Convert Lead → Contact

The Lead record transforms into a Contact. Zoho's conversion API handles this, carrying over all fields and Notes.

Step 2: Create a Deal

A Deal is created with:

• Deal Name: [Student Name] - [Program Name]
• Amount: Payment amount
• Stage: "Closed Won"
• Payment Fields: Synced from Razorpay

Step 3: Track EMI Progress (For Subscription Payments)

For students on monthly EMI plans, each installment triggers an update:

The Payment_Status only flips to "Completed" on the final installment. This lets the sales team instantly see who's mid-plan and who's fully paid.

Step 4: Update Lifecycle

The Lifecycle_Stage updates to Paid for [Program] and the trail appends accordingly.

How Lovable Managed The Entire Webhook Chain

Payment-to-CRM sync involves orchestrating three different APIs (Razorpay webhooks, Zoho CRM, and Thinkific enrollment) in a single edge function. The founder described the business flow: "When payment succeeds, find the lead in Zoho, convert them to a contact, create a deal with payment details, and enroll them in Thinkific courses."

Lovable produced a 200+ line edge function handling the entire chain, including Razorpay signature verification using the Web Crypto API, Zoho OAuth token refresh, Deal field mapping, and Thinkific user creation with retry logic.

Lovable didn't just write the code; it managed the entire webhook architecture. It configured edge function routing, set up CORS headers, handled Deno runtime requirements, and ensured the function was idempotent.

The founder's contribution was the business logic: which fields map where, what "Closed Won" means, and how EMI tracking should work. Everything else, the infrastructure, was Lovable's domain.

Layer 4: The Edge Cases That Break Every CRM

Edge cases are where most CRM integrations fall apart. They're also where the Lovable partnership proved most valuable, because fixing edge cases in production traditionally requires a developer on call. Instead, the pattern was: observe the failure, describe it to Lovable, deploy the fix.

The Duplicate Account Problem

Zoho CRM creates an "Account" (company) when converting a Lead to a Contact. When two students from the same company (say, Infosys) both convert, the second conversion throws a DUPLICATE_DATA error because the Account "Infosys" already exists.

The Solution

The system catches this error, falls back to searching for the Contact by email, and retrieves the Contact ID directly. The conversion still succeeds, it just takes a different path.

How the partnership solved this: This edge case didn't surface during testing; it appeared in production when two students from the same company enrolled back-to-back. The Zoho API returned a cryptic error.

The team didn't need to decode the error code or read Zoho's documentation. They shared the error log with Lovable and said: "The Lead conversion is failing with DUPLICATE_DATA on the Account. We need to handle this by catching the error and looking up the Contact by email instead."

Lovable rewrote the conversion function with a try-catch fallback, understanding both the Zoho error structure and the recovery pattern. From bug report to deployed fix in one conversation: No Jira ticket, no sprint planning, no code review. Just context shared, fix generated, problem solved.

The Parent's Payment Method Problem

For subscription payments, a student might use their parent's payment method. The Razorpay payment object shows the parent's email on the payment instrument, but the student's email is in the subscription notes.

The Solution

For subscription.charged events, the system strictly uses the email stored in Razorpay subscription notes, not the payment instrument email. This prevents incorrect CRM attribution.

The team identified the business risk ("if a parent pays, the CRM will create a deal under the parent's name, not the student's"). Lovable identified the technical solution ("use the subscription notes email instead of the payment instrument email"). This is a partnership, domain expertise meets implementation expertise.

The Voice Call Without Email Problem

When someone calls the voice agent "Priya," they only provide a phone number. But Zoho needs an email for deduplication.

The Solution 

The system generates a placeholder email, voice-{8-char-ID}@voice-call.internal, ensuring the CRM record is created, and the transcript is logged without blocking on missing data.

The Partnership Pattern For Edge Cases

Each of these edge cases followed the same collaborative pattern:

1. Something breaks in production
2. The team identifies the business impact and describes the expected behavior
3. Lovable generates the technical fix, often anticipating related edge cases the founder hadn't considered
4. The fix is deployed immediately

This cycle, production observation → context sharing → AI-generated fix → deploy, became the standard operating model. The founder never needed to decode stack traces, read API documentation, or understand webhook retry semantics. They needed to understand their business and communicate clearly. Lovable was the engineering partner that turned business context into production code.

Layer 5: Automated Email Workflows

With clean data flowing into Zoho, automated emails become trivial:

Trigger: Brochure Download

• Workflow Rule: On Lead Create/Edit where Lifecycle_Trail CONTAINS "Downloaded [Program] Brochure"
• Action: Send program-specific brochure PDF via email
• The CONTAINS condition (not EQUALS) ensures it fires for returning users too

Trigger: Successful Payment

• Action: Consolidated HTML welcome email via Zoho Send Mail API
• Includes: Payment summary, course access links, and onboarding steps
• Thinkific's default welcome email is disabled; the platform controls the entire experience

Trigger: EMI Installment

• Action: Update email confirming payment received + courses unlocked for this tier

Even the email integration was Lovable's work. The Zoho Send Mail API requires specific headers, HTML formatting, and attachment handling. The founder described what the email should contain and when it should fire. Lovable built the Send Mail edge function, including HTML email templates with dynamic fields, PDF attachment handling, and conditional logic based on payment type (full vs. EMI).

What The Sales Team Actually Sees

When a sales rep opens a Contact in Zoho CRM, they see:

1. Complete profile, auto-populated from forms, never manually entered
2. Lifecycle Trail, full history: Downloaded Brochure > Attended Workshop > Applied > Paid
3. All Notes, every form submission, chat conversation, and voice call transcript, timestamped
4. Deal with payment status, real-time EMI tracking
5. Marketing automation status, which emails were sent, which sequences they're in

Zero manual data entry. Zero context switching. The CRM tells the complete story.

Every piece of data that populates this view flows through edge functions that Lovable built and manages. The founder designed the information architecture, including where data should appear and why. Lovable built the pipes that make it happen.

The Meta-Lesson: CRM Integration As A Partnership Problem

CRM integrations are traditionally one of the most painful parts of any tech stack. They involve:

• Complex, poorly documented APIs with inconsistent error handling
• Field mapping nightmares across different systems
• Idempotency challenges (what if the webhook fires twice?)
• Race conditions (what if two forms submit simultaneously?)
• OAuth token management with refresh flows
• Webhook signature verification

Building these integrations through a partnership with Lovable fundamentally changed the experience. The founder brought:

• Domain Expertise: Understanding the student journey, sales process, and enrollment workflow
• Business Rules: How leads should be classified, when deals should be created, and what EMI tracking means
• Quality Assurance: Testing real scenarios, catching edge cases in production, and describing unexpected behavior

Lovable brought:

• API Knowledge: Zoho CRM, Razorpay, and Thinkific API patterns, error codes, and quirks
• Infrastructure Management: Edge functions, webhook routing, CORS configuration, Deno runtime
• Engineering Patterns: Retry logic, idempotent operations, graceful fallbacks, error recovery
• Speed: What would take a CRM developer days was generated in minutes

This was a perfect example of AI becoming a development partner. The founder didn't abdicate technical decisions; they made architectural choices (one Contact per person, append-only lifecycle trails, cumulative EMI fields). But they never needed to translate those decisions into code themselves. They described the "what" and "why"; Lovable handled the "how."

The traditional approach to building this CRM pipeline would involve a CRM consultant ($150/hr), an integration developer ($100/hr), and weeks of back-and-forth. Instead, it was built over a few days in partnership with Lovable by someone whose primary skill is marketing, not engineering.

The Marketer's Takeaway

At three companies before this, the biggest CRM failure mode was always the same: people stopped updating the CRM. Salespeople skip fields, marketers forget to tag leads, and within six months, the data is useless.

The fix isn't better training or stricter processes. The fix is removing humans from the data entry loop entirely. Every field in this CRM is populated by code, not by people. The only thing the sales team does in Zoho is read and respond.

This transforms the CRM into an intelligence system. And it was built by partnering with an AI development platform, sharing context, iterating on edge cases, and treating Lovable not as a tool, but as an engineering teammate.

If your CRM is full of empty fields and stale data because updating it is someone's least favorite task, there's a better way. Talk to us about building a CRM pipeline that populates itself.