Internal product · Sales operations
A role-aware operating system for a small sales and delivery team.
LeadFlow turns a prospect pipeline into an explicit operating process: ingest leads, qualify them, trigger production, record sales activity, manage invoices and payment follow-up, then hand completed work back for delivery—with ownership and valid next steps encoded into the software.
01 · Problem
The real coordination problem was not “where are the leads?”
It was knowing which opportunities were worth pursuing, who owned the next action, what had already happened and which steps were allowed to happen next. A spreadsheet could store the businesses, but it could not reliably enforce the operating process between two roles.
Responsibility changes by stage
Research, production, calling, invoicing, payment follow-up and handover belong to different people at different moments.
Some steps require earlier proof
An invoice should not be “sent” before one exists. Handover should not begin before payment. Completion should not skip delivery.
Context must survive handoffs
Qualification evidence, website preview, call history, price, invoice and follow-ups need to remain attached to one business record.
02 · Lifecycle
The status is not a label. It is an instruction about what happens next.
LeadFlow models the journey with 17 explicit stages—from New lead through qualification, production, sales, finance, payment and handover to Completed or a closed path.
Interactive lifecycle
Follow a lead through the operating system
Lifecycle principle
The system should make the next valid action obvious and block shortcuts that create operational ambiguity.
03 · Guardrails
The system prevents several classes of operational mistake.
Role permissions and transition rules live in the backend. They are not just UI conventions that a user can bypass by clicking differently.
Evidence before production
A new lead must pass the qualification workflow—including a valid research link—before it can create a website request.
Owner-only stages
Production, invoice-ready, payment confirmation, handover and completion can be restricted to the appropriate role.
No impossible transitions
An invoice cannot be marked sent before it is ready; payment follow-up starts after sending; handover requires Paid; completion requires Handover.
Meaningful changes persist
Creation, qualification, stage changes, calls and invoice events are recorded so the record explains how it reached its current state.
04 · Automation
The product removes coordination work, not just typing.
Flexible CSV import + dedupe
A custom importer accepts multiple common column names, handles quoted CSV, skips duplicate business/city or source records and reports progress during large imports.
Qualification → production
Approving a lead automatically creates a website-production request instead of requiring a separate message or checklist.
Hourly batched digest
Pending website requests are claimed into country-specific batches and sent as one digest, with explicit pending/sending/sent/failed states and retry handling.
Outcome drives next state
Calls store summary, optional transcript, price and follow-up. Certain outcomes require a date so “follow up” cannot become a dead-end status.
Validated invoice storage
Uploads are restricted by role, file size and actual PDF/PNG/JPEG file signatures before being stored and linked to the correct business.
Issues live inside the tool
Collaborators can file bugs or feature requests with urgency and context; owner notifications and status tracking keep product iteration connected to usage.
05 · Product surface
One business record carries the operational history from prospect to handover.
The visualization below is synthetic. The real workspace contains collaborator identity, live prospects, calls, documents and commercial records and is intentionally private.
06 · My role
I designed the operating model and then encoded it into software.
LeadFlow began from my own need to identify and qualify website prospects, then expanded into a shared system as another person became responsible for research and sales. I defined the lifecycle, ownership boundaries, data model, stage rules and automation, then built the interfaces and backend logic around how the collaboration actually works.
Operations → software translation
Taking an informal collaboration process and making ownership, dependencies, allowed transitions and supporting information explicit.
Internal-product ownership
Building the workflow plus the less glamorous pieces that make internal software reliable: permissions, validation, history, notifications, documentation and feedback.