// Project 03 — OpenAI FDE Hackathon · 3rd place
LionLink — Customer Service Console
A hackathon during the OpenAI for Singapore FDE Bootcamp, co-organised by OpenAI and AI Singapore, where my team built for LionLink, a fictional bus operator. We interviewed each department, and Customer Service had the clearest pain: complaints arrive by phone and email, get recorded into Excel by hand, and every complaint means minutes to hours of checking with Operations, Planning and Engineering departments before answering customers.
I owned the internal Customer Service console: one screen that finds the passenger's trip, shows what each department recorded about it, and turns complaints into a queue that can be tracked, grouped and answered, with the help of AI.
// How the AI works
- Classifying with the Decisions API. OpenAI's Decisions API entered public beta the day before the hackathon, and it fit the job exactly. Rather than asking a chat model and parsing its prose, each complaint is put to two fixed questions, category and urgency, and the API can only answer from our own lists, with a confidence score for each. Answers below 0.6 confidence, or refused outright, are flagged for an officer to review instead of being trusted. Only the passenger's words and the channel are sent, so the label reflects what they complained about, not what the records say.
- Auto-parsing complaints into a form. Emails and call notes rarely arrive with the route, time and stop Customer Service needs. One click on Extract details sends the text to a model with a strict JSON schema and the lists of valid services and stops, with instructions to return null rather than guess. Every value is checked against those lists again before it reaches the form, so an invented stop is dropped, not saved. A local rule-based parser handles the same text if the model is unavailable, and a banner tells the officer which one filled the fields.
- Live call transcription. Officers can record a phone call and watch it transcribed as they talk. The server issues a 60-second session key, so the API key never reaches the browser, and the session is primed with stop names and fleet numbers like NW-V039 that a general model would mishear. Recording carries on in the background while the officer looks up the journey, and when the call ends the transcript goes straight through the parser.
- Reply drafts grounded in the records. A draft comes back as two separate fields: a passenger-ready reply of at most 140 words, worded for an email or for reading aloud on a call, and internal notes for staff, so notes can never leak into the reply. The model sees only the facts on screen. It can give a cause only when Operations recorded one, never promises compensation, and asks for the route, time or stop when they're missing. Officers can open exactly what was sent to the model, and nothing goes out until staff have checked it.
// Stack
- Next.js
- Console, API routes and passenger app
- OpenAI
- Decisions API for classification; Responses API for parsing and drafts; Realtime for transcription
- TypeScript
- Classification, trip matching and metrics as plain, tested functions
- Playwright
- End-to-end tests for every demo scenario
// Reflection
This was my first hackathon, and it gave me a real look at how forward-deployed engineers work: interviewing stakeholders, finding the problem underneath what they ask for, and designing something that fits how they actually work. Clients often don't know exactly what they want. A big part of the job is asking the right questions and guiding them towards a solution that works for them.
One line has stayed with me since:
“We are not looking for fancy solutions that look good but don't work.”
With AI, it's easy to get caught up in the newest model or the flashiest feature. That line reminds me to start with the people and their problem, and to use the technology only where it genuinely helps them.
Jianzuo
On my first hackathon