WBSP
ProvidersDocsSign in

evm

A variant of Event Venue Management.

View the interactive variant page →

Event Venue Management

Part of the worlds-biggest-software-project initiative.

An AI-native, open-source platform for managing event venues — bookings, catering coordination, AV, and invoicing — without the lock-in or six-figure contracts of incumbent enterprise tools.

Event Venue Management is a unified system for venue operators to handle space booking, customer relationships, contracts, catering, and post-event reporting. It targets independent venues, hotel and restaurant event departments, convention centres, and corporate or university facility teams who need depth without the cost and complexity of legacy enterprise platforms.

Why Event Venue Management?

  • Hospitality-focused incumbents like Tripleseat are deep but ill-suited to non-hospitality venues, leaving conference suites, corporate campuses, and university event offices underserved.
  • All-in-one platforms such as Planning Pod bundle 20+ tools but can feel overwhelming for small-to-mid venues.
  • Enterprise platforms (Momentus, Ungerboeck) come with high cost of entry and lengthy implementation cycles, with six-figure annual contracts.
  • General project management tools (e.g. ClickUp) are cheap but offer no native venue-specific features.
  • Specialised tools force trade-offs: Caterease wins on catering but is weaker on general venue booking; Skedda has excellent self-service UX but limited catering and AV coordination.

Key Features

Booking and Space Management

  • Event booking and venue availability management
  • Space and room layout with floor plan management
  • Self-serve customer booking portal
  • AV and technical equipment management

Customer and Contract Workflow

  • Customer CRM and lead tracking
  • Contract and agreement management
  • Invoicing and payment processing
  • Event timeline and task management

Catering and Operations

  • Catering and menu integration
  • Catering workflow and production scheduling
  • Automated BEO (Banquet Event Order) generation
  • Sustainability and carbon tracking

Intelligence and Reporting

  • AI lead qualification and proposal generation
  • Dynamic space pricing and revenue management
  • Post-event reporting and analytics
  • Hybrid event (in-person + virtual) coordination

AI-Native Advantage

AI is used to qualify inbound leads, propose available dates, and generate personalised proposals without sales staff involvement. Natural-language event briefs are converted into structured BEOs covering room configurations, catering, AV, and staffing. Dynamic pricing adjusts room rates based on demand, seasonality, competing local events, and time-to-event urgency, while post-event AI analysis aggregates feedback, staff notes, and financials to surface operational improvements and upsell opportunities.

Tech Stack & Deployment

The system is expected to align with relevant industry standards including APEX/ANSI Event Industry Standards, iCalendar (RFC 5545) for availability sync, PCI DSS for payment processing, AV-over-IP standards (SDVoE, AVB/TSN) for AV modules, and GDPR / CCPA for attendee and client data. Deployment modes and SDK details are to be determined as specification work proceeds.

Market Context

The event venue management software segment sits within a broader event management software market estimated at USD 15.2 billion globally in 2026. Entry-level tools (HoneyBook, Planning Pod) start at $19–99/month, mid-market platforms (Tripleseat, Skedda) typically run $300–1,500/month on custom pricing, and enterprise platforms (Momentus, Ungerboeck) are six-figure annual contracts. Primary buyers are independent event venues, hotel and restaurant event departments, convention centre operations teams, corporate campus facility managers, and university event offices.

Want to just try the product without setting anything up? See preview/ for a standalone Docker image with everything pre-loaded — one docker run command and no other local setup.

Running the API locally

The api/ directory contains the core venue & booking backend (see specs/001-venue-booking-mvp/) plus CRM/leads and calendar sync (specs/002-crm-leads-calendar-sync/), contracts, invoicing & payments (specs/003-contracts-invoicing-payments/), the AI-native layer — lead scoring, BEO generation, dynamic pricing (specs/004-ai-native-layer/) — domain events, webhooks & reporting (specs/005-domain-events-webhooks-reporting/), and an MCP server, sustainability tracking, and GDPR/CCPA data-subject workflows (specs/007-mcp-sustainability-compliance/). To run it locally:

cp .env.example .env            # fill in EVM_JWT_SECRET at minimum
docker compose up -d db redis
cd api && uv sync --group dev
uv run alembic upgrade head
uv run uvicorn evm.main:app --reload

To also run the external-calendar-sync background job (only needed for two-way Google/Microsoft/CalDAV sync — the rest of the API works without it):

uv run arq evm.workers.calendar_sync_worker.WorkerSettings

Configuration is env-driven (EVM_ prefix); see .env.example for every supported variable — database/Redis URLs, JWT settings, the optional SMTP settings used to deliver team-invite emails (invites are logged instead of emailed when SMTP isn't configured), the optional Google/Microsoft OAuth client settings (only needed to enable two-way calendar sync; the read-only .ics feed and CalDAV need neither), and the Stripe settings (EVM_STRIPE_SECRET_KEY, EVM_STRIPE_WEBHOOK_SECRET) needed to accept real card payments on invoices, and the LLM settings (EVM_LLM_PROVIDER, EVM_LLM_API_KEY) needed for lead scoring and BEO generation to actually call an AI provider — none of these are required to run the rest of the API, and the automated test suite mocks the Stripe and Anthropic HTTP APIs entirely.

Lead scoring and BEO generation run as background jobs on the same worker process used for calendar sync — no separate service is needed, but the worker must be running for either feature to complete (an unscored lead or a generating BEO stays in that state until it does). The same worker process also dispatches webhook deliveries (polling every ~10 seconds) and runs due scheduled reports (once daily).

Webhook subscriptions and the domain event catalog are documented in spec/asyncapi.yaml, generated from api/src/evm/events/catalog.py via:

cd api && make asyncapi

An MCP server exposing six venue tools to AI agents (check_availability, find_spaces, quote_price, qualify_lead, generate_beo, create_booking) is mounted at /mcp on the same api service — no separate process. Issue a scoped, revocable credential via POST /agent-credentials (role: viewer for read-only tools, manager or above for tools that create/modify data) and use the returned token as the MCP client's bearer credential; see specs/007-mcp-sustainability-compliance/contracts/mcp-tools.md.

Loading demo data

To populate a destination with realistic-looking venues, leads, bookings, contracts, and invoices for a demo recording or screenshot, use the seed script (specs/009-demo-data-seed-script/). It never runs against a destination unless that destination's own env file opts in with EVM_SEED_ALLOW=true — add that to .env for local, or to .env.<destination> for any other named destination:

cd api
uv run python -m scripts.seed_demo_data --destination local --profile small

Add --profile full for a larger dataset, or --yes to skip the confirmation prompt when re-seeding a destination that already has demo data on it. The script prints the demo owner's login on success. See specs/009-demo-data-seed-script/quickstart.md for full usage.

Run the test suite (requires Docker, since integration tests run against a real PostgreSQL instance via testcontainers — see the constitution's Principle III):

cd api && uv run pytest

Running the frontend locally

The frontend/ directory contains the operator dashboard and self-serve public booking portal (see specs/006-frontend-operator-dashboard/) — a Next.js app that talks to the api/ service above. To run it locally (with the API already running per the previous section):

cd frontend
npm install
cp .env.local.example .env.local   # fill in API_BASE_URL/NEXT_PUBLIC_API_BASE_URL/
                                    # NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY
npm run generate:api               # regenerate lib/api/schema.ts from ../spec/openapi.json
npm run dev                        # http://localhost:3000

API_BASE_URL is the server-only base URL the app's Server Components/Route Handlers use to call the API with the httpOnly session cookie; NEXT_PUBLIC_API_BASE_URL is the same backend exposed to the browser for the unauthenticated /book/** public portal pages, which call the public availability/booking endpoints directly; and NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY is the Stripe publishable key used by the deposit-payment PaymentElement on the public portal (safe to expose — publishable keys are not secrets). Regenerate the API client (npm run generate:api) any time spec/openapi.json changes, and commit the result alongside the schema change per the constitution's Development Workflow gate.

Run the test suites:

npm run test        # Vitest unit tests
npm run test:e2e    # Playwright, against a real running api/db/redis stack — see
                     # specs/006-frontend-operator-dashboard/quickstart.md

Build for production:

npm run build
npm run start

Project Status

This project is in the research and specification phase.
Contributions, feedback, and domain expertise are welcome.

Contributing

We welcome contributions from developers, domain experts, and potential users. See CONTRIBUTING.md for guidelines.

Important: All contributions must be your own original work or clearly attributed open-source material with a compatible licence. Copyright infringement and licence violations will not be tolerated and will result in immediate removal of the offending contribution. If you are unsure whether a piece of code, text, or other material is safe to contribute, open an issue and ask before submitting.

Licence

Licence to be determined. See discussion for context.