RevenuePilot — Revenue Operations Web Application

The problem

Leads were lost between marketing and revenue. Advertising platforms report clicks, the CRM tracks deals and messaging conversations live in separate tools, so no one could say which campaigns produced customers, which opportunities were going cold, or where revenue was leaking.

Marketing spend was measured in clicks rather than customers, and there was no single view of a customer across channels.

Product objective

Build one operating system that carries a lead from first capture to recorded, attributed revenue — normalising every channel into the same pipeline and telling the team what to do next, with evidence.

• Every lead keeps its acquisition source, so spend can be traced to revenue.
• Qualification and scoring are explainable, so 'hot' and 'cold' mean something specific.
• Revenue is recorded independently of deal status, so a closed deal is not the only thing that counts.
• The product is channel-agnostic — not locked to a single messaging app.

Users & use cases

RevenuePilot is designed for B2B teams who sell through more than one channel and need marketing and sales to work from the same record.

• Marketing teams comparing spend against qualified leads, customers and revenue per campaign.
• Sales representatives working a prioritised pipeline with SLA-based follow-up instead of an unranked list.
• Revenue operations owners maintaining qualification rules, attribution models and automations.
• Owners and administrators managing team access, security posture and subscription usage.

Product architecture

The product is a pnpm monorepo: a Next.js application plus shared internal packages for the database layer, event handling, permissions, shared types, UI and observability. Marketing pages, the authenticated application and an internal platform console are separate route groups on the same deployment.

A versioned REST surface under /api/v1 backs the console, organisation management, security, mail campaigns and tracking. Webhooks, connector callbacks and support tickets each have their own API routes, and inbound payloads are validated with idempotency keys and replay protection.

• Supabase provides PostgreSQL with row-level security on every tenant table; a dedicated migrations history covers identity and RBAC, RLS policies, the audit log, contacts and leads, contact merging, pipeline and deals, revenue events, the risk engine, analyst evidence, business intelligence, the qualification engine and lead scoring.
• A unified inbox brings email, WhatsApp, web chat, SMS and social conversations into one workspace alongside customer context, qualification state and AI summaries.
• Automations use When/If/Then rules for follow-up, assignment, tagging, stage changes and notifications, with human approval required for material actions.
• The AI Growth Analyst answers questions against recorded performance and is required to return an explicit 'not enough data' rather than inventing a number.

Key features

• Normalised lead captureWebsite forms, webhooks, manual entry, CSV and advertising sources land in one lead pipeline, and every lead keeps its acquisition source so attribution survives the first touch.
• Unified inboxEmail, WhatsApp, web chat, SMS and social conversations sit in one workspace with customer context, qualification state and AI summaries beside them.
• Explainable qualification & scoringConfigurable qualification schemas and transparent lead scoring replace subjective 'hot and cold' labels with a defensible next action.
• Revenue recorded independently of deal statusRevenue events are stored separately from pipeline stage, with first- and last-touch attribution back to the acquisition source — so performance is measurable even when deals stall.
• Risk engine and rescue signalsA deterministic risk engine surfaces deadlines and revenue leaks, turning neglected follow-up into an alert with a recommended action rather than silent decay.
• Controlled AI with an audit trailAgents act through authorised, organisation-scoped tools, and human, AI, automation and integration actions are all recorded with before/after state and correlation IDs.

Interface

revenuepilot-new.vercel.app

revenuepilot-new.vercel.app

Development approach

The build started from the business problem rather than a feature list: define the revenue loop first, then let each screen answer to a step in it.

• Database-first. The schema and its row-level security policies were designed before the interface, so isolation is enforced by the database instead of by filtering in the browser.
• Capabilities instead of scattered checks. Roles grant capabilities, and every route, RPC and workflow action re-checks them server-side.
• A monorepo with shared packages keeps the database client, event contracts, permission model and UI primitives in one place across the app, console and site.
• Security checks sit in the release gate: tenant-isolation, RLS, authorization and webhook-replay tests must pass before a feature ships.
• Truthful states throughout — connectors report real health, and the analyst returns 'not enough data' rather than a fabricated figure.

Challenges & decisions

A revenue product fails quietly when the numbers cannot be trusted, so the hard requirements were traceability and isolation rather than surface polish.

• Frontend filtering is never treated as authorization — every tenant table carries row-level security enforced server-side and in AI tool authorization.
• Service-role keys, OAuth secrets and provider tokens stay server-side and never reach browser code.
• The AI analyst is required to answer 'not enough data' when evidence is missing, so decision support never invents a metric.
• Material AI actions require human approval, keeping consequential work with a person.