Keep it small.A local collection.
An optional handoff.

01 / FIELD NOTESThe workflow comes before the storage choice

The Today queue narrows attention to follow-ups and next actions. The board gives the same work a longer view. The source describes lead details with notes, scores and next-action dates, rather than an elaborate team CRM.

The pipeline's eight stages are expressed as a union type:

status: 'New' | 'Contacted' | 'Followed up' | 'Replied' | 'Call booked' | 'Quoted' | 'Won' | 'Lost';

This defines the accepted values in the shown type. It does not, by itself, prove that every board column, filter or transition is generated from that declaration. Adding a stage still needs a check of the code that consumes it.

02 / FIELD NOTESBrowser persistence is a scope decision

The source stores the working collection in localStorage and keeps demo data under a separate key. That makes it possible to try the seeded board without overwriting the real collection described in the account.

Browser-local data can survive closing and reopening a page. It is not automatically a shared team database, a backup or a cross-device account. Browser policy and private browsing also affect persistence. Those platform details are clarified in the MDN localStorage reference; they are not new tests of Lead Tracker's storage handling.

For this tool, the optional Sheets connection is the way out of the local-only model.

03 / FIELD NOTESWhat the Sheets request actually sends

The application provides an Apps Script for the user to install in a Sheet and deploy as a web app. The resulting URL is configured in the tool. The published client excerpt sends the collection as a saveAll operation:

export async function syncLeadsToSheets(url: string, leads: Lead[]): Promise<boolean> {
  const response = await fetch(url, {
    method: 'POST',
    mode: 'cors',
    headers: {
      'Content-Type': 'text/plain', // Using text/plain to prevent pre-flight CORS blocks on simple Apps Script setups
    },
    body: JSON.stringify({
      action: 'saveAll',
      leads: leads,
    }),
  });

  if (!response.ok) {
    throw new Error(`Failed to save leads to sheet: ${response.statusText}`);
  }

  const result = await response.json();
  return result.status === 'success';
}

There are two separate checks. A non-successful HTTP response throws an error. After that, the parsed response must contain status: 'success' for the function to return true.

An HTTP response can therefore arrive without the application acknowledging the save. The local explanation below lets you inspect those cases without contacting Google or sending a lead.

{ action: 'saveAll',
  leads: [/* full example collection */] }

This is an outbound save operation. The excerpt does not show importing remote changes, resolving simultaneous edits, validating the endpoint's permissions, or recovering from an interrupted response. Calling it a complete synchronization protocol would go beyond the code shown.

04 / FIELD NOTESThe content type is only one part of the request

The body contains JSON, but the declared content type is text/plain. The comment explains the intent: avoid a preflight in a simple Apps Script setup.

text/plain is one of the CORS-safelisted content types when the other simple-request conditions are met. It does not bypass the response's CORS requirements or establish that a particular deployment is correctly configured. See MDN's CORS guide.

Google also documents that Content Service responses redirect to a one-time script.googleusercontent.com URL. The actual deployment and client still need to be tested together; the Content Service documentation describes that behavior. These are technical clarifications, not a claim that this preview connected to the original endpoint.

05 / FIELD NOTESThe next work is about keeping the tool manageable

The original account describes saveAll as rewriting the sheet on each sync. A change-based approach is a proposed improvement, not something the current excerpt implements.

The other two follow-ups are straightforward: add JSON export/import so the collection has another exit, and separate the main component into smaller board and queue pieces.

I would keep those tasks attached to the problem the tool solves. A useful next-action list does not need every CRM feature. It does need a clear answer to where its data lives, what a save acknowledgement means, and what happens when the optional connection fails.