Flynn Townsend
Case Study · Function.

Case study · Function.

Function. · Event Sales Pipeline CRM

A B2B sales pipeline for hotel event enquiries that I built end to end, from an empty repo to a deployed cloud app.

Stylised poster of Function.: a kanban pipeline with New, Proposal and Booked columns above a revenue analytics strip
Stylised poster in the app's own design language (espresso and champagne gold). The deployment sits behind sign-in, so there are no screenshots of it here.
01 The problem

The problem

Hotel event enquiries end up scattered across inboxes and ad-hoc spreadsheets. Nothing keeps track of which enquiry is at which stage, what was last said to whom, or how quickly the first reply went out, and in event sales the speed of that first response is often what wins or loses the booking. I wanted to see what it takes to fix that properly.

02 The solution

The solution

I shaped it around the whole enquiry-to-booking lifecycle: a Today screen with stat tiles and an action queue, a kanban board by stage with hover quick-advance, an enquiry detail view with a timestamped activity log and a clickable stage stepper, CSV import and export, and an analytics dashboard covering win rate, booked revenue, lead sources and first-response-time against a two-hour target.

It is deployed on Vercel with a Supabase backend and gated by email sign-in. It is not a hotel system and it is not in use at the hotel: I built it for myself, to understand the enquiry-to-booking lifecycle by building the tool that would run it. A walkthrough is available on request.

03 Technical breakdown

Technical breakdown

  • Modern full stack

    Next.js 16, TypeScript and Tailwind CSS v4, deployed on Vercel with a Supabase (Postgres) backend in Sydney. The whole enquiry lives in a jsonb column, so the app's data model can evolve without schema migrations.

  • Swappable data layer

    All persistence goes through one store adapter. With no backend configured the app runs fully local on localStorage; adding Supabase sync was literally one new file, and first cloud load auto-migrates existing local data up, once.

  • Security by design

    Row-level security scopes every row to its owner, the client ships only a publishable key, and a strict no-client-PII rule is built into how the tool is used. A deliberate piece of security-conscious design, not an afterthought.

  • Verified before use

    Every flow was verified before use: sign-up and email confirmation, localStorage auto-migration into Postgres, and stage advances round-tripping to the database with their activity entries. A timezone bug (UTC dates shifting Sydney dates back a day) was found in verification and fixed with local-time date helpers.

  • Configured for change

    Stages, lead sources, event types, lost reasons and the response-time target all live in one config file; the data model in one types file; design tokens in one CSS block. Built expecting the workflow to change.

04 Why it exists

Why it exists

Dispense proved I can build something a team trusts with real money. Function. is the next step for me: learning the sales process from the inside by building the tooling it would run on.

I am heading for the technical side of cyber security sales, as a Sales Engineer at a security vendor, and building a pipeline tool end to end with the same stack modern SaaS demo environments use is deliberate preparation for that. I want to understand stages, win rates and response-time pressure as the operator living inside the tool, not just the vendor selling it.