Tan LE

Most "AI meeting notes" products work after the fact: the call ends, a bot that joined the meeting sends a summary an hour later, and the useful moment has already passed. I wanted the opposite: an assistant that listens during the call, knows the company's products and the customer in front of you, and puts a usable answer on screen within a couple of seconds of a question being asked. This post covers what I built, the stack behind it, how it fits a sales team today, and why the same engine is a short step away from an AI phone agent that can answer the front desk and take bookings. The problem I wanted to solve Watch a sales rep on a discovery call and you see the same pattern again and again. The customer asks something specific: "Does this integrate with our ERP?", "What's the price for 40 seats on annual billing?", "How is this different from what we have now?" The rep either knows, or says "let me get back to you", o...

Part 1 of 2. This post introduces the product and walks through the web application. Part 2 covers the invoice-parsing engine, the technology stack and the CI/CD pipeline. What is IProcessor? IProcessor is an internal operations platform built for GMD Stores, a multi-store retail business that buys from dozens of import vendors and ships goods through its own warehouse. Every week the business receives a flood of vendor invoices as PDF attachments, has to reconcile them against purchase orders, receive the goods, split them by store, verify pick-and-pack, and account for margins. Before IProcessor, most of this was manual data entry and spreadsheets. IProcessor turns it into a single flow: A vendor emails an invoice PDF to a shared mailbox. A background service picks it up, identifies the vendor, extracts every line item and saves it to the database. No human touches it. Buyers and accounting review and approve the invoice in the web app. Warehouse staff receiv...

Hiding Complex Detail Sections on Phones Without Breaking Deep Links A small fix from the Staffpoint project, and the three edge cases that made it bigger than it looked Staffpoint is a staffing and scheduling platform built on ASP.NET WebForms. A recent fix on the Personnel Details page dealt with a problem every responsive retrofit of an old app eventually hits: some screens simply do not work on a phone yet, and hiding a tab is not enough to keep users out of them. This post covers what the issue was, what the fix changed, and the edge cases that turned a one-line CSS change into a small routing policy. The issue The Personnel Details page is a single-page shell. It loads a person's record and shows a row of tabs: Details, Qualifications, Availability, Accreditations, Notes, Rates, and a few more. Each tab loads its content over AJAX into the shell, and the current tab is encoded in the URL hash, so #availability-1234 means "Availability for person 1234." Tha...

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...