Sales & GTM Automation

The outbound sales operation of JSS Software Automations, my one-person company: rebuilt end to end and running headless on a Mac mini. It generates its own leads, works them over email and a call list, and improves itself on a measured cadence. Nothing reaches a person without my written yes in Slack.

The problem

Language models write passable cold email. That was never the hard part. The hard part is operation: an autonomous system acting daily against a finite market where the worst mistakes cannot be taken back. My market is owner-run screen-printing shops, and each will ever receive at most three emails from me. A hallucinated price, a message to someone who asked to be left alone, or an invisible double-send is not a bug to patch next sprint. It is a prospect destroyed in a market too small to regrow. Everything below follows from that.

How it works

1 · Signal generation

Two sources feed the pipeline. A paid shop directory supplies the known universe of shops, refreshed nightly by one crawler. A second sweep finds pain on its own: hiring posts, owner forums, shop-site changes. Channels that proved unreachable or empty for this market were deliberately left unwired.

2 · One lead database

Every lead is one row carrying its full history: emails sent, stage, calls, notes. New shops are qualified against the customer profile by website, email and phone, then bucketed by quoter status: no quoter at all, quoting by hand, or running an auto-quoter worth improving on. Fails are logged as disqualified and rechecked quarterly, and the database is backed up to git nightly.

3 · Outreach

A fixed sequence: the approved cold template, a follow-up if the shop stays cold, a third and final email, then the phone: a daily call list I work myself. The bucket is re-confirmed against the live shop site before every send, the stage sits on the row where I can always see it, and a reply at any point stops the sequence. Three touches per shop, ever, with suppression and the never-contact list checked in code on every send. Volume is a ceiling, not a target, and it scales by adding mailboxes, never by pushing one harder.

4 · Follow-up

A negative reply removes the shop from all future email, silently: I never see it. A question gets a reply drafted on the spot and sent on my yes. Interest sends the booking request, two slots plus a link. No response to either lands on the call list and stays pinned until resolved. A booked meeting is confirmed the morning of, held on the Meet with the demo live, and closed or lost with the reason logged.

5 · Slack, the only surface that reaches me

At the top of every month the desk posts the cold and follow-up templates for my yes; once approved, the sends run. Every client reply, question or booking crosses the gate before anything sends. My phone gets pushed only for a reply, a booking, a breakage, or a hot lead going stale; the daily call list and the weekly scorecard arrive on schedule, and negatives never ping me.

6 · Self-improvement

Weekly, the desk reports how it performed, with suggestions. Verdicts come from fixed-size send waves measured against tripwires registered before the wave starts, so the system cannot grade itself kindly after the fact. Research fires on events only: a tripped wire, the monthly source scan, the quarterly re-read of the customer profile. My edits to its drafts are mined monthly, so the drafting learns my voice. Once a month we set strategy together: cost per held meeting steers channels, the profile and the offer. Price and the offer never move on the system’s own judgment. All of it runs headless on a Mac mini under launchd, with an external watchdog that pushes my phone if anything dies.

What a yes actually is

Human in the loop is usually an undefined pause: no semantics for what counts as approval, where it may be given, whether an edit is one, or what silence means. Every clause below was forced in by a real incident during the first version’s operation, and the rebuilt gate runs the same contract.

Where it came from

The first version ran daily against real prospects, a scheduler working one shared state file. Its real numbers, its incidents, and the operating rules they forced are the subject of the report below. What survived here is everything that worked, rebuilt on a database instead of a shared file and a service instead of a scheduler.