Your best people already built a worse version of this

What have the best operators already built?

I’ve worked 300+ events. The best in-person GTM operators I know, at companies from $5M to $500M ARR, have already built their own software out of consumer AI tools, on nights and weekends, without asking anyone’s permission.

An enterprise director of events built an AI notebook from her own scan lists. She asks it questions like “who have I scanned at my booth in the last year in New York?” A senior field marketer built a chatbot that reads the pile of organizer emails for an upcoming show and turns them into the pre-show deck her team uses.

Another operator keeps a library of prompt templates that draft event prep docs. Another built a bot that rates events before the company commits budget to them. A RevOps leader went furthest of all: they sketched the internal system the company needed, then watched it lose the fight for priority to revenue work.

Some of this is initiative and some of it is survival. One enterprise director of events relayed the mandate her company handed down: “AI is not going to replace us, but someone who knows how to use it will.”

And the results are real enough that the builders keep relying on them. The field marketer with the pre-show chatbot gave the most honest product review I’ve ever heard: “It’s not always great, but it’s a lot better than having to do it myself.”

An investor recently made the same point from the other side of the table. He told me an AI coding agent could probably rebuild the whole product “in a week.” He meant it as a real question, and he’s more right than I’d like to admit. What he’s missing is the difference between a tool and infrastructure.

Are the builders right?

Start with what I believe: every one of these operators is right.

When the best people in a field start building their own tools out of consumer parts, that’s the strongest demand signal a market can produce. You build a scan-history notebook because the question it answers matters to your job. You’ve been asking it for years, and your company’s stack can’t answer it.

Each of those workarounds pinpoints a piece of missing infrastructure:

• The rating bot says the company picks its events from the organizer’s marketing, with no evidence of its own.
• The email chatbot says pre-show details arrive in pieces, scattered across organizer threads.
• The notebook says the company has no memory of its own time on the show floor.
• The RevOps sketch says even the team that owns the data can see the need, and it still loses to a pipeline commit.

I want to be plain about this: your build isn’t naive. If you’ve built one of these, you understand the problem better than almost anyone, and your instinct that this should exist is right.

Why are a personal tool and infrastructure different species?

The difference has nothing to do with code quality.

A personal workaround serves one brain. The notebook works because its builder knows what she meant by every list name and every half-typed note; the tool inherits her context for free. Hand the login to a colleague and it becomes an archive of someone else’s shorthand.

Its builder keeps it running on stolen evenings. There’s no roadmap and no on-call rotation. When a model update changes the output, or when an organizer changes their email format and the digest breaks the week of the show, she’s on her own.

The upkeep runs on one person’s spare attention, and the job already uses that up at the 50-event ceiling: the 50 to 60 events per manager per year that operators report as the most one person can run.

It dies when the operator changes jobs. When she leaves, the notebook leaves with her, or sits forgotten in a personal account. Her company spent real budget building the history inside it, and that history was only ever on loan from her.

It never crosses a team boundary, and this one matters most, because in event-driven GTM the failure lives between teams. A prompt template does fix drafting. The hard part is what happens after you send the doc.

A director of events put it this way: “You send them a spreadsheet… they’re like, cool, I’m going to look at this. Never.” A director of marketing events, on kickoff docs: “They’re ignoring it or reaching out to us asking the questions.” A better-drafted ignored document is still an ignored document.

And a head of events summed up the position she’s in: “How can I make this the easiest, so easy for everyone else, but I know my success depends on everyone in the company.” Her personal tool can’t reach the people her success depends on. It lives on her laptop, and they live in another org chart.

It can’t enforce anything. You don’t SLA-track your own spreadsheet. A workaround can show you which leads went unworked. It can’t give the gap an owner, show it to that owner’s manager, and keep it there until someone acts. Only a shared system that your whole revenue team agrees to work in can do that, and that’s a fair working definition of infrastructure.

And it can’t build up over time. A personal tool learns one operator’s history at one company, for as long as she stays. Infrastructure keeps the record when people move on, and it gets smarter with every event. Over the years, it turns your team’s activity into the evidence you need to defend your events budget, the way digital channels always could.

None of this is the builders’ fault. It comes with the species. A tool that one person builds, for one person, on one person’s time ends up as a personal assistant, however good that person is. Infrastructure is a different animal: shared, enforced, and permanent. The company owns it, so it stays when the hero leaves.

Was the code ever the defensible part?

That brings me back to the investor, because his week is real. An AI coding agent probably could copy the screens, the schema, and a good share of the prompts of a tool like this in a week. The honest answer is: so what?

The week-one rebuild gets you the software. Everything the software exists to hold is still missing.

It can’t create years of event history, because history builds only as fast as the calendar moves. It can’t skip the years of expo-hall wifi, badge-file formats, and rare CRM edge cases a product has to survive before it holds up. A week-old product has met none of those. It can’t fast-forward your reps’ trust, which grows one clean handoff at a time.

And it can’t invent the record itself: which accounts your team covered at which shows, what people said in the aisle, which leads your reps worked afterward, and what it all produced. Your CRM records revenue. It leaves out the work that produces your in-person revenue. You only get that second record by writing the work down in one place, for years.

Anyone can print a blank ledger. The value was always the entries.

Should you keep building?

So here’s my advice to you. Keep building your workarounds. They pay for themselves in saved hours, and they sharpen your understanding of the job. The bar one builder set for hers, better than doing it all by hand, is worth clearing tonight.

And understand what you’re producing along the way. Together, the notebooks and rating bots and prompt libraries are the best requirements document this industry has ever written. The only people qualified to write it wrote it, and each piece marks the exact spot where infrastructure should have been.

When you want a version that outlives you, run your events on FieldXM. Your successor inherits the record of every show. And FieldXM reaches across the boundary between your teams, where the work breaks down. Your reps capture leads in the FieldXM mobile app, and FieldXM’s accountability reports show you who followed up.

Go deeper

• The category argument: The Last Unmanaged Workflow in B2B Revenue, on why the failure lives between teams.
• The throughput argument: the 50-event ceiling, on the spare attention operators build these workarounds with.
• The capture finding the notebooks are compensating for: the event capture gap.