BPS Profit Strategies

The problem

Two problems, and the second is the one that scales. The sales argument depends on a number the visitor has to believe — what card processing is costing them today — and it has to survive scrutiny from an owner who has sat through a merchant-services pitch before. Behind that, an outbound business runs on work nobody wants to do twice: finding businesses that fit, checking whether they are worth approaching, writing the first message, remembering to follow up, and keeping the record straight when a lead becomes a client. Done by hand it caps at whatever one person can hold in their head. Done by a third-party platform, the list and the sending reputation accumulate in someone else's account.

Approach

1. 01

   Built the marketing site around the cost question the visitor is actually asking, with a savings estimate they can run themselves rather than a claim they have to accept, and appointment booking attached to the result.

2. 02

   Kept the compliance story explicit, since surcharge programmes only work if they are demonstrably compliant.

3. 03

   Modelled the operation as a pipeline with named gates — discovery, enrichment, scoring, contact — so a lead's state is a fact in the database rather than a memory.

4. 04

   Scoped every record to an organisation from the first migration, so the platform was a product with one tenant rather than one client's system that would later have to become a product.

5. 05

   Split the work across thirteen specialist agents rather than one general one: scouting, outreach, email writing, nurture, content, onboarding, client success, finance, and the error and code agents that keep the rest honest.

6. 06

   Put an orchestrator and a state machine in front of them, with approval gates on anything that reaches a human, so an agent proposes and a person releases.

7. 07

   Recorded every agent run, error and approval, so when the system does something surprising there is a trail rather than a shrug.

8. 08

   Kept Node.js owning business state and n8n owning execution, on separate subdomains, so the marketing domain is never coupled to the operations stack.

Outcome

The acquisition side of the business runs as a system rather than as somebody's morning. Leads move through named states, agents draft and a person approves, and every run is recorded. And because tenancy was in the schema from the beginning, what shipped is a product with a first customer rather than a bespoke build that would need tearing apart to serve a second one.

Key decisions

1. 01

   Thirteen narrow agents under an orchestrator

   Instead of: One general-purpose agent with a long prompt

   A narrow agent can be tested, replayed and replaced on its own. One large one fails in ways nobody can attribute, and every fix risks the behaviour that already worked.

2. 02

   Approval gates on anything that reaches a person

   Instead of: Letting the pipeline send on its own

   Outbound touching real merchants under a compliance-sensitive offer is the wrong place for full autonomy. Agents draft and queue; a human releases. It also means the audit trail answers who approved what, not just what was sent.

3. 03

   Node owns the state, n8n owns the execution

   Instead of: Running the business logic inside the workflow tool

   Workflow tools are good at running steps and bad at being a source of truth. Keeping Postgres authoritative means the pipeline can be rebuilt, replayed or moved without the business record moving with it.

4. 04

   Multi-tenant from the first migration

   Instead of: Building single-tenant for the first client and generalising later

   Retrofitting tenancy means touching every query, every index and every permission check in a system already carrying real customer data — the most expensive refactor in this kind of software. An organisation column on day one costs almost nothing and is the difference between a product and a bespoke build.

5. 05

   The client's own application rather than a sending platform

   Instead of: Configuring a third-party outreach tool

   On a rented platform the list, the sending reputation and the campaign history accumulate in someone else's account under their pricing and policy. For a business whose pipeline depends on outbound, that dependency gets more expensive to unwind the longer it runs.

In short

Why build a client their own outreach platform instead of using an existing one?

Because on a third-party platform the things that compound are not yours. The subscriber list, the sending reputation built up over months, the campaign history that tells you what actually worked — all of it lives in an account governed by someone else's pricing and policy changes. For a business whose pipeline depends on outbound, that is a real dependency, and it gets more expensive to unwind the longer it runs. Building it as the client's own system also lets the data model match how they actually segment merchants rather than how a generic platform assumes everyone does, and it is what makes agent automation possible at all: an agent can only act on state it can read, and rented platforms do not expose theirs.