Rob Rigby

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.

I was told there was no point emailing the companies we research, because they never reply. That's true of most of them. It isn't true of all of them, and the ones who do reply give you the information without anyone having to make a call. There was a second benefit too: an email that bounces tells you the address on the record is wrong, which a phone call never does.

So I had the researchers start emailing records, copying me in so a reply arriving while someone was away didn't sit unanswered. That worked, but they were spending a long time composing each one, so we built templates.

When I built the research form I integrated the emailer into it properly. Templates are built inside the site. A researcher clicks “Email record” and it sends a personalised email in their own name, copies me in, and stamps the record to show an email went out. They can edit it first if they want to add a question. It takes a second.

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.

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.

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.

One of the directors wanted an emailer in the customer platform, mainly because our main competitor had one. Building it from scratch had always been ruled out on cost, which is why it had never gone anywhere.

I asked the agency who develop the customer platform what was possible. A fully integrated version, the one that would have looked custom built, came back at many thousands more than the business would spend. So rather than report back that it couldn't be done, I looked for a version that could.

What I landed on was this: we hold the account with an established email provider, and each customer gets a login as a user on our account rather than setting up their own. They compose their templates there, and when they click the email button in our platform their templates appear and they choose one. Not the seamless version the director wanted, but the same service for a fraction of the cost, and the customers' data never leaves the platform. Customers had been allowed to export that data for thirty years, so this broke a long-standing rule.

I set out the requirement in writing for the agency, with screenshots showing where the controls should sit: an email-all button, an email-individual button, and which contact an email-all should go to. Then I put the case to the directors, with the agency's quote and mock-ups of how it would look.

One of them pushed back, reasonably, on sending customers to a third-party site to write their emails. My argument was that starting simple would show us whether customers actually wanted the feature before we spent money on the polished version. That's still the version in use.

Before release I ran it on a test site using our own seed records, so every email came back to us. Two faults turned up that way. Sending to a chosen contact didn't work at first. Worse, where several records shared one generic address, such as branches of a national chain, it sent one email per record, so a chain with 500 branches would have received the same email 500 times. Both were fixed before any customer saw it.

We ran it for three months with one customer at a discounted rate while it was ironed out, and that produced a functional change I hadn't specified: the option to email all the first contacts, or all the second contacts, rather than everyone on a record. That came from the customer using it.

Five customers have used it since. Four of them would not have signed up on the six-month minimum term the business had always required, and the emailer is what let us drop it. The provider's subscription costs around £700 a year and the new business has covered it several times over.