Work

Teardowns, field observations and internal builds

I'm upfront about what this page is and isn't.

No verified paid client case studies, yet

I don’t have paid client case studies I can verify and publish yet, and I won’t invent results to fill that gap. What follows are anonymised process teardowns, field observations and my own internal builds — clearly labelled as such — so you can see how I approach a problem before you engage me.

Process teardown

Multi-channel field-service workflow

An anonymised teardown built from one field-service business's public-facing pages: enquiries can arrive by phone, SMS, email and an embedded HubSpot web form, alongside recurring field service with a service report after each visit, and Xero used for property-manager invoicing. The points below are questions that evidence raises, not confirmed findings — there was no access to the business's internal systems.

Do phone, SMS, email and HubSpot enquiries converge into one customer or job record, or does someone reconcile them manually?
Does a HubSpot form submission automatically create anything in the customer or scheduling system, or is there a manual handoff after submission?
When a service report identifies extra work, how does that become a quote, approval, follow-up and scheduled job? Public information does not answer that.

Field observation

Management visibility & time capture

A single field conversation in a large industrial workshop, not a formal study: one employee described how the team accounts for their day.

One worker said employees account for what they do throughout the day across categories including meetings, pre-starts and different types of work.
That worker described the logging itself as burdensome; I did not independently observe the full logging process.
The worker said head office wanted visibility into where labour time was going. The process lesson is to preserve that management visibility while testing whether the capture effort can be reduced.

Internal build

Workflow reliability build

Internal automation and reliability practice using n8n, APIs and databases — useful for showing how I structure workflows, diagnose failures and document what is happening without presenting internal work as client proof.

Where normal rules are sufficient, I prefer deterministic routing and checks rather than adding an AI step.
Error handling, logging and monitoring are part of the reliability design so failures can be made visible and diagnosable.
These are internal builds and experiments. They are evidence of hands-on practice, not a client case study or proof of performance at scale.

Want a teardown like this done on your own process?

A process review is the first step — no build commitment until there's something worth building.

Start with one process