What makes 1pm ideal for event planning

Count the tools it takes to get one 300-pax gala from enquiry to invoice.

There is the inbox where the enquiry landed. The spreadsheet where the quote was built. The proposal deck in a design tool. The signed PDF sitting in a downloads folder. The BEO in a word processor, version four, emailed to the kitchen on Thursday and superseded on Friday. The timeline in a second spreadsheet, shared with suppliers as a read-only link that nobody can read on a phone. The accounting package where the invoice lives. The calendar that half the team looks at and half the team does not. And a group chat holding the three decisions that never made it into any of the above.

Eight tools. One event. Every handoff between them is a place where a detail quietly stops being true.

That is the problem 1pm was built for, and the honest reason this article needed rewriting. When it was first published, 1pm did one thing very well: a live run of show that crew could actually use on the day. That is still the sharpest part of the product. It is no longer the whole of it.

Where an event actually starts

It starts before anyone has agreed to anything.

Enquiries come in through a form you can embed on your own site, and they land in a Leads inbox rather than an email account. Each one is a thread you can reply to from inside 1pm, with saved reply templates for the questions you answer forty times a year. Calls, texts, and site visits get logged against the same lead, so the history of a client is in one place instead of split across a phone and a memory.

From there you price it. There is a reusable catalog of priced items and packages behind the pricing screen, so a canape package or a room hire rate is defined once and reused, not retyped per event with a fresh chance of a typo. A quote goes out as a link. If the pitch needs more than a price, you build a proposal instead: a branded, block-built web page that fills itself in with the real event details and updates when they change, so there is no PDF to re-export every time a number moves.

When the client says yes, they say it on the page. Terms are versioned in a library, the client ticks and types their name, and 1pm records who agreed, to which version, and when. If someone asks in eight months what was actually agreed, the answer is a record, not a recollection.

Then the deposit. Invoices can take card payments online through Stripe, or you record the bank transfer by hand, and the balance owing is current either way. Deposit and balance invoices, service charges, gratuities, credit notes, and a running statement per event are all in there, because the money side is where "we will sort that out later" costs the most.

The middle, which is where events are actually won

The planning phase is unglamorous and it is where the margin lives.

Spaces are your saved venues and rooms, each with its own address, access instructions, and capacity, and 1pm will hard-block a double booking of the same Space unless you have said concurrent events are fine there. That single rule has saved more Saturday mornings than any feature I can think of.

The BEO builds itself out of the event record. Service style, setup style, pax guaranteed, dietary summary, menu, bar package, AV notes, access from and vacate by. It is one page, it is current as of the last change, and the kitchen is reading the same version as the duty manager because there is only one version.

Menus live in a library, built once as courses and dishes, and then they appear on the BEO, on the client confirmation, on the charges, and on the printed card on the table. On the Hospitality plan you can link each dish to a costed recipe and see plate cost, food cost percentage, and margin as you build. That part is planner-only. It never reaches the BEO, the confirmation, the printed menu, or a crew member.

Tasks sit alongside the events with steps and reusable workflows, so the fourteen things your team does for every booking are a saved workflow rather than a habit. Automations run the rest: a rule fires on a trigger (a quote sent, a date approaching, a booking confirmed) and sends the email or spins up the checklist. There is a review queue if you would rather read a client email before it goes.

Requests handle everything you need to collect from other people. Insurance certificates from suppliers, dietary requirements from guests, headcounts, signed agreements, documents with expiry dates that get chased automatically as they lapse. Each person works through their own no-login link. For onboarding that has no event attached, contractor compliance, stallholder applications, staff paperwork, there are Portals: the same machinery with the dates and pax stripped out.

The day itself

This is the part the original version of this article was entirely about, and it has not stood still either.

• A live ROS with countdowns on every item. "In 15 min", "running 3 min", "done in 5 min", refreshing across every device that has it open.
• One-tap Start and Finish for crew, with undo, so you get real wall-clock timing and a record of how long things actually took.
• Drag to reorder and the times follow. Insert above or below and the math is done for you. Tab-driven editing builds a full ROS from the keyboard.
• A private link per crew member, no logins. Each one sees only their own items, or the full ROS minus private items when they need context.
• Mobile-first, and it works offline. If the signal drops in a loading dock, the ROS stays and taps queue locally until it returns.
• Conflict warnings on overlapping items, so clashes surface before the day rather than during it.
• Full audit trail. Every change logged with who and when.

The client can have a view of it too, and so can the public if the event calls for that. Same data, different filters, no third spreadsheet.

Then the part nobody enjoys

The invoice goes out from the same record that holds the pricing, so the numbers cannot drift. It can sync one-way to Xero. Payments post against it. Reports cover the pipeline and conversion rate, operations, finance, and the kitchen, and every one of them exports to a spreadsheet and prints clean for a management pack.

That is the loop closed: enquiry, quote, proposal, terms, deposit, BEO, menu, tasks, requests, the day, the invoice, the numbers. One record per event, from the first email to the final payment.

The point of all of it

The pitch is not "1pm has a lot of features". Plenty of software has a lot of features and is miserable.

The pitch is that a detail entered once should be true everywhere. The pax number the client confirmed should be the pax number on the BEO, the number the kitchen cooks to, the number on the invoice, and the number in the report. Not because someone diligently updated four documents, but because there is one number and four views of it.

Everything else, the live ROS, the offline crew links, the branded confirmations, the recipe costing, follows from that. So does the thing venues actually feel, which is that the number of times a week somebody asks "is this the latest version?" goes to roughly zero.

A quick note about words

I use "run of show" throughout, and ROS for short. If you learned the trade in the UK or Australia you probably call it a run sheet. Same document, same job, and 1pm does not care which word you use. You can even rename it inside your account, along with Events, Crew, and Spaces, so the software speaks your dialect rather than mine.

Closing

Go back and count your eight tools. Then count the handoffs between them, because the handoffs are where the version-four BEO gets emailed to a kitchen that is already cooking from version three.

1pm is an attempt to remove the handoffs rather than to make each tool marginally nicer. That is a slower thing to build and a harder thing to demo, but it is the only version of this that meaningfully changes a Saturday.

Chris Founder, 1pm.app