AI Built This: Built isn’t the same as used

SHARE

By Ben McCarthy, founder of Premier Events.

Last month, I said the next column would be about creating SOPs for each team.

That work turned into something bigger, a set of new Hub modules for how we actually run a job, and it’s taught me something I should probably have known already. Building the thing is now the easy part. Getting 55 people to use it is hard work.

Here’s where we are at.

The projects section of the Hub, the part that holds a job from enquiry through to delivery, is built, tested and live – but nobody is using it. I held the first training session on it this morning, with nine of the event management team, so if I told you it was up and running I’d be lying. The client brief module is being used by one team only. The enquiries module is being used by the Woodshop and AV teams, and nobody else yet. Goods in and storage is starting to get picked up, but there’s a backlog to work through before it reflects what’s actually in the warehouse.

None of these are broken. Every one of them does what I asked it to do. The problem is that I’ve been building faster than I can train people, and a tool that nobody’s been shown is, from the team’s point of view, exactly the same as a tool that doesn’t exist. Three months ago I was pleased that ten days could get you six working systems. It turns out ten days can also get you six things that sit there.

So I’ve stopped. No new modules for now. My time at the minute is being spent training people to use what’s already live, and on understanding how they work today. It’s been a while since I managed client events myself, so I’m out of the loop on how they operate!

This morning’s session is a good example.

The event management team already have a way of running a job, and it works. When a new job comes in, they set up a SharePoint site in Teams for it, and that’s where everything lives. What I’d built was a Hub projects section which, when a new job is created, also sets up a SharePoint site. So the first thing we found, within about ten minutes, is that the Hub would quietly duplicate something the team already does. That’s not something I’d have found by building. I could only find it by sitting in a room with the people who do the job.

The fix isn’t super technical; it’s simply marrying the two up so there’s one site per job! Then there’s the bit I genuinely can’t do myself: the team need to go away and build the task templates. Every type of job we deliver has its own set of things that need doing, in a sensible order, and if the Hub is going to add those tasks to a new project automatically, with dependencies for other departments, then the people who’ve been doing them for years need to be the ones writing the list.

A smaller thing from the same session.

Before we started, I’d asked Claude to make a short animated teaser video about the Hub, a bit of a sizzle reel, to show the team at the start. It took no time and it did the job of getting people interested before the detailed walkthrough. I’m not going to pretend that’s a business-critical use of AI, but it’s a reminder that the model’s getting good at things well outside writing code.

One module I built which I use all the time is the My Day section of the Hub, which now drafts my social media posts. It comes up with the ideas based on my conversations with Claude that day, writes the copy and produces the artwork, and I go through and tweak them before anything goes out. Before that, I’d just stopped posting for a while, not because I didn’t have anything to say but because I was busy and writing from a blank page is the bit that doesn’t get done. Editing something that’s already there is a different job. Posts are going out again and it’s already led to some more work!

That tool went from built to used in an afternoon. It needed no training session, no templates, no backlog. The difference isn’t that it’s a better tool. It’s that it has one user, and that user is the person who built it. The projects section has circa 40 users, most of whom have a perfectly good way of doing the job already, and every one of them has a reason not to change this week. Of course it takes longer. I should have planned for that from the start, but I’m impatient so just cracked on with building stuff!

If you’re running a business this size and building your own tools, my advice this month is slightly different from usual. Build one thing. Then stop, and go and watch someone use it before you build the next one. What you learn in that room is worth more than the next module, and it’s the bit you can’t delegate to the AI.

Next month: the savings. We’ve now cancelled Deputy, Deskbird, SwipedOn and a few others because something we built does the job better. I’m going to tot up what they were costing us and what replaced them.

I’m also looking into automating our AV dry hire department, so I may have an update on that too!

Facebook
Twitter
LinkedIn
WhatsApp
Email
Print