Every capability, and what state it is actually in.

Events are first-class records rather than one global configuration, so a workspace holds as many as you run. Each moves through Draft, Coming Soon, Published, Completed, and Cancelled, and the status governs what the public can see.

Speakers, contacts, and organizations persist across events. Someone who spoke in 2025 and sponsored in 2026 is one record carrying both histories — the thing a stack of separate point tools cannot do.

Separate sections for details, visibility, branding, public page layout, custom domain, tracking pixels, venue and rooms, tickets, CFP configuration, policies, attendee organizations, Slack, Discord, newsletter sync, embeds, the AI agent, its knowledge base, reviews, the Convince Your Boss generator, and a deliberately separated danger zone.

Deleting an event requires typing its name, and the name cannot be pasted — a guard added after a near-miss.

Six presets to start from, plus two site templates that change the public layout rather than only its colours. The theme applies across the whole public event site, not just a header, and carries to next year's event.

One accurate detail: preview opens the public page in a new tab. There is no live editing canvas.

Request a challenge, add the DNS record, verify it in settings. Verification is a real check against the record rather than a checkbox you tick.

Policies render at their own public URLs and are stored as data rather than hardcoded. The FAQ doubles as grounding for the event's AI assistant, so answering a question once answers it in both places.

Coming-soon mode shows a countdown and collects notify-me signups. The password gate covers the entire public surface for internal or invitation-only events.

Creates the organization and first event and picks a starter set of features, so a new deployment is not a blank admin screen.

Section visibility, hero content, and public navigation are editable today. What is being built is direct manipulation: drag to reorder, hide what you do not want, and a footer column editor.

The footer editor is in review now. The wider section builder is specified and not yet started.

Today images are uploaded where they are used, so the same photo gets uploaded repeatedly and there is no way to find what you already have. A shared library with tagging is specified; nothing is running yet.

Early-bird, regular, student, workshop, and virtual tiers, each with their own price, window, and limit.

Group tiers into a ladder and the next price opens when the current one is exhausted, without anyone watching the dashboard at midnight. Inventory is enforced inside a serializable transaction, so a rush cannot oversell a tier.

Checkout is a Stripe hosted session and the webhook confirming payment is signature-verified before anything is written. No card data touches ConferenceOS at any point.

Refunds are processed from the registration record and leave an audit trail with a reason.

Codes have their own manager and are validated on the server during registration rather than trusted from the browser.

Questions are archived rather than deleted when retired, so last year's answers stay readable. Answers feed a registration-answers report and the special-needs roster.

A group order generates claim links. Each seat holder fills in their own details, so you get real attendee records instead of ten copies of the buyer's name.

Buyers who must pay by invoice can request one, with a PO number and billing address; the organizer sends it through Stripe or marks it paid. Invoices download as a PDF from a signed link.

The holder requests a transfer link by email and the recipient claims it. The registration moves rather than being cancelled and rebought.

Approval issues a code to the applicant. Denials can carry a smaller discount instead of nothing, which is the difference between a rejection and an invitation.

Applications can be attributed to affiliate organizations, and approvals can be actioned in bulk.

Point the event at an external ticket page and the public Register and Buy buttons go there; native checkout is refused server-side rather than merely hidden.

Be clear-eyed about the trade. This is a link hand-off, not a sync: those registrations live in that system, so check-in, badges, and attendee messaging cannot see them.

The importer works. It pulls attendees, orders, check-in state, and question answers, deduplicates them, creates claimable profiles, and auto-claims a registration when the email is already verified.

The gap is packaging: it runs as an operator script, not a screen in the admin, so today it needs someone with shell access.

Aimed at the longest forms first — proposals, scholarships, volunteer signup, profile completion. Specified, not started.

Submitters withdraw a proposal themselves rather than emailing to ask. A lighter 'I would like to speak' form exists separately for people not ready to propose a specific talk.

Reviewers claim an invite by token and work a queue. A reviewer can recuse themselves from a proposal and the recusal is recorded rather than handled by convention.

Statuses move individually or in bulk, and the whole submission set exports to CSV.

This is the handoff spreadsheets lose. The session carries the speaker, abstract, and track from the proposal, so nothing is retyped and nothing drifts.

Each speaker gets a profile page and a share page with an automatically generated card image for social posts.

One limit worth knowing: cards generate individually. There is no gallery, no automatic check for broken ones, and no bulk download sized per platform.

Stating this plainly because our own materials have claimed otherwise: the speaker portal route exists but renders an under-construction placeholder. There is no speaker self-service dashboard today.

Speakers are organizer-managed and speaker communication happens over email. The automated 7/3/1-day deadline reminder system described in older documentation is not running either — it was superseded, and its endpoint returns a not-implemented response.

Scoped CFP review, per-track run sheets, and public track listings owned by their chair. Specified, not started.

Status changes do not trigger their own correspondence today; a person sends it. Templating and automatic sends are specified.

Sessions are dragged into place and resized in 15-minute steps, and the resize handle is keyboard-operable rather than mouse-only. Sessions publish individually or in bulk, so a partly-built agenda can go live without exposing the half you are still arguing about.

The schedule check flags room and track conflicts as they appear and never blocks an edit. It reports; you decide.

Venues carry rooms, capacities, and layouts. Offsite and side events are their own records with their own public pages rather than being faked as sessions.

Attendees sign up and cancel themselves; organizers can confirm or cancel on their behalf and export the list. When a seat frees, the waitlist promotes and the attendee is notified.

Reminders ahead of a session go out by email and push notification.

The personal agenda sits in the attendee's event home alongside their pass and onboarding checklist.

Materials are managed per session, so attendees find them where they are already looking rather than in a separate email.

Embeds are token-scoped with a host allowlist and frame-ancestors policy, and the token can be rotated — so a widget can be revoked without touching the schedule.

Reviews are held for moderation before they show. Pull quotes can be extracted from session feedback automatically and then edited, which turns feedback into next year's marketing copy.

Recaps generate in bulk, are editable, and export in a form the newsletter can use. The draft is a starting point, never a publish button.

What ships: virtual sessions with a separate registration flow, attendance recording, CSV registrant import, and a real two-way sync with Beehiiv Webinars including session mapping and reconciliation.

What is thinner than it sounds: Zoom, Livestorm, YouTube Live, StreamYard, WebinarJam, and custom RTMP are supported as stored join and registration links, not API integrations. You paste the link, ConferenceOS routes attendees to it, and attendance arrives by CSV. Beehiiv is the only provider with a live data sync, and recording URLs are pasted by hand.

Benefits are individually status-tracked, so 'logo on the shirt' is a thing that is or is not done rather than an assumption. Add-ons are sold and assigned separately from tiers.

Availability is driven by actual commitments rather than a document someone remembers to update. When it is not ready, the page says so rather than showing stale numbers.

Booths are generated from a venue layout with real map geometry, then held, confirmed, released, or blocked. A hold lasts 30 minutes, so browsing does not lock the floor.

The sponsor picks from their own portal and the organizer can override. Virtual booths are supported for hybrid and online events.

This is the sponsor-facing half of the deal and it is fully built, unlike the speaker equivalent. Sponsors upload assets, mark benefits complete, claim add-ons, and manage their own comp-ticket allocation.

Lead disclosure is consent-gated: a sponsor sees attendee details only where the attendee explicitly granted data sharing, and that consent can be withdrawn at any time.

Allotments are allocated, revoked, and marked sent from the portal. Claim tokens are hashed and expire. Recipients claim their own seat, so you get real attendee records.

Meetups, user groups, and media partners get their own records and their own public page rather than being squeezed into the bottom sponsor tier.

Today a sponsor's access is set up by the organizer. The planned version is self-serve from the moment the deal closes.

Two related gaps are specified with it: sponsors and partners hold a single embedded contact rather than multiple named people, and logos are pasted as URLs rather than uploaded.

An offline-capable scan app for booth staff. This is a real intention with no scheduled work behind it, which is worth saying rather than implying it is close.

There is a dedicated check-in app at its own URL as well as the console view, so a volunteer can work the desk without the rest of the admin.

Undo matters more than it sounds. The common desk error is checking in the wrong similarly-named person, and reversing it needs to be one click.

Detectors flag duplicate scans, overlapping sessions, impossible attendance, late entry, and early exit. Flagged records go to an exception desk where a human corrects them.

This exists because attendance feeding continuing-education credit has to survive being audited.

The spine ships: credit bodies, provider approvals, programme roles, a pre-flight readiness check, and generated attendee-facing copy explaining what they earned.

What does not exist is the artifact at the end — issued certificates, learner transcripts, and third-party verification. You can run a compliant programme and evidence it; you cannot yet hand the attendee a certificate from here.

Volunteer needs are defined per event with a public signup page and an organizer approval workflow.

Vendor records connect to the expense side, so the AV company is one entity rather than a recurring line item.

A feature flag for kiosk check-in exists in the codebase with nothing behind it. Treat this as not started.

Specified, with a flag reserved and no surface built. For an event with a code of conduct this is a real gap, and we would rather say so than let a flag name imply otherwise.

Onboarding is a checklist rather than an email sequence, so someone who joins late can catch up in one place.

A progressive web app rather than a store download, so there is no install friction and no app-review cycle before the event.

Push is opt-in per attendee and subject to the same consent record as email and SMS.

Off unless the organizer enables it, and off per attendee unless they opt in. Field-level visibility is the attendee's choice rather than an all-or-nothing toggle.

Each attendee has a connect code they can regenerate if it leaks. Connecting requires the scan, so there is no way to enumerate people you have not met.

Blocking is immediate and unilateral. Reports become tracked cases in an organizer moderation queue with a resolution workflow, rather than an email someone might miss.

Reviews are held for moderation and can be highlighted onto public pages. Nothing publishes itself.

Tracking is real: referral codes carry clicks and conversions, and a conversion is credited when the Stripe webhook confirms the purchase.

The reward is karma points and nothing else. There is no reward configuration, no tiers, and no payout surface, so do not read this as an affiliate programme.

Organizers define badges and karma activities today, with sensible defaults to start from, and the ledger records what people earn.

The honest gap: there is no attendee-facing surface. Nobody can see their own badges or karma, which means the feature currently rewards people privately. It is configured and waiting for its display.

The privacy groundwork it needs — opt-in directory, per-field visibility, governed messaging — is already in place. The matching and in-app booking are not built, and no work is currently in flight.

Audiences come from saved segments rather than exported lists, so a send always reflects the current state of the event. Every broadcast is previewed against a live count first.

Segments are queryable, exportable, and pushable to the CRM. They are also exposed as agent tools, so an assistant can evaluate one without being handed the attendee list.

Attendees manage email and SMS preferences from a signed link that needs no login. The preference is enforced at send time, and an opt-in-health report shows where consent is thin.

Delivery callbacks are signature-verified, and an unconfigured webhook secret causes a refusal rather than acceptance of unsigned traffic.

Twilio is fully integrated with signature-verified inbound handling, SMS contact verification, SMS opt-in as a first-class consent channel, organizer-initiated broadcasts, and the event-day morning brief.

One precise limit: automatic session reminders go by email and push, not SMS. There is no SMS reminder-campaign builder.

Beehiiv is the deepest of the three, with field mapping, signup routing, bulk sync, and webinar attendance sync. Kit and Mailchimp are implemented as contact sync.

Configured per event with an incoming webhook and an on/off switch. No platform-level credentials required.

Several automations run on a fixed schedule today — session reminders, morning briefs, SLA breach alerts, task due reminders. What is planned is letting an organizer author their own triggers and actions.

Creative is generated from real sessions, speakers, and dates rather than from a blank prompt, then exported or pushed to a connected channel. Prohibited-word guards run over generated copy.

These are fixed sequences defined in code. Making them editable and configurable by the organizer is specified separately and not yet built.

Each channel connects by OAuth per event and reports its own state — not configured, disconnected, connected, or error — rather than failing silently. Campaigns are pushed and their status updated from the promotions surface, and spend syncs back for ROI reporting.

Per-channel on/off toggles are specified and not built, so today connecting a channel is the switch.

Both first and last touch are stored on the registration itself and indexed, feeding a marketing-attribution report and a paid-promotion ROI report. 'Did that campaign sell tickets' has an answer rather than an opinion.

Invitees are imported by CSV and claim by token, so an invitation produces a real attendee record rather than an untracked email.

Configured per event by the organizer and generated for the attendee. It is among the most-used pages on a conference site and almost never built.

First-party tracking against your own event, so it survives ad blockers and does not require a consent banner for someone else's script.

Paid traffic currently lands on the event home or the registration page. Dedicated campaign pages are specified; a flag exists with nothing behind it.

Mail is ingested and routed into queues. Replies are threaded, support CC participants and reply-all, so the conversation stays in one place.

A presence indicator warns when someone else is already replying — the small thing that stops two people answering the same person differently.

Breach and idle-case checks run on a schedule rather than depending on someone watching the queue.

Notes support @mentions and stay internal. Templated auto-acknowledgement can be switched on per queue.

Rated through a signed link with no login, which is the reason the response rate is worth anything.

The assistant answers from the event's schedule, FAQ, venue, and knowledge base rather than from general knowledge, and can be given a persona and avatar per event. It is enabled per event and off by default.

Prompt-injection guards run on the input, and the assistant answers rather than acts — it cannot change the event.

Ingestion is built and running. What remains is mapping particular addresses to particular queues, which today is wired rather than self-serve.

The record includes support history, so whoever picks up the next conversation can see the last one. Organizations roll their people up.

Pipeline stages, tasks with owners, notes, and tags, all attached to the same records the event uses.

Deliverables generate from templates — a speaker pack, a sponsor package — rather than being typed per deal, and chase themselves on a schedule.

The preview shows what would change and nothing is written until it is confirmed, which is the difference between an import and an accident.

It is the most valuable question at the start of a cycle, and the logic exists and works.

It exists only as an agent tool. There is no organizer screen for it, so you get the answer by asking your assistant rather than by opening a view.

One-way export, rate-limited and batched. Monday.com works the same way, configured per event with a board id.

The pieces exist separately — pipeline, deliverables, support ingestion. Joining them into a sales workspace is specified and not started.

Both are real intentions with no scheduled work and no code behind them. Until they exist the honest routes are the REST API, CSV export, or the Twenty and Monday.com adapters.

Tasks carry notes, @mentions, and file attachments, and due-date reminders run automatically. A per-event team page shows who is on it.

Preview what a playbook will create before creating it, then generate the project. Task dates reschedule in bulk when the event date moves.

Templates are curated system defaults today. There is no path for an organizer to author and save their own.

Playbooks produce tasks; they do not yet compute the timeline from the event date. Making the plan date-aware is specified.

Revenue realization is reported separately from bookings, so committed-but-unpaid sponsorship does not read as money in the bank.

Expenses are also reachable through the agent tools, so a budget can be populated by an assistant working from your invoices — behind a separate permission that ticket and schedule access does not grant.

Processed through your own Stripe account. No card data is stored by ConferenceOS at any point.

Attendees, no-shows, headcount, ticket sales, registration velocity, revenue summary and realization, invoices, expenses, CFP funnel, speaker readiness, session popularity and feedback, sponsor commitments and benefit fulfilment, sponsor comps, scholarships, volunteers, vendors, check-in flow, marketing attribution, paid-promotion ROI, broadcast performance, opt-in health, special-needs roster, registration answers, and broken outbound links.

Reports share by tokenized link, so a board member can read one without an account.

Refund windows are written into policy text today. Deriving them from the event date is specified.

Model-neutral: Claude, ChatGPT, or anything else that speaks MCP. Reads cover the event, schedule, speakers, registrations, venue, FAQ, sponsors, saved segments, CFP submissions, and expenses. Writes cover speakers, CFP status, event details, sessions, FAQ entries, CRM notes, tasks, tags, pipeline stages, and expenses.

No single connection sees every tool. Tools are filtered by the role on the key: a read-only key sees only reads, each administrator role adds the writes for its scope, and only a system administrator sees everything.

Three roles escalate cumulatively: speaker administrator, event administrator, system administrator. A key with no role is read-only.

An event-pinned key is refused if it names a different event, and infers the event when one is not given. Writes addressed indirectly — updating a speaker via a session id — re-check scope after loading the record, so pinning cannot be walked around by addressing something sideways.

Budget writes need a separate permission on top of the role. Being able to edit the schedule does not confer being able to edit the money.

CRM and expense write tools preview by default, returning the rows that would change, and commit only on explicit confirmation. Imports are idempotent and never overwrite an existing record.

Stated precisely, because the distinction matters and our own copy used to blur it: core content writes — speaker, CFP status, event, session create and update, FAQ — apply directly rather than previewing. They are fully audited, but they are not dry-run by default.

Standards-based discovery and dynamic client registration with PKCE, so a compliant client can find and connect to the server on its own. Token exchange mints a short-lived key rather than a permanent one.

A human connecting this way is capped at event-administrator scope and can never reach the system tools, whatever their role elsewhere.

Calls are attributed to either the API key or the specific human behind it. A denylist hard-blocks shell, file, deployment, secret, schema, and billing tool names even if one were ever registered by mistake.

Events, event detail, check-in, FAQ, registrations, rooms, scholarships, session reviews, and stats. Uniform response envelope, key authentication, scope enforcement.

Worth knowing before you plan against it: this is not full CRUD. There are no collection endpoints for sessions, sponsors, speakers, CFP, communications, or reports. For those, the MCP tools go further than the REST API does.

Everything generated is a draft an organizer edits and approves. Nothing publishes itself, and prohibited-word guards run over generated marketing copy.

Stating this plainly because this site claimed otherwise until recently: ConferenceOS verifies inbound webhooks from Stripe, Resend, and Twilio, but does not publish outbound webhooks to your systems. To react to changes today, poll the REST API or use a CRM adapter.

Authorization is enforced server-side per route. Authenticated users who lack permission land on an unauthorized page rather than being bounced to sign-in, which is a meaningfully less confusing failure.

On SAML: ConferenceOS authenticates through Clerk, so enterprise SAML depends on your Clerk plan and configuration rather than on anything we ship. We would rather point at that than imply we built it.

Erasure anonymizes in place rather than hard-deleting, so financial and order integrity survives a valid erasure request. Requests are tracked as records rather than handled ad hoc.

Sponsor lead disclosure reveals only attendees who explicitly granted it, and withdrawal takes effect immediately. Consent is checked at the point of use rather than at the point of collection.

Coverage spans registration, group and transfer flows, sponsor claims, CFP, volunteers, scholarships, media applications, reviews, verification, contact, and the support chat. The agent endpoint is limited to 60 requests a minute per principal by a limiter that survives a restart.

Peer messaging has report and block with an organizer queue; reviews and testimonials are held for moderation. Agent guardrails and a prohibited-word list run over model input and generated copy.

Human and agent actions land in the same log, attributed to the actor. The per-event activity feed is the readable view of it.

The hardening check inspects the deployment's own configuration and reports what is unset or unsafe, rather than assuming it was handled at install.

Demo mode is read-only and banners itself clearly. Test mode puts payments into Stripe test mode with a visible indicator, so nobody demonstrates with real money by accident.

Being specific rather than reassuring: OAuth tokens and webhook URLs are encrypted at rest today. Attendee personal data is not. It sits in a managed Postgres database with storage-layer encryption and access controls above it, but there is no field-level encryption and we will not describe it as though there is.

Route-level authorization is real and enforced in production today. What does not exist is a single default-deny spine — permission is asserted route by route, which is harder to audit and easier to miss on a new page.

Related and also planned: distinct role-specific views for every person type, including volunteers, press, and staff.

This site previously described a config backup feature. It does not exist — there is no configuration export, snapshot, restore, or event-clone in the product. Database-level point-in-time recovery is an infrastructure practice for the hosted deployment, not something you can drive.

The version of a deployment is visible in the admin, and a tenant upgrade rehearsal and promotion pipeline exists. One-button update and deployment-wide integration key management are specified and not built.

ConferenceOS is slated to be open-sourced under Apache 2.0.