Inbox Tickets

Origin

Inside-sales work means a constant stream of customer emails — purchase orders as PDFs, quote requests, vendor follow-ups, shipping account numbers buried in long email threads. Outlook alone wasn't a workflow tool. I built one. Now flagged emails become categorized tickets automatically, attachments live next to the ticket, and the data I touch most often (vendors, customers, parts) has its own first-class place to live.

What it does

• Outlook → tickets via AppleScript

  Four AppleScripts handle the bridge: poll flagged messages, save PDF attachments per ticket, open Outlook to a specific message, and unflag once a ticket is resolved. The bridge runs without an Outlook plugin or Microsoft Graph API access — it just talks to the Outlook app installed on my Mac.

• Auto-categorization

  Six categories (quote, order entry, respond, follow-up, forward, FYI) assigned by keyword match. Default keywords are configurable; new keywords learned per email pattern. Each ticket also tracks status (open / in progress / done), reminder timestamps, and a price-notice handled flag for vendor pricing changes.

• Shipping-account auto-extraction

  A regex parser pulls shipping account numbers out of email bodies and normalizes the carrier (FedEx / UPS / T-Force / DHL / LTL / CWT). It also classifies the billing intent — third-party billing, collect, ship-via — based on context words around the account number. No more scrolling the email to find the number.

• Vendor + customer + part registries

  Vendors carry rep contact info, lookup URL templates, browser preferences, price-increase dates and percentages, tariff percentages, and shortcut keystrokes. Customers carry portal URLs and credentials. Parts map to vendors via prefix matching. Everything I touch in a quote has a first-class home and one search.

• ERP cross-references

  Every ticket links to its corresponding ERP records — sales orders, quotes, POs, invoices — with internal IDs and direct deep-link URLs. One click from an email to the ERP record it relates to.

• Local-first, port 8765

  FastAPI server runs on localhost:8765. Browser auto-opens when run.sh starts the server. SQLite database lives on disk, encrypted by FileVault. No cloud, no SaaS subscription, no data leaving the machine.

Engineering

• AppleScript as a feature, not a workaround

  Microsoft offers a Graph API for Outlook automation — but it requires admin tenant approval, OAuth flows, and a license tier I don't control. AppleScript talks to the Outlook app already installed on my Mac, no admin needed, no auth ceremony. The bridge fetches messages, reads sender + subject + body + attachments, saves PDFs to disk, and unflags messages — all from a four-script pack that runs without any cloud dependency.

• Schema designed around the actual workflow, not generic CRM

  The DB has tables for tickets, vendors, customers, parts, vendor_prefixes, ticket_references, attachments, keywords, and settings. Vendor records carry the specific fields a sales-side person actually needs while quoting — rep email, rep phone, lookup URL templates, price-increase percentages, tariff percentages, keystroke macros, browser preference. Customer records carry portal URLs and credentials. Tickets cross-reference ERP records by internal ID and direct deep-link URL. The schema is the workflow, not a generic ticket-tracker abstraction.

• One leverage story, two lessons

  Lesson 1: senior engineering leadership isn't about telling teams to be productive — it's about *being productive yourself, visibly,* by building the tools your day demands. Lesson 2: the leverage move scales down to one user. NativeBridge multiplies my dev velocity. Inbox Tickets multiplies my desk velocity. Different tools, same thesis: solve the meta-problem that's slowing you down before you solve any of the instances.

Stack

• Python
• FastAPI
• Uvicorn
• SQLite
• AppleScript (Outlook bridge)
• pdfplumber
• Vanilla HTML + CSS + JS