Systems I run my own business on

My back office: jobs, invoices and follow-ups

Real · in daily use since January 2026

After a call or a site visit, I record a voice note. It comes back as suggested changes to my records, and I review them before they go in.

1. After a call or site visit, I record a voice note.
2. It’s transcribed and turned into a structured debrief.
3. The changes it suggests are staged for me to review.
4. I approve them, and an update routine carries them into the job records, the invoice ledger and the follow-up calendar.

When I type a debrief instead of recording one, it feeds the same update routine.

Documented

The voice-note path: transcription, a structured debrief, changes staged for me to approve, then the update routine.

Illustrated

The walkthrough above. Same steps, invented data.

Not shown

Output from a real run. Real records hold client details, so none is published here.

What it keeps. It’s a set of AI-assisted routines over plain files I own. I call it Ops, which is where the name RunByOps comes from. It keeps:

• a record for each lead and job, with its status and next action
• an invoice ledger, each invoice tied to its job reference, with issue date, due date, payment terms, paid date and status
• a follow-up calendar
• short debriefs from site visits, calls and meetings
• a morning summary of the pipeline, follow-ups due and the day’s priorities.

The rules I’ve written into it. These are written instructions for the AI-assisted routine. They describe how it’s meant to work, not database rules that make a mistake impossible.

• Keep the ledger in step. Any change that touches an invoice should update the ledger in the same save, so follow-ups don’t work from stale figures.
• A client’s own requirement. One regular client needs a purchase order number on every invoice, so the rules call for one.
• Follow-ups nobody wrote down. When a lead or job changes state, a dated follow-up should go into the calendar in the same save.
• Sources that disagree. When two records say different things, don’t quietly pick one: list both, then record the reconciled answer with a timeline.

Where it stops. It started in January 2026, and the invoice ledger was added in May. It’s built around one person and plain files, so it isn’t something I’d install in your business as it is. What transfers is the pattern: one record per job, a ledger tied to it, follow-ups set when something changes, and a person reviewing what the AI suggests. Guides 01 and 03 are the spreadsheet version, and guide 04 is about making an AI step like this one reliable.

Photo registers: a converter for observation-only records

Real · built February 2026

The problem. My early photo registers did two things at once. Beside each photo was what I saw, plus a severity rating and a recommended action. On the jobs these registers support, those calls belong to the appointed consultant, not to whoever records the photos. Putting them in my register blurred who decided what.

What I built. An observation-only register format, and a small script that converts a finished register into it, so changing the format didn’t mean redoing registers by hand.

What it expects. My own register layout: a Word table with eight columns and one photo per row. On the register it was written for, 15 rows with one photo each, the observation-only version has all 15 photos, unchanged.

Where it stops. It’s built for my own register layout, not as a general tool. Because it works from fixed lists of phrases and keywords, the converted register is a draft for a person to read, not a finished document. Observation-only is now the standard for the registers I deliver: I record what’s there, and the appointed consultant makes the calls.

The same idea runs through guide 02: record what was seen, and leave causes and recommendations to the person responsible for them.