Tan LE

Every week, part of my ticket-operations workflow involved the same manual routine: open the StubHub inventory site, apply the same filters, and work down a research spreadsheet of performers one by one — searching each name, adding what qualified, and noting the ones with no events. It's exactly the kind of task that is too UI-bound for an API integration but too repetitive to keep doing by hand. So I automated it with Power Automate Desktop , Microsoft's desktop RPA tool. This post walks through how the flow works and the design decisions that made it reliable enough to run unattended, week after week. What the flow does The flow runs on a weekly cycle, and its first job is to know where it is in that cycle: Weekly reset. On start, it gets the current date and time in Pacific time and checks the day of week. If it's Sunday at 6:00 AM or later, the week is over: it resets the state file ( CompletedSpecPerformerList.txt ) and stops. Every other run continues the ...

Before my current automation work, I spent about a year as a freelancer building a market-intelligence and purchasing-workflow platform for a US ticket-brokerage client. The secondary ticket market moves fast: events go on sale at a fixed minute, prices and seat availability shift constantly across a dozen marketplaces, and the brokers who win are the ones who see changes first. My job was to give a small operations team that visibility — and to automate as much of the surrounding workflow as possible. This post is a technical retrospective of that system: what it did, how it was architected, and what I learned running data pipelines across two clouds. What the platform did At its core, the system ran four loops for the operations team: Primary-market ingest. Scheduled jobs pulled upcoming events from Ticketmaster's APIs — by state, by venue, by on-sale date — into a local SQL Server database, so the team planned their week from one screen instead of a dozen browser tabs...

  The final post in my series on an automation hub for a ticket-resale business. This is a very real-world integration story: a sales platform with no webhooks and no usable order API — the only thing you get is an HTML "TICKETS SOLD" notification email. Plus the settlement-reconciliation pipeline that records payments onto invoices automatically. Context The team sells tickets on Lysted, but inventory and invoices are managed centrally in SkyBox (VividSeats' POS). Every Lysted sale has to be recorded in SkyBox: matched to the right event, section, row, and seats in inventory, with the invoice reflecting the correct payout. Lysted doesn't fire webhooks. What the team did have: "tickets sold" emails already being forwarded into a Slack channel. So: Slack is the message queue, and the HTML email is the API . Pipeline 1: Recording sales Slack conversations.history (bot token) → store messages in MySQL (idempotent — nothing processed twice) → download atta...

  Post 3 in my series on an automation hub for a ticket-resale business. If you've ever put an LLM into a production pipeline, you know the feeling: the prompt clearly says "return ONLY valid JSON," and the model responds with... a friendly greeting, a markdown code fence, and then the JSON — occasionally missing a bracket. This post collects the techniques I use to parse LLM output safely in C#. The problem: an LLM is an "API" with no schema guarantee In my email-classification pipeline (see post 2), the model must return a list of objects like: { "uid": "452455", "subject": "Presale starts Friday!", "performer": "...", "venue": "...", "event_date": "Oct 10, 2026", "label": "PRESALES", "confidence": 0.92 } In practice the model returns every possible variation: uid is sometimes a string and sometimes a number, label i...

This is a living index of the systems I'm most proud of — each one is in daily production use, and each links to a deeper technical write-up. If you're a recruiter or hiring manager, this page is the fastest way to see what I actually build. 1. AI Email-Triage Pipeline (LLM classification in production) A pipeline that classifies hundreds of ticketing emails per day (presales, releases, cancellations) using multimodal LLMs, then distributes summarized reports automatically to the relevant business departments. I fine-tuned GPT-4o-mini on a labelled dataset I built from PDF archives, put OpenAI and Gemini behind a single interchangeable JSON contract for cost/performance trade-offs, and wrote a defensive C# parsing layer — balanced-brace JSON extraction, tolerant custom JsonConverters, code-enforced business invariants — so a single malformed model response never breaks the batch. Stack: C#/.NET, OpenAI API (fine-tuning), Gemini, IMAP, SQL Server Read more: Classifying E...

  Post 2 in my series on an automation hub for a ticket-resale business. This one covers the AI pipeline that reads and classifies event-ticket emails — from prompt engineering and multimodal handling (emails with images) to building my own dataset and fine-tuning GPT-4o-mini. The problem The purchasing team's inbox receives hundreds of emails a day: Ticketmaster presale announcements, venues releasing new ticket blocks, artists sending promo codes, cancelled orders that need refunds... Missing a "tickets released" email can mean losing a chance to buy at face value; missing a cancellation email means losing refund money. But nobody can read hundreds of emails a day by hand. The requirement: classify emails into categories ( PRESALES , TICKETS_RELEASED , TICKETS_ON_SALE , ALMOST_SOLD_OUT , PROMOTION_DISCOUNT , Cancelled ...) and extract structured data : performer, venue, event date, purchase link, promo code — and for cancellation emails, the order number, vendor, quanti...