Everything runs on one record. Here is what that buys you.

Every tool in this category answers questions you already knew to ask, by making you build the report that asks them.

Oracle reads your leads, events, event orders, proposals, tours, invoices, payments, client comments, and inbox threads, and answers in a sentence. It will also draft the reply, redline the proposal, or open the support case, and then stop, because a change it proposes is a diff you approve, never a change it made.

• Reads across ten record types, not one dashboard
• Proposes changes as a diff and applies nothing itself
• Treats every record, email, and note as untrusted input it must not obey

How it actually worksTwenty-eight tools. It can read a client comment thread, and it knows that a proposal record may carry an older copy of the same text and refuses to answer from it.

The hour after a planning call is the hour you spend transcribing your own notes into six fields you half remember.

Record the meeting and Everbook transcribes it, reads it against the event, and hands you a list of the changes it heard: the count moved, the ceremony shifted, they want the second bar after all. You tick the ones that are right and the event takes them.

• Recording to transcript to a reviewable list of proposed changes
• Nothing is applied until you accept it, item by item
• A PDF summary of the meeting for the file

How it actually worksTranscription runs server-side. The API key is never in the browser bundle, and a build check fails the deploy if any key reaches the compiled assets.

The tenth time you add the same three tasks to the same kind of event, no software has noticed. Automation exists, but only if you stop and build it.

A pass over your own audit history looks for the same action, at the same point, on the same kind of event. When it finds one it says so in a sentence, shows you the events it learned from, and offers to turn it into a workflow.

• Learned from your audit stream, not a template library
• Shows the evidence: which events, how consistently
• Accept, dismiss for the season, or never ask again

How it actually worksA pattern needs the same action type, the same relative timing, the same target, and the same event type. Thresholds are data you can tune, not a constant buried in a comparison.

Every vendor keeps their own copy of the wedding, and the differences between those copies are what goes wrong on the day.

Everbook holds one event order, the BEO if your trade calls it that, and gives each vendor the section that is theirs. The florist fills in floral, the DJ fills in music and MC, and the planner approves what the couple sees. Change the guest count once and every section that depends on it moves.

• Per-trade vocabularies: Floral, Food, Music & MC, Photo & Video, Planning, Bar, Rentals
• Field-level visibility between operator, vendor, and couple
• Gates and signatures, so an approval is a record and not an email

How it actually worksVisibility is field-level, not page-level. A field can be client-facing, vendor-facing, internal only, or required only when another field says so, and the trades whose fields exist have hundreds authored, not a generic form.

Sourcing is six emails, six threads, six formats, and a spreadsheet you build to compare them.

Say what you need once and send it to as many operators as you like. Each answers on their own, and you read the replies against each other instead of against your memory of the last one.

• One request, many operators, answers in one view
• Recipients never learn who else was asked
• Replies attach to the event, not to an inbox

How it actually worksThe requester sees every recipient. The recipients see none of each other. That asymmetry is enforced by two separate routers, so a recipient asking for the request they were sent cannot reach the list of who else got it.

The event went well, the invoice went out, and the two do not match. Nobody finds out, because finding out is a job.

Everbook lists what was delivered and never billed, with the reason each line went out the door: comped, waived, or simply missed. Then it reconciles every payment against the processor, so a payment that never landed cannot sit in your books as one that did.

• Delivered-but-unbilled, with a reason on every line
• Payments matched line by line against the processor
• Change orders, deposits, and balances on the event record

How it actually worksReconciliation surfaces unattributed rows, money that arrived with nothing to attach it to, which is the category most likely to be real loss and the one a per-workspace filter would hide entirely.