One event, several manual handoffs
Room bookings began with a two-part fillable PDF emailed to the facilities team. Staff then reserved the room in Eptura, created an A/V ticket for IT, and created facilities work orders for room setup.
The request already contained much of the information those teams needed, but someone still had to interpret it and carry it into each system. Booking the space and arranging the work to prepare it depended on that manual coordination.
Finding the bottleneck
The bottleneck was the handoff between the request and the systems used to fulfill it. Digitizing the PDF would only address the intake step; the larger opportunity was to connect room availability, event details, room configuration, facilities work, and IT support.
The workflow also needed to reflect how rooms are used. Setup and teardown require time outside the event itself. Combined spaces occupy multiple physical rooms. Equipment already installed in a room is different from equipment IT needs to deliver. Those distinctions needed to be part of the process.
What I built
I built a custom web application that collects the event requirements in one place and connects the submission to Eptura and Freshservice.
The form captures event details, date and time, requester and host information, department, attendance, room and layout, A/V needs, and supporting notes. Users can view availability and choose supported room configurations before submitting.
On submission, the application records the request, checks for conflicts, reserves the room in Eptura, and creates the applicable Freshservice requests. Facilities receives setup and breakdown work orders, with event-support requests added when selected. IT receives an A/V request when the booking calls for requested equipment, presenter coordination, or specified technical setup support.
Booking and service-request references are retained together, giving the requester and support teams identifiers they can use to follow up.
Built around the details that matter
These controls make the automation practical across several systems that can fail independently.
Setup and teardown time
The application reserves the event window plus the selected host buffers. This accounts for an Eptura API limitation that otherwise leaves those periods unreserved. Tickets retain the actual event times and the supporting setup information.
Combined rooms
Supported configurations reserve the individual rooms they occupy. If a booking fails partway through, the application attempts to release reservations already created and identifies any that remain held for follow-up.
Conflict checking
Server-side checks run before new reservations are created. The workflow stops when it cannot read the calendar rather than assuming the room is available.
Existing reservations
A supported claim workflow can attach the facilities and A/V request to an eligible existing Eptura reservation instead of creating another booking for the same event.
Useful IT requests
The equipment model distinguishes what is already in the room from what must be delivered. Installed inventory alone does not trigger an IT ticket; explicit support requirements determine whether one is needed.
Partial-failure handling
The request is recorded before external reservations are created. If the room is held but ticket creation fails, the application records the available references, explains the incomplete result, and attempts to alert the service desk.
Built for staff to maintain
Authorized administrators can create, rename, describe, categorize, and archive A/V options, assign them to rooms, and mark them as already installed, requestable, or unavailable. They can also change option order, supporting notes, dependencies, and supported Freshservice equipment mappings.
Combined-room A/V configurations can derive their equipment from member rooms or use an explicit configuration. Updating an individual room can therefore flow into the combined configurations that use it.
The department/program dropdown is also editable through administration, including adding, renaming, removing, and reordering choices.
These supported changes are saved as application data. Staff can keep equipment and department information current without editing source files or deploying a new version. Room identities, integration credentials, and broader workflow changes remain separate implementation concerns.
Supported changes after submission
Requesters can retrieve a booking using its confirmation number and booking email, then update supported planning details before the edit cutoff. Changes are saved to the booking record, with notes added to the linked facilities ticket and existing IT ticket.
Changes to the date, time, room, or cancellation are routed to the facilities team as requests rather than automatically moving the reservation. A server-enforced cutoff ends self-service editing when the event is less than ten calendar days away, directing later changes to facilities.
This gives requesters a way to maintain event details while keeping reservation changes and late adjustments with the team responsible for coordinating them.
What changed
The process moved from a PDF-and-email intake followed by manual system entry to a connected booking workflow. Request details now drive the room reservation and the applicable facilities and IT requests.
The facilities team's role shifts toward handling exceptions and coordinating the event rather than recreating the original request in each system. IT receives requirements that distinguish installed equipment from requested work, and administrators can maintain supported options as rooms and departments change.
The result is a more repeatable path from requesting a room to arranging the work needed to prepare it, with linked records and explicit handling when a step cannot be completed.
My contribution
I mapped the PDF-and-email process into a structured web workflow and built the form, availability integration, booking orchestration, Freshservice field mapping, persistent request records, return-to-edit flow, and administrative configuration tools. I also implemented and tested conflict handling, combined-room behavior, equipment rules, and failure scenarios.