Build Log

Nebula Components Lead Workflow

This is a build log, not a case study. The system is newly instrumented and no results are claimed yet. The measurement plan is published here so the evidence pipeline is visible from the start.

Context

Nebula Components is an electronic components shop I operate. Visitors browse parts, check availability, and submit requests for quotes or technical questions.

Before automation, every request arrived as an email or form submission. Each one required manual triage: read it, decide what it needs, write a response, send it, and remember to follow up if there was no reply. The process worked, but it depended entirely on me checking the inbox at the right time.

Problem

Requests died in the inbox. Not because I ignored them, but because the inbox is not a workflow. A submission that arrives at 11pm gets buried under the next morning's email. A quote request that needs supplier confirmation sits in draft limbo. A follow-up that should go out in 48 hours depends on me remembering to send it.

The failure mode is silent: no error message, no alert. The visitor just never hears back, and I only notice when I stumble across the thread days later.

Build

The workflow has four steps, matching the process on the homepage:

  1. Capture: A form submission arrives via webhook. The system logs the request with timestamp, source form, and request type.
  2. Route: Automation classifies the request and moves it to the appropriate follow-up queue. Routing latency is logged.
  3. Review: I receive a notification with the request context. I can approve the suggested response, correct the route, or pause for manual handling. My decision is logged.
  4. Follow up: The agreed response goes to the visitor. The system records when it was sent and the total time from capture.

Tools used: n8n (workflow orchestration), Google Sheets (append-only log), SendGrid (email delivery), Slack (owner notifications).

Build time: ~4 hours for initial workflow, ~2 hours for instrumentation.

Checkpoint Design

The owner checkpoint sits between routing and follow-up. This is deliberate: the system handles the repetitive movement (capture, classify, queue), but the response decision stays with me.

Why not full automation? Because context matters. A quote request from a repeat customer might deserve a faster turnaround. A technical question might need me to check stock before answering. A request that looks automated might need to be filtered.

The checkpoint is not a bottleneck to remove later. It is the place where business judgment belongs. The automation's job is to make sure I see the request quickly, with enough context to decide, and that my decision is logged so the process is auditable.

Measurement Plan

The workflow logs these events to an append-only sheet:

Event Fields Purpose
request_captured timestamp, source_form, request_type Mark the moment a visitor submits a request
request_routed timestamp, route, latency_from_capture Track how quickly the system moves the request forward
owner_checkpoint timestamp, action (approve/correct/pause) Record when I review and what decision I make
followup_sent timestamp, latency_from_capture Confirm the visitor received a response
outcome timestamp, resolution_type Close the loop: what happened to this request

Why publish the measurement plan before results? Because observation is documentation. The evidence pipeline is the content strategy. When results exist, they will be traceable to this log, with calculation methods stated inline.

Results

Collecting since July 21, 2026

No performance numbers are claimed yet. Results will be published here as they accumulate, with dates and calculation methods. The threshold for publishing: 60+ days of collection, 30+ logged requests, 80%+ complete event chains.

What This Page Will Become

When the data thresholds are met, this build log converts to a numbered case study:

  • Volume handled (from request_captured count)
  • Response-time delta (from latency_from_capture fields)
  • Owner-intervention rate (from owner_checkpoint actions)
  • Hours saved (with stated calculation method)
  • A "limits" section: what the automation does NOT do, what stayed manual
  • A redacted screenshot of the live workflow and a log excerpt

Until then, this is a build log. The system is running, the evidence is accumulating, and the measurement plan is public.

Want a similar workflow?

The same approach works for any lead capture or request handling process.