Inspiration
Large Indian weddings and multi-day events are still operated through disconnected spreadsheets, WhatsApp threads, calling teams, cab lists, hotel rooming sheets, and gate registers. The failure is rarely one missing tool; it is the lack of one current guest timeline that tells an operations team what needs attention next.
What it does
EventPilot AI brings guest operations into one workspace:
- guest and group management;
- public RSVP collection plus voice/IVR outreach;
- callbacks and follow-up queues;
- cab capacity and guest transport assignments;
- hotel inventory and room assignments;
- QR-based arrival and check-in tracking;
- live event dashboards.
For OpenAI Build Week, we extended the existing MVP with Event Readiness Radar. It combines live RSVP, outreach, transport, lodging, and check-in records into a single readiness score. More importantly, it ranks operational risks, shows the evidence behind each risk, recommends the next action, and links the operator directly to the workflow that can fix it.
Examples include urgent pending RSVPs, unresolved callbacks, transport or lodging capacity gaps, unassigned confirmed guests, and low check-in coverage during a live event.
What is new for Build Week
EventPilot existed before the hackathon. The new work completed during Build Week is:
- a cross-module readiness snapshot over six operational data sources;
- an event-phase-aware scoring and risk engine;
- a new authenticated readiness API;
- a dashboard experience with metrics, top risks, evidence, next actions, refresh behavior, and one-click Fix links;
- unit and integration coverage plus production-build verification;
- clear documentation separating the pre-existing MVP from the dated Build Week extension.
The readiness engine is deliberately transparent and has zero OpenAI API runtime cost. It uses deterministic rules over EventPilot's own records and makes no external AI calls. Codex was used as the development environment.
How we built it
The backend uses Node.js, Express, Prisma, and PostgreSQL, with AWS Lambda/serverless support, Amazon SQS, DynamoDB audit feeds, and Plivo voice workflows. The operations dashboard uses Next.js, React, TypeScript, and Tailwind CSS.
The readiness API calculates weighted RSVP completion, follow-up health, transport coverage, lodging coverage, and time-aware check-in coverage. Critical capacity or data gaps override the score band, which keeps the result explainable and operationally safe.
Challenges
The hardest part was not generating another summary. It was turning data owned by separate modules into one consistent snapshot without hiding the evidence. We also had to distinguish a true capacity shortage from an assignment backlog and avoid penalizing check-in before an event starts.
What we learned
Operators need prioritized, reversible actions more than vague predictions. A simple score only becomes useful when every risk explains why it exists and where to fix it. We also learned that a pre-existing product needs a sharply documented, independently testable hackathon delta.
What's next
Next we would add role-specific readiness views, change history for every score, configurable thresholds by event type, multilingual operator alerts, and post-event operational retrospectives.
Built With
- amazon-sqs
- aws-lambda
- codex
- dynamodb
- express.js
- next.js
- node.js
- plivo
- postgresql
- prisma
- react
- tailwind-css
- typescript