Jeet documentation

A lead opens from a contact you already have, or straight from the conversation somebody is looking at in Wavy's inbox. Webhook ingestion for a web form, a marketplace listing, or a missed-call provider needs no credential of ours at all — a workspace generates its own per-source token and pastes the resulting URL into that provider's own settings. Every path in — WhatsApp, a webhook, or a merge — goes through the one lead-creation gate, so a repeat enquiry lands on the existing lead rather than duplicating it.

Needs: Reading a business's own email inbox for enquiries needs a mailbox credential (IMAP host, port, username and password), entered once via a connector — every other channel above already works with nothing configured.

Will not: Won't read an email inbox for enquiries until that mailbox credential is entered — the parsing and dedupe-safe lead creation behind it are already built and tested.

Enforced by a partial unique index in the schema, not application logic that a bug could route around: opening a second lead for a contact that already has one open is refused with a 409 naming the existing lead and its stage. Merging two contact records now reassigns the losing contact's leads onto the survivor — closed ones unconditionally — and refuses the whole merge, naming both lead ids, if both sides already have an open one, rather than silently combining two live opportunities.

Will not: Won't resurface a dedupe match marked 'ignored' on the next scan unless the group's own membership actually changes.

new → contacted → qualified → proposal → negotiation → won / lost. Every stage move — single or bulk — goes through the one function that assigns a lead's stage, so a required field has no route around it. A bulk move of up to 200 leads reports which ones were refused and why, and moves the rest rather than aborting the whole batch.

Will not: Won't let you add an eighth stage — the seven are fixed, so a stored automation or report can't reference a stage that later changes meaning.

Per-stage required fields and rot-days thresholds, enforced on every write path. Rotting ignores a future next-activity date — a meeting booked for next month still rots — and counts weekends, matching the one competitor whose behaviour users have already learned. A task-completed or inbound-reply rule now fires inline, in the same transaction as the event that triggers it; a stage-entered-days, score-at-least or quiet-days rule is evaluated by an on-demand scan. Rules are evaluated in creation order and at most one moves a lead per pass, with every other match recorded as skipped_conflicts; a rule cannot refire on the same lead within its own cooldown window.

Will not: Won't run on a fixed schedule of its own yet — the on-demand scan needs a person or a scheduler to call it, since there's no Celery beat entry for it in this wave.

0-100, arithmetic rather than a model — there isn't enough won/lost data yet to train one. Built-in components: replies (12 points each, capped at 48), stage (0-40), having a value set (+10), and staleness (-8 per week quiet past day 7, capped at -32). A workspace can add its own rules in three fixed weight buckets — highly positive +25, slightly positive +10, negative -10 — instead of picking an arbitrary number, and a preview endpoint runs a candidate rule set against a real lead before you save it.

Will not: Won't score from anything your business sent — only what the customer did.

A task is assigned to a person in this workspace, listed by today, overdue, or open — with unassigned tasks counted separately so nothing gets lost under a default owner. Completing one logs it to the lead's history and resets the rot clock. A due task now raises an in-app bell notification idempotently, and an overdue task escalates to the assignee's own team manager, looked up from real team membership rather than guessed — a rep in no team is reported by name rather than silently skipped.

Will not: Has no field that could hold a phone number, a channel, or a message template — a task cannot itself become an outbound message to a customer, only an in-app nudge to a colleague.

Loss reasons grouped and counted, win rate by source, owner and stage of exit, over any window up to ten years. Complete because a lost transition is refused without a reason, so the loss_reason column is populated on every row instead of being an optional dropdown nobody fills in.

A call_task or whatsapp step, when due, always becomes a task naming exactly what to say or do — a rep places the call or sends the WhatsApp message themselves. An email step may send directly, because Jeet draws no such boundary against email: a real, consent-gated, unsubscribe-capable send path degrades to a task instead of blocking when no email provider is configured, so the follow-up still happens on schedule as a human action either way. Enrollment refuses to schedule an email or WhatsApp step for a contact with no opted-in marketing consent, and an inbound reply pauses and cancels every remaining scheduled step for that lead immediately.

Needs: An email provider (ZeptoMail) for an email step to send directly — without one, that step becomes a task instead of failing silently.

Will not: Won't ever send a WhatsApp message or place a call itself — those steps always become a task for a rep, no matter what is connected.

The call log, a per-call webhook token a provider posts status updates back against, and consent-gated recording linkage — a recording cannot attach until a confirmed-consent row exists for that exact call — all work locally. A click always writes an attempt row even with no provider connected, so it is never silently lost.

Needs: An Indian cloud telephony connector (Exotel, Knowlarity or Ozonetel). Until one is connected, a click still logs honestly and reports dialed: false rather than pretending to dial.

Will not: Won't scrub a number against the TRAI DND registry — that's a distinct check from the opt-out flag Jeet already respects, and would need its own provider or compliance service.

Templates, the consent gate (Wavy's own marketing consent record, read and — via the unsubscribe link — written, so an unsubscribe here also stops a WhatsApp broadcast), and the self-hosted open-tracking pixel and click-redirect all work locally with no network call, and keep working regardless of what eventually sends the message.

Needs: An email-sending account (ZeptoMail) for actual delivery. Without it, a send records status: blocked_no_provider rather than pretending to have sent.

Will not: Won't send an email that a contact has not opted in to receive, even once a provider is connected.

Consent-gated recording linkage (shared with click-to-call), transcript storage and retrieval all work locally. Summarising a transcript you already have is a real, working call through the same LLM router every other AI-assisted route in this product uses — a workspace with a manual transcription process can paste text in and get a summary today with nothing else configured.

Needs: A speech-to-text service to turn a recording itself into a transcript — separate from an LLM key, and not configured on this deployment.

Will not: Won't transcribe a recording on its own without that speech-to-text service — pasting an existing transcript in and summarising it is the path that works today.

Quotes, line items and totals are recomputed server-side from the live catalogue on every write — a client-sent price for a catalogued line is always ignored. Editing a quote already sent never mutates it: the old row is marked superseded and a new version is created, so a link already in a customer's inbox keeps showing exactly what they were quoted. Sending a quote produces a real, unguessable share link rendering the quote as a self-contained HTML page.

Needs: A PDF-rendering library or service, which this deployment does not run. Until then, the share link is a real, working page — an HTML stand-in, not a placeholder that fails.

Will not: Won't generate a downloadable PDF file yet — the share link is what a customer actually receives today.

Booking links, weekly availability rules with a per-rule IANA timezone — so a booking never silently shifts an hour across a DST transition — and conflict prevention against every meeting Jeet itself knows about all work locally, including the unauthenticated public booking page a prospect uses to book.

Needs: A Google Calendar or Microsoft Outlook connection. Without it, a meeting booked anywhere outside Jeet is invisible here and can double-book.

Will not: Won't see a rep's real calendar until that connection exists — a meeting booked in Google Calendar directly is invisible to this booking link today.

No third party involved. Weighted, best-case and committed value are computed live from open leads against configurable per-stage probabilities, grouped by currency — a mixed-currency pipeline reports null with a by_currency breakdown rather than a blended figure. Confidence is reported as low below 5 closed deals in the trailing 90 days and medium below 20, each with a stated reason, rather than a number delivered with uniform confidence regardless of how little history backs it.

Will not: Won't state a number with high confidence on a brand-new workspace — a thin closed-deal history is named as the reason, not smoothed over.

No third party involved. Visibility is enforced, not just documented: a rep sees only their own numbers, a team's manager sees their team's, and owner/admin see anyone's, checked against real team membership rather than a client-supplied claim. Activity is reported as two separate classes — verified_activity (stage moves and calls from the append-only history) and self_reported_activity (task completions, which a rep can mark done without having made the call) — rather than one blended score.

Will not: Won't blend a rep's self-reported task completions into the same number as verified stage moves and calls — the two stay visibly separate.

No third party involved. Every strategy respects a rep's own capacity setting — a rep at their max open leads, or not accepting new ones, is skipped, and if every target rep in a matching rule is at capacity the lead is left unassigned with a stated reason rather than overloading whoever is first. A deactivated rep is simply skipped in a bounded, single pass, so rotation cannot loop. Assignment reuses the same auditable event history a manual assignment already writes to.

Will not: Won't overload a rep past their own configured capacity, even when every other rep in a rule is also full — the lead is left unassigned instead.

No third party needed for the core outcome. Every imported row goes through the same lead-creation gate manual and webhook lead creation use, so a large CSV cannot mass-create duplicate contacts the way a bespoke bulk path would — a row whose contact already has an open lead is counted skipped, not an error. Imports are capped rather than silently truncated, and a malformed row is recorded with its number and reason rather than aborting the whole batch. An export never returns a bare CSV inline: content is served through an unguessable, time-limited link, and no file ever touches local disk.

Will not: Won't mass-create a duplicate contact from a large import — a row whose contact already has an open lead is skipped and counted, not silently duplicated.

Open leads grouped by stage, best score first within each column. Terminal stages are returned too, empty, so a client can render every column without guessing the shape.

{
  "stages": ["new","contacted","qualified","proposal","negotiation","won","lost"],
  "columns": {
    "new": [ { "id": "…", "title": "2BHK enquiry — Kandivali", "stage": "new", "score": 10, "...": "..." } ],
    "contacted": [], "qualified": [], "proposal": [], "negotiation": [], "won": [], "lost": []
  },
  "open_total": 1
}

Open a lead against a contact you already have. Refuses a second open lead for the same contact.

{
  "contact_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "title": "2BHK enquiry — Kandivali",
  "source": "manual",
  "value_minor": 4500000,
  "currency": "INR"
}

{
  "id": "c5e1a9f0-1a2b-4c3d-8e9f-0a1b2c3d4e5f",
  "contact_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "contact_name": "Rahul Mehta",
  "contact_phone": "+919876543210",
  "title": "2BHK enquiry — Kandivali",
  "source": "manual",
  "stage": "new",
  "value_minor": 4500000,
  "currency": "INR",
  "owner_user_id": null,
  "score": 10,
  "score_reasons": ["No reply from them yet", "Not contacted yet", "Has a value (+10)"],
  "is_open": true,
  "lost_reason": null,
  "last_activity_at": "2026-08-16T10:02:00Z",
  "created_at": "2026-08-16T10:02:00Z"
}

The refusal: a second open lead for a contact that already has one.

{ "contact_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "title": "Same customer again" }

// 409
{
  "message": "This contact already has an open lead.",
  "lead_id": "c5e1a9f0-1a2b-4c3d-8e9f-0a1b2c3d4e5f",
  "stage": "new"
}

Open a lead straight from the conversation someone is looking at in Wavy's inbox. Source is read from the conversation's channel, not accepted from the caller.

{ "title": "Asked about pricing on WhatsApp", "value_minor": null }

{ "id": "…", "source": "whatsapp", "stage": "new", "score": 0, "score_reasons": ["No reply from them yet", "Not contacted yet", "No value set"], "...": "..." }

List leads, optionally filtered by stage (?stage=qualified) and whether to include closed ones (?include_closed=true).

One lead plus its full append-only event history, oldest first.

Edit title, value_minor, or owner_user_id.

Add a note. Deliberately does not touch last_activity_at — that field means the customer did something, and a lead has to be able to go quiet even while the salesperson keeps typing about it.

Move one lead. lost_reason is required when stage is 'lost', regardless of any configured stage rule.

{ "stage": "proposal" }

// 400 — this stage rule requires owner_user_id before entry
{
  "message": "proposal needs these filled in first: owner_user_id.",
  "stage": "proposal",
  "missing_fields": ["owner_user_id"]
}

The other hard-coded refusal: losing without saying why.

{ "stage": "lost" }

// 400
"Say why it was lost — it cannot be reconstructed later."

Move up to 200 leads through the identical single-move gate. Nothing is committed until every lead has been considered; refusals are reported per lead rather than aborting the batch.

{ "lead_ids": ["c5e1a9f0-…", "9b2e7a11-…"], "stage": "qualified" }

{
  "stage": "qualified",
  "moved": [ { "id": "c5e1a9f0-…", "stage": "qualified", "...": "..." } ],
  "moved_count": 1,
  "refused": [ { "lead_id": "9b2e7a11-…", "reason": "qualified needs these filled in first: contact_phone.", "missing_fields": ["contact_phone"] } ],
  "refused_count": 1
}

Counts and open value per stage, and the open value per currency. Leads with no value set are counted separately rather than folded into the total as zero, which would understate the pipeline. Amounts in different currencies are never added: value_minor is stated beside the currency it is in, and is null with a stated reason where the pipeline holds several.

Record one message against a contact. Only an inbound message moves last_activity_at; an outbound one never does. A contact with no open lead returns matched:false and writes nothing. external_ref makes a repeat delivery idempotent.

{ "contact_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "direction": "inbound", "external_ref": "wamid.HBg…", "preview": "Is the 2BHK still available?" }

{
  "matched": true,
  "lead_id": "c5e1a9f0-…",
  "duplicate": false,
  "direction": "inbound",
  "score": 22,
  "score_reasons": ["1 reply from them in the last 90 days (+12)", "Not contacted yet", "Has a value (+10)"]
}

The current score, its reasons, and each component broken out (built_in vs rule) so an interface can show which parts of a disagreement an admin can actually change.

This workspace's own rules, plus the seven field options and the three weight buckets with their points.

Add one criterion in a fixed weight bucket — highly_positive (+25), slightly_positive (+10), or negative (-10).

{ "field": "replies_at_least", "weight": "highly_positive", "label": "Replied at least twice", "threshold": 2 }

{ "id": "…", "label": "Replied at least twice", "field": "replies_at_least", "weight": "highly_positive", "points": 25, "is_active": true, "...": "..." }

Remove a rule.

The workspace's engagement window (default 90 days) plus the allowed range, 1-366.

Set how far back a reply still counts. Refused above 366 days, not clamped — a window longer than a year is a lifetime total wearing a disguise.

Run a candidate rule set — or, with an empty list, the stored rules — against a real lead and see each criterion's contribution. Writes nothing.

{ "lead_id": "c5e1a9f0-…", "rules": [ { "field": "quiet_days_at_least", "weight": "negative", "threshold": 21 } ] }

{
  "lead_id": "c5e1a9f0-…",
  "score": 12,
  "stored_score": 22,
  "using_stored_rules": false,
  "engagement_window_days": 90,
  "components": [
    { "label": "1 reply from them in the last 90 days (+12)", "points": 12, "source": "built_in" },
    { "label": "Not contacted yet", "points": 0, "source": "built_in" },
    { "label": "Has a value (+10)", "points": 10, "source": "built_in" }
  ]
}

Every stage's rot_days and required_fields, plus the requirable-field vocabulary and how rotting is computed (counts weekends, ignores a future next-activity date, resets on any lead event or a completed task).

Set the rot threshold and mandatory fields for one stage. Field names are validated against a closed vocabulary — a rule naming a column that doesn't exist would be a gate that silently never fires.

{ "rot_days": 7, "required_fields": ["owner_user_id", "value_minor"] }

{ "stage": "proposal", "rot_days": 7, "required_fields": ["owner_user_id", "value_minor"] }

Open leads stale longer than their stage allows, worst first, plus which stages have no threshold set at all.

{
  "items": [ { "id": "…", "stage": "proposal", "rot": { "days_since_touch": 11, "rot_days": 7, "reason": "Nothing has happened for 11 days, and proposal rots after 7." }, "...": "..." } ],
  "total": 1,
  "stages_without_a_threshold": ["new", "contacted"]
}

A follow-up owed on a lead, assigned to someone in this workspace. No field can hold a customer address.

{ "lead_id": "c5e1a9f0-…", "title": "Call back about financing", "due_at": "2026-08-18T11:00:00Z", "type": "call", "assignee_user_id": "user_772" }

{ "id": "…", "lead_id": "c5e1a9f0-…", "assignee_user_id": "user_772", "type": "call", "title": "Call back about financing", "due_at": "2026-08-18T11:00:00Z", "status": "open", "completed_at": null, "...": "..." }

Filter by ?assignee=, ?lead_id=, and ?due= (today, overdue, open, or all). Unassigned tasks are counted separately so nothing gets missed under a default owner.

Mark done and log it to the lead's history — completing a task is one of the things that resets the rot clock.

Loss reasons, win rate by source/owner/stage-of-exit, over a window of 1-3650 days. win_rate is a fraction of closed deals only — open leads are not counted as losses that haven't happened yet. value_won_minor carries its currency and is null, with a reason, where the won deals are priced in more than one.

{
  "window_days": 90,
  "closed": 14,
  "won": 6,
  "lost": 8,
  "win_rate": 0.429,
  "loss_reasons": [ { "reason": "Went with a cheaper competitor", "count": 5 }, { "reason": "Went quiet", "count": 3 } ],
  "by_source": { "whatsapp": { "won": 5, "lost": 4, "win_rate": 0.556 }, "manual": { "won": 1, "lost": 4, "win_rate": 0.2 } },
  "by_owner": { "user_772": { "won": 4, "lost": 3, "win_rate": 0.571 } },
  "by_stage_of_exit": { "negotiation": { "won": 4, "lost": 2, "win_rate": 0.667 }, "proposal": { "won": 2, "lost": 6, "win_rate": 0.25 } },
  "value_won_minor": 18500000,
  "value_won_currency": "INR",
  "value_won_by_currency": [ { "currency": "INR", "value_minor": 18500000 } ],
  "value_won_undefined_because": null,
  "won_without_a_value": 1
}

Run one due sequence step. A call_task or whatsapp step always becomes a task; an email step sends directly only when a contact has opted in and a provider is configured — otherwise it degrades to a task rather than failing silently. channel == email is the only case that ever calls the real send path; call_task and whatsapp always produce {"kind": "task_created"}.

// email step, no provider configured
{ "id": "…", "status": "scheduled", "outcome": { "kind": "task_created_no_provider", "email_message_id": "…" } }

Click to call a lead. Always logs a real attempt row, whether or not a telephony provider is connected.

{ "lead_id": "c5e1a9f0-…" }

// no telephony connector configured
{
  "call": { "id": "…", "status": "failed", "provider": "", "...": "..." },
  "dialed": false,
  "reason": "No telephony provider is connected for this workspace. Configure an Exotel, Knowlarity or Ozonetel connector before dialling."
}

Send an email to a lead's contact directly, or record exactly why not. Never raises for a business-rule refusal — only for a genuine input error. A contact with no opted-in consent gets status: blocked_consent instead — the same refusal either way: never a silent send.

{ "lead_id": "c5e1a9f0-…", "subject": "Following up on the 2BHK", "body_html": "<p>…</p>" }

// no email provider configured on this deployment
{ "id": "…", "status": "blocked_no_provider", "to_email": "rahul@example.com", "...": "..." }

Mark a quote sent and produce its share link. This route itself never emails or messages anyone — it hands back a link a rep sends however they choose.

{ "id": "…", "status": "sent", "share_token": "kX9f…", "share_url": "/api/v1/agents/jeet/quotes/share/kX9f…", "...": "..." }