Nobody Wanted to Write the Meeting Summary

After a client call in Google Meet, somebody had to write down what we talked about, what we agreed to do and what needed following up. Nobody liked doing it, so the summaries came late, with information missing, tasks missing, and sometimes very little that anyone could use.

People didn't create them because they didn't have the time and it was a pain to do it. If you have six meetings lined up in a day and fifteen minutes between them, you're not going to fill a template.

You have a lot of meetings to attend to and a lot of work to do, and those short gaps are what you need to prepare for the next client, not to sit down and write up the last one.

And if you're trying to work out what tasks to automate with AI in your company, I would look for your version of that, a piece of work people keep putting off even though somebody needs the result.

When the notes didn't get written, the cost didn't disappear. If you needed something from a sixty-minute meeting and it wasn't in the notes, you had to go back to the recording, remember roughly when the subject came up, watch again and write it down.

That could take from ten minutes to sixty minutes re-watching and taking notes. That was the hassle we had, not a measured saving I'm claiming for every summary.

We knew AI could help us with that, so we went through three versions in a week before we got something the consultants and clients liked, and those summaries are still in use.

AI could read the transcript and write the summary instead of leaving the consultant to do it. But getting that to work also meant figuring out what a good summary should contain, and we hadn't properly done that before.

Think about what happens with work like this in your own firm. Someone writes up the call, closes the task and moves on, so as far as the system is concerned, the work is done.

But that doesn't tell you whether the things people agreed to do actually made it into the write-up. A summary can exist and still leave the next person without the information they need to do their job.

That's the problem we had. And I don't think blaming the people writing them would have helped, because we hadn't given them a clear enough idea of what we expected either.

They were doing work they didn't enjoy, alongside the client work they still had to finish, and nobody had properly decided what a useful summary looked like. I say that as the owner, this was something we needed to sort out.

I've written about where AI projects get stuck between a working demo and daily use. With our summaries, checking that the system produced text wasn't enough, we needed to know whether that text helped the person receiving it.

Now, there's a reason this kind of work can be harder to automate than you expect, and it helps to separate two jobs.

Sometimes you already do the work well. You have a report people use, someone knows what belongs in it, and you can show the AI what you're trying to produce. You're asking it to follow a pattern you already understand, faster or better.

Other times you're trying to produce something you haven't worked out how to do properly yet. You can explain what it's for, but once you see a first version, you start realizing what should be different.

That's much closer to what happened with our summaries. We had people writing them, but we didn't have a good enough example that we could point to and say, make it like this.

So we had to try things, look at what came back and work out what would actually help the people using it. That takes more thought than handing over an existing process.

I've told people to document the process before giving the work to an agent, and I stated that too strictly. It assumes you already have a process worth following.

If the way you're doing the work now produces a poor result, writing it all down doesn't solve that. In our case, we needed to improve what the summary was supposed to be, and trying an early version helped us make those decisions.

And when I say a template wouldn't have solved it, I don't mean defining the output was useless. I mean a better form still leaves someone filling it in during the minutes they need for something else.

Nobody wanted to do that, it felt like a waste of time. Having AI read the transcript and draft the summary is a much better solution than having someone fill a form when they have minutes to prepare for the next client.

The first summary version gave us pages of text. It was too complicated, and even though it contained a lot of information, people didn't want to read it.

So we made it simpler, and then we went too far. The second version was missing the work that was agreed, the next steps and the next tasks. We had made it easier to read without making it useful enough.

We needed those tasks in a short list, with enough detail that someone could scan it and understand what needed doing without reading a long account of the meeting. Making the summary shorter wasn't enough if the agreed work disappeared with the text.

The summaries we ended up with were used to create follow-up tasks, help with client planning and keep a history of the project.

We had very few problems with the AI making things up in this case. Most of the work was on how the information was presented and how much of it belonged there.

That doesn't mean accuracy is usually easy, I'm telling you what happened with this particular job. If we'd only checked whether the statements were correct, we would have missed most of what people disliked about the output.

And we had a similar problem with a system that read sales meeting transcripts to help a supervisor give feedback. It produced so much text that the supervisor wasn't getting much use from it, so we replaced the reports with scores that showed who needed help first.

I explained that case in the AI enablement article. In both cases, looking at what people actually used told us something we couldn't learn just by looking at whether the system ran properly.

With the meeting summaries, three versions in one week got us to something everyone liked. But please keep the conditions around that result, because I was the person making the changes, I was involved in the deployment and I responded quickly when something needed fixing.

If nobody in your company has time to do that, you shouldn't expect the same week. The team can tell you what's wrong, but someone still has to make the change and get it back to them while they're willing to keep trying.

I haven't measured whether it improved retention, project outcomes or anyone's hours. What I know is that the summaries became useful enough for people to keep using them in their work.

So don't stop at how quickly the AI wrote it, check whether the follow-up tasks are getting created and whether the summary helps people plan the next piece of client work.

This also puts a boundary on something else I've written. In The Extra Time AI Buys You Is Already Gone, I said to decide what saved time will be used for before the rollout. That rule was too strict as well.

It applies when you're expecting to free up time. You should still count the checking and rework, and decide what the team will do if those hours become available.

But if you're starting with work that was being done badly, getting a useful result can be the reason to try it. Removing the manual writing matters too, but you don't need a measured hours-saving claim to explain why a better project record is worth testing.

You will still need to look at what it costs, including the time spent building and maintaining it. The Four Numbers can help you work through that, but don't turn continued use into a financial return you haven't measured.

Now, I want to be careful about which work you choose, because people disliking a task tells you nothing about how much harm a mistake could do.

Our summaries were client-facing from the start, used for planning and kept as project history, so a mistake could affect work beyond the summary itself.

They were always checked. The summary was saved in our system, the consultant would read it and then he could share it with the client.

So they weren't sent automatically without a check, and a wrong statement wasn't harmless just because I could fix the next version quickly.

That is why I would ask two questions together, how far can a mistake go before someone notices, and how quickly can we deal with it?

I've written about sorting AI work by what a mistake could cost, and that still applies. Starting with a client-facing task in our company isn't a recommendation for every firm to do the same.

So when you look for your first piece of work, ask the team what keeps getting put off, what came back late last week, what was finished but wasn't much use to the next person.

You're looking for something that repeats, with someone who needs the result and can look at an early version with you. A handoff note or a meeting write-up might give you somewhere to start, but you still need to check what could go wrong in your own situation.

Then write down what you think a useful result should contain. It doesn't need to be a long document, it needs to be clear enough that you can put a first version in front of someone and talk about what should change.

Expect to learn something from that conversation. We needed to see a version that was too long and another that was too thin before we got the summary into a shape people wanted.

And name the person who will make those changes before you ask the team to try it. They need to understand the system well enough to fix it, and they need time available to do that work.

From the user's side, reporting a problem takes time too. If they tell you what's wrong and nothing happens, they still have a client waiting, so going back to the old way can be a reasonable decision.

I've seen that happen. In one rollout, a user had trouble importing a couple of Google Meet recordings and went back to the older system without reporting it. He still needed to finish the work, and the import failures gave him a reason to use the system he knew.

So don't assume that silence means it's going well. Go back to the people who tried it, ask whether they're still using it and look at what they're doing with the result. Let them try it before you assume that wanting relief from the work means they'll trust your solution.

Starting with work people avoid is where I would look for candidates, based on what we experienced. Whether your choice works depends on what the output needs to do, what happens when it's wrong and whether someone keeps improving it after the first try.

And once it is useful, you may find that the next thing slowing the work down is checking it. We got summaries people could use, we didn't finish improving the whole company.

Before you buy another tool, ask your team for one piece of work that keeps arriving late or incomplete, and sit down with the person who needs it. Work out what would make it useful, then decide whether AI is a sensible way to get there.