A VIP host books again, a year later. Does Excellent remember the first event?

A host books a private dinner in March. The room enjoys working with them. Then nothing until next February, when the same host calls to book again. Does anyone remember the allergy from last year? The seating preference? The fact that they always ask for the corner table?

This is a fair question to ask any events system, and it deserves a straight answer instead of a hopeful one. Some of what matters is already attached to the host as a person, not buried in last year's paperwork. Some of it is not built yet. Knowing which is which keeps you from relying on something that is not there, and from missing something that already is.

Does a repeat host show up as the same record, or a new one each time?

The same record. The host of an event is a Party, a first-class entity in Excellent, and a guest who signs a contract and a host named on an event both resolve to that same kind of record. A returning host is not re-typed as a stranger the second time. That is the groundwork a repeat-booking feature would need, and it already exists: nothing has to invent a way to tell that March's host and February's host are the same person, because the platform already treats them as the same Party.

What actually carries forward from one booking to the next today?

The documents and records tied to that one event: the proposal, the BEO, the contract, the invoice, the signatures, the seating chart, and the named guest list. A finalized BEO is written as an immutable snapshot the moment it is finalized, so if you need to see exactly what was served or who sat where on the March event, that record exists and does not drift later. A named guest list for an event can carry a VIP flag and a per-guest meal choice, attached to that event's own guest rows.

What does not exist yet is a built view that automatically pulls last year's allergen note or seating preference forward into this year's new event. The roadmap is direct about this: a cross-restaurant event-history feature, something that would let a host's past bookings inform the next one automatically, is listed as not started. So today, if the corner-table preference from March matters in February, a person has to find the old BEO and bring it over by hand. The system does not do that lookup on its own.

Why does the Party record matter if the history feature is not built?

Because the Party is the entity everything else hangs off, and the token a no-login guest uses to view or sign a document is kept separate from it on purpose. The guest signer and an event's host both resolve to one Party, and that Party stays the data model's home for the person, while a magic-link token is only ever the access mechanism — never the record itself. That separation is a narrower claim than promising a feature exists, but it is the honest one: keeping the person and the access method apart is what makes it possible to add things to a Party later without re-plumbing how a host is authenticated.

So what should an operator actually do about the March host today?

Treat the finalized BEO as your memory until a built history view exists. The document is there, permanently, and it states exactly what happened: the run of show, the allergens on that menu, the seating. If a host's preference matters enough to carry into the next booking, write it down somewhere a person will check before the next proposal goes out, because nothing today surfaces it for you automatically. This is not a workaround to be ashamed of. Keeping a note by hand while a data model is still catching up is ordinary practice.

It also helps to separate two different jobs here. One is remembering a detail specific to a person — an allergy, a preferred table, something they once mentioned that mattered to them. The other is remembering what worked operationally on the last event for an account, which matters mainly for corporate or repeat group business rather than a single family occasion. Both are real, and both currently live in the documents from the first event rather than in a rolled-up profile. If you run private dining software for groups, this is worth asking any vendor directly: not just whether a host is one record, but what that record is actually built to hold today.

A short summary

A returning host is already the same Party record, not a new one each booking. The documents, signatures, seating, and guest list from a past event stay intact and do not drift. A built feature that automatically surfaces last year's preferences on this year's new booking does not exist yet. Until it does, the finalized BEO is the accurate record of what happened, and bringing a detail forward is a manual step, not an automatic one.