Joseph runs multiple businesses. At the point we started working on this, his inbox was a bottleneck for every one of them. Emails arrived unfiltered. Some got his attention immediately. Others sat until they became problems. There was no triage layer, no routing, no way for his team to handle anything without looping him in.
The explicit goal we defined was to remove 20 hours from his weekly workload. Email was the biggest single target. We mapped out roughly 50 automations that needed to be built. Not 50 complex workflows — mostly small, specific decisions. Does this email go to Asana? Does it route to a Slack channel? Does it trigger an NDA? Does it need a response template? Fifty of those small decisions, repeated daily across multiple inboxes, adds up to a lot of hours.
The architecture
The stack has two layers. n8n handles execution. Google Sheets holds the rules.
n8n is a self-hosted automation tool, comparable to Zapier or Make but with significantly more flexibility and a much lower cost ceiling. The per-usage cost runs around $20 a month. The developer retainer to maintain it costs more than the tool, but that's true of any automation platform — the software is cheap; the configuration is what takes time.
The Google Sheets layer is the part that makes this actually work in practice, not just in theory. Every routing rule, every threshold, every list of approved senders lives in a spreadsheet that any team member can open and edit. A non-technical admin can add a new email routing rule by adding a row to the sheet. They can disable an automation by changing a cell value. They never need to touch n8n directly.
This separation matters more than it sounds. I've seen automation systems where the rules are hardcoded into the workflows themselves. That approach creates a system where every change, however small, requires someone who can open the workflow editor and knows what they're doing. In practice, that means changes don't happen. The rules calcify. The automation that was built for the business six months ago keeps running for the business as it was six months ago.
When the rules live in a spreadsheet, the system stays current because it's easy to update. That's the whole argument.
What got built first
We prioritized by hours saved per automation, not by complexity.
The first set of automations covered billing email triage. Invoices and payment-related emails were being handled by Joseph directly. Each one required a decision: is this legitimate, does it need action, who should handle it. The automation routes these to an Asana task with the relevant details pre-filled. Joseph's team picks it up from there.
The second set covered deal flow. Drups is actively acquiring businesses, and inbound deal emails from brokers were getting buried. The automation now creates a deal pipeline entry when an email matches the broker pattern, with a date stamp so the pipeline doesn't go stale. Stale deal pipelines look like abandoned pipelines to investors. A single automation solved a problem that was affecting how the whole acquisition effort was being perceived.
The third set covered routing. Emails meant for specific departments, specific vendors, or specific team members now get relayed automatically with the right people CC'd. Joseph stops seeing the ones that aren't his.
NDA triggers came next. When a specific inquiry type comes in, the automation sends the standard NDA template without Joseph's involvement.
What "done" looks like
The target was 20 hours a week removed from Joseph's plate. Email triage alone accounts for an estimated 5 to 10 of those hours. That estimate is based on volume multiplied by handling time per email type, not a precise measurement, but it's directionally right.
Done doesn't mean fully automated. Some email categories will always need human judgment. The goal was never to automate everything — it was to automate the categories where the decision is always the same so that the human attention is available for the categories where it isn't.
The test for a working automation system is whether it can survive a team member leaving. With hardcoded rules, when the person who built the system leaves, the organization inherits a black box. Nobody wants to touch it. It slowly breaks as the business changes. With rules in a spreadsheet, the system is transparent enough that someone new can understand it in an afternoon and maintain it from day one.
That's what we built toward. The automations themselves are ordinary. The architecture is what makes them last.
