Rob Rigby

Operations, and the systems people work in.

I've spent the last two years at a small data company near Bristol, running a research team and building the tools they use. Below are three things I've done there, and one I built for myself.

How this work was specified rigbyrob@gmail.com LinkedIn

How a research record got updated, before and after

The database behind a B2B data product, around 13,000 company records.

Before

Around 1,500 paper forms posted to freelance researchers
Completed forms posted on for data entry
Every record checked by hand against a 50-page guide
Database updated

Several months from start to usable data

After

Employed researcher works a record from their list in an online form
Records gather into batches of around 100
Five staged checks, each decided by a person
Written back to the live database

Uploaded the same week, on the same staff hours

Case one

Rebuilding the research process

Some of the records in the database had not been touched for five years. It was sold as a live, managed database of about 13,000 companies.

The work went out on paper. Around 1,500 forms in the post to freelance researchers, back again to be typed up, then every record checked by hand against a 50-page guide. It took months, nobody could say how big the backlog was, and there was no way to measure what a freelancer had actually done.

I made the case to the directors for employing researchers instead, wrote the advert, held the interviews and inducted the team. The paper forms became an online form that checks entries as they are made, which I designed and built using AI tools as an aid. I also split the database into priority bands by company size, so the largest companies are researched four times a year and the smallest once, and built the research calendar around that. Those decisions were mine, based on which errors customers actually notice.

Monthly output went from around 400 records to around 1,500 on the same staff hours, and about £500 a cycle of printing and postage stopped.

The online research form part-way through a record: three contact slots, the fabricator questions as checkboxes, and buttons to mark the record done, book a callback, send an email or look the company up.
Research form, customer data removed

Case two

A checking platform that keeps people in charge

A completed checking batch of 39 records: counts for updates, companies gone and refusals, a full progress bar, and each workflow stage from pre-flight to completion marked complete.
Batch progress view, customer data removed

Every record had to be checked before it went live, and for a long time the only person who could do it was me, working through a 50-page manual by hand. That was the bottleneck, and it was one I had created.

The platform I designed takes a batch of around 100 records through five stages: data quality, comparing updates, refusals, companies that have gone, and completion. A person decides at every stage. What the platform does is track where a batch has got to and make sure nothing is skipped, so it can be picked up later or by someone else. A batch takes about an hour.

The 50-page manual became a three-page process covering the same ground, and the checking is now done by two senior researchers rather than by me.

Case three

Cashflow forecasting at short notice

The colleague who handled cashflow for both companies in the group left on two weeks' notice, and what he left behind was not usable by anyone else. Nobody could say with confidence that staff and suppliers would be paid at the end of the month.

I started by building an application to model it, which was the wrong call. After three days it was clear it would take longer than the directors could wait, so I stopped and put the position in a spreadsheet instead, and had a first draft with them the next day. They then asked for it on the date customers actually pay rather than the invoice date, which meant working back through twelve months of invoices and bank statements to see what each customer paid and when.

Before I had finished, a gap showed up four months out, caused by our largest customer moving to longer terms. I reported it straight away rather than waiting until I could size it properly. It first looked like £20,000 below zero. Cancelling and renegotiating supplier contracts brought that to about £10,000, and the directors closed the rest by agreeing different payment dates with a customer.

The tool I eventually built from that reads invoices and payments from our accounts software. The part that took the longest was card payments: they arrive grouped in one settlement, so the forecast was putting money on the wrong dates. I gave the directors three options and recommended capturing the detail closer to source, because attributing it by best guess would create new errors every time the settlement pattern changed.

The forecasting tool's matrix view: every regular payment as a row, each month as a column, two years across. Frozen history is shown in grey italic and the live forecast in red, with a total row along the bottom.
The tool that came out of it. Every regular payment is a row and every month a column, running two years ahead; the names and amounts shown here are stand-ins.

Aside

My own project: a job application tracker

Built for my own job search. It records every application, its closing date and outcome, and flags anything about to close.

Try the demo (example data, nothing real)