BccBuddy

Turning email into action

A service that runs sales workflows straight from your inbox.

An email with deal@ in the Bcc line, and the BccBuddy activity it triggers: the deal logged with its details, the CRM updated, a follow-up task and a confirmation — One Bcc does the work. Seconds after sending, the deal is logged, the CRM is updated and the follow-up is on the calendar.

The workflow behind deal@: extract the deal details, create or update the deal in the CRM, create a follow-up task and reply to the sender, with recent runs alongside — Behind each address is a workflow of steps. This is deal@, with its latest test and recent runs.

The problem

Salespeople live in their inbox, but their pipeline lives in a CRM. Every conversation that should become a deal, a task or a reminder has to be copied over by hand, and the ones that don't get copied are the ones that slip.

What I built

BccBuddy works from the Bcc line. Put an address like deal@ on an email and it logs the deal; task@ creates the follow-up; reminder@ sets the reminder. There's no other app to open; the email you were sending anyway does the work.

Behind each address is a workflow of steps, and steps can write to the tools a team already uses, such as a CRM. A browser extension brings the same actions into the inbox itself.

To test adoption, I ran it with about ten salespeople. Each used it every working day, sending around four emails a day through it, so roughly 200 emails a week ran through playbooks.

How it works

A Next.js app handles sign-in, settings and the workflows. Inbound email and the processing behind it run on AWS Lambda, and everything reads and writes one Postgres database. The product works in three flows:

Set up, in the web app. A salesperson builds a playbook from a library of steps, creates a trigger address such as deal@ and attaches it, and connects HubSpot, Salesforce or Google Calendar by signing in to each.
An email arrives. Intake hands it to the API, which finds the sender, or onboards them on first contact. It matches the sender and address to a trigger, loads that trigger's playbook, and runs it as a workflow. Each step calls the connected tools, and every step's state is recorded, which is what powers the history and analytics.
The extension. It signs in through the web app, syncs the salesperson's triggers, and uploads attachments that workflows can use.

The highlighted path follows a Bcc'd email from the salesperson to the CRM.

What was hard

Working across technical and non-technical people once LLMs made everyone fast. Velocity went through the roof. The models were good at building interfaces, and that was misleading, because an interface isn't the system. Screens were designed without regard for the shape of the backend. Data was stored in the browser on the assumption that it was saved. People shipped faster than they understood the system underneath, and managing that gap was the hard part.

What I learned

When anyone can produce a working screen, the hard part of software moves to the system behind it: how data is shaped, where it lives and what the product can actually trust. That lesson led me to Nano, and to thinking much more deeply about software engineering and how teams will work in these environments.