Lead
Tracker.

01 / THE BUILDStart with the next conversation

A list of leads is easy to collect. Deciding who needs attention today is the more useful part.

Lead Tracker is an outreach-tool demonstration built around that question. Its Today queue surfaces next actions, while an eight-stage pipeline shows where each conversation stands. Lead details hold notes, scores and follow-up dates.

The published demo starts with 25 fictional leads, so it can be explored without entering real customer information. The interactive explanation below uses three separate fictional examples. It is not a capture of a real sales pipeline.

02 / THE BUILDA queue for today, a board for the bigger picture

The queue and the pipeline answer different questions. The queue focuses on what is due. The board keeps the broader set of conversations visible, from New through to Won or Lost.

Try selecting an example lead and changing its stage. Moving a due example to a terminal stage removes it from this illustration's Today queue; it remains visible in the full pipeline. The rule here is a small teaching example, not a reproduction of every filter in the original tool.

The original eight stage names are preserved. A stage describes the record; it does not prove that a call took place or that an email was sent. No contact action runs from this page.

03 / THE BUILDLocal first, with an optional way out

The application account describes localStorage as the primary store. Demo data and real data use separate keys, keeping the seeded examples apart from the working collection.

An optional Google Apps Script connection sends the lead collection to a Google Sheet. The user installs the provided script, deploys it, and configures the endpoint in the application. That adds a remote dependency; it is not part of the default browser-only experience.

The companion article follows the outbound saveAll request and the exact acknowledgement it expects. The existence of that request does not establish two-way synchronization or multi-user conflict handling.

04 / THE BUILDMy contribution

I designed and developed the interface and deployed the demonstration. The main design choice was to put the next action beside the broader pipeline, rather than present every record as an equally urgent item.

The small stack fits the documented single-user scope. React and TypeScript handle the interface, Tailwind CSS the presentation, and Google Apps Script provides the optional Sheets connection. A team-wide CRM with shared permissions would be a different brief.

05 / THE BUILDWhat remains to improve

The original write-up identifies three follow-ups. saveAll sends the full collection instead of a change set. A JSON export/import path would provide another way to move the data. And the main application component needs to be split into smaller board and queue components.

Those are unfinished items, not capabilities being claimed here. The working principle is modest: make the next action easy to find, keep the storage model understandable, and be explicit about what the optional sync adds.