Turn scattered event requests into one reliable operating path.

Starlight Event Services studied two operating areas: inbound inquiry follow-up and event intake, documents, and scheduling. The current stack is practical and familiar: Gmail, a website contact form, phone notes, social messages, Google Forms, Google Sheets, Google Drive, Google Calendar, DocuSign, PDF proposals, and client/vendor email threads. The team prefers to keep the Google Workspace foundation where practical and avoid a large platform replacement as the first move.

The two pain points are connected. New event requests arrive through several channels, then staff manually add details to a lead tracker and coordinate the first response. Once a prospect becomes an active event, coordinators rebuild the event packet from forms, email, contracts, calendar notes, Drive folders, and planning sheets. Starlight estimates this creates 8-12 hours per week of avoidable work at a blended $150/hour, which creates a gross monthly value signal of $5,220-$7,830 before tool costs or implementation time.

The core issue is not that Starlight lacks software. The root problem is that there is no single controlled path from inquiry to event packet. Gmail, forms, Sheets, Calendar, Drive, and DocuSign each hold part of the truth, but none of them currently acts as the operational record for the full handoff. That is why the same details get collected more than once, why a promising inquiry can wait in the wrong channel, and why coordinators have to search before they can answer confidently.

The evidence is strong enough to move into a focused pilot because multiple interview answers point to the same operating pattern. The solution can be sharpened further after Starlight traces one live inquiry-to-event path and confirms exactly where details are duplicated, missed, or updated late.

Starlight should start with an off-the-shelf workflow pilot rather than a platform replacement. The first move is to define one intake-to-event operating path: every new inquiry should become one tracked record, every required event detail should have a defined field, and the first-response owner should be clear before the request waits on availability, pricing, or operations input. This is mainly a workflow and configuration effort using the current Google stack, supported by a structured intake tool and a lightweight automation layer.

The first phase-two move is to expand the validated intake path across the highest-volume event types. This belongs after month one because the team needs proof that the required fields, owner rules, and handoff notifications work on one real path before standardizing more events. The expected business effect is faster first response and less coordinator rework across a larger share of the pipeline.

The second move is to add operating governance. Starlight should define who owns lead status, who approves event-packet changes, where final guest count lives, how contract status is checked, and how late changes are flagged. This is not a new-tool move. It depends on the pilot showing which fields and status rules actually prevent repeated questions and stale versions.

The third move is a conditional custom-build assessment. The off-the-shelf pilot should show whether Airtable plus automation can provide the event-level visibility the team needs. If it cannot, Starlight should scope a bespoke event operations system that preserves the tools that already work while centralizing event status, handoff history, and change control. This is a second-phase opportunity supported by the studied pattern, but it still requires technical scoping, cost review, security review, and a clear owner for long-term support.

The selected but not deeply studied area is broader cross-tool handoff. It should remain in the roadmap as a follow-up assessment rather than a near-term recommendation. The same pattern may affect vendor coordination, post-event billing, or staffing workflows, but this report only studied enough evidence to recommend action on inquiry routing and event intake first.

The evidence supports a pilot-first decision. The time signal is meaningful: 8-12 hours per week at $150/hour creates a weekly gross value signal of $1,200-$1,800 and a monthly gross value signal of $5,220-$7,830. That is large enough to justify action, but not enough to skip the proof step. The report can see the burden and the tool stack; it cannot yet see exact form volume, event-type variation, vendor costs, user permissions, or how much rework will remain after the first workflow is standardized.

The tool-cost posture is likely modest for a first pilot using Tally, Airtable, and Zapier, but exact pricing and plan limits still need review. ROI is plausibly favorable if the pilot removes repeated intake, manual copying, and delayed first-response work. A bespoke operations system could still be commercially justified, but only if the off-the-shelf path cannot create the control Starlight needs without excessive workaround complexity.

The value estimate is directionally useful for deciding whether to pilot, not yet a final net ROI calculation. The financial model should be tightened after Starlight measures one pilot month, records time spent before and after, confirms tool pricing, and decides whether the remaining exceptions are better handled through workflow rules or a bespoke build.