Process automation and system integration for B2B

Integrations and automation

Six areas where I connect systems.

Invoicing and settlement

Deals that turn into invoices without anybody retyping line items, and payment status coming back to the record the sales team looks at. Which system owns the amount is decided first, because the CRM is often not it.

Online sales and marketplaces

Orders, customers and stock moving between a shop, a marketplace and the CRM. Orders arriving as closed-won deals fill a pipeline with noise, so order flow and sales flow get separated deliberately.

See the Magento integration

Payments and subscriptions

Payment links, subscription status and renewal dates on the record, so a renewal is a dated event rather than something somebody remembers.

See the Stripe integration

Company and registry data

Company records filled from an official registry by tax number rather than typed in by hand. Matching companies by email domain is a reliable way to end up with hundreds of contacts under one invented company.

Integrations written to order

When a system advertises an integration that turns out to be a cookie script, or has an API and no connector, the connection gets written. Webhooks, queues, retries and a log you can read.

See custom API integrations

Process, document and deadline automation

Approvals, documents generated from records, signature flows and deadline-driven tasks. The part people feel first is usually the deadline that no longer depends on memory.

Integrations and automation

Four layers, all chosen around one process.

No-code layer

Native first

If the platform does it natively, that is what gets used. Building what a portal already has is the most expensive kind of custom work, because somebody has to maintain it afterwards.

Code layer

Configuration and workflows

Next comes what can be configured: workflows, properties, associations, programmable actions. This layer covers more than most people expect, and it survives platform updates.

Data layer

Code where configuration ends

Then code: API calls, custom objects, serverless functions, private apps. This is where the work stops being clicking and starts being engineering, and it is written to be read by somebody else.

HubSpot native

Monitoring on top

Anything that runs unattended gets a log and an alert. An integration that fails quietly is worse than no integration, because for weeks everybody trusts the data it stopped writing.

Integrations and automation

Process map. Specification. Build. Run.

01Map

Process map

I walk the process as it happens today, including the spreadsheet in the middle and the person who reconciles it. This is where it becomes clear which step actually needs a decision.

02Spec

Specification

What gets connected, in which direction, what happens on a conflict, what happens on a failure. Written down before anything gets built, because "both directions" is a sentence that hides most of the cost.

03Build

Build

Built in a test environment, on real records, with the failure cases exercised on purpose. The error path gets tested as deliberately as the happy path.

04Operate

Run

Go-live, monitoring switched on, and a documented handover. After the first weeks there is a review of what the edge cases turned out to be.

Starter offer

An audit day or a training day to start working together.

Both have a fixed scope and take one working day. I quote a larger project only once I know what is really in it.

HubSpot8 hours

HubSpot portal audit day

Half an hour with leadership on the one number the company cares about
A read-only pass through the portal
Twenty minutes with each team member, up to four people
A document with fixes priced in hours, plus an hour to walk through it

Book a call about the audit See the audit scope

AI in business8 hours, online

AI training day for your team

Six blocks in one day
Opening with leadership, 30 minutes
Hands-on work with the model on your team's materials
Recording and a starter kit for every role

Book a call about the training See the training programme

Integrations and automation

Questions that come up on a first call.

What does process automation actually mean here?

Taking a process that runs today with a person in the middle, and removing the part of it that does not need a decision. Usually that is reading data in one system and typing it into another, which is also the part that fails silently when somebody is on holiday.

What kinds of integration are there?

Three that matter in practice. A native connector built by one of the vendors. A configured connection using what both platforms expose. And a written integration through APIs, for the case where no connector exists or the one that exists does not do what it claims.

How much does automating a process cost?

It follows the number of systems, the direction of the flow and how many exceptions the process has. The honest first step is counting the current cost: minutes per run, times runs per month, times people doing it. That number decides whether the project is worth starting at all.

How do we map our processes before we start?

Start with one process and follow a single item through it end to end, writing down every place somebody touches it. Mapping an entire department at once produces a diagram nobody uses; one process produces a specification.

Our system has no ready integration. Can this be done?

If it has an API, yes. If it does not, there are usually other routes, including scheduled exports or a dedicated address that records what flows through it. I say which route it is before I start, and what its limits are.

Who maintains this after the project?

Your team, with the documentation and the code. The parts that need occasional attention can also sit inside portal care if the integration touches HubSpot.

Do we need HubSpot or another CRM for this?

No. This line works in companies that have no CRM at all. If you do run HubSpot, the integration usually gets cheaper, because part of the plumbing is already there.