标签：#magesheet

Every logistics and field-sales team runs the same expensive process: a driver photographs a receipt into a WhatsApp group, and a back-office clerk manually types the invoice number, total, and date into a spreadsheet. Hundreds of receipts a week = transcription errors and thousands of wasted hours. AI vision models kill that bottleneck. Here's the pipeline that turns a blurry field photo into clean structured data in seconds. Why vision models beat traditional OCR OCR reads characters. Modern vision models (Claude Vision, Gemini Vision, GPT-4 Vision) read structure — they distinguish a tax ID from a total, and a date from an amount, even on crumpled, angled, or poorly lit receipts. No brittle per-vendor parsers. The pipeline (3–8 seconds end to end) WhatsApp image → Apps Script doPost → forward to vision model → model returns JSON { InvoiceNumber, TotalAmount, VendorName, Date, Category, confidence_score } → confidence routing: > 90 → auto-append to ledger 70–90 → flag for human review < 70 → ask driver to re-photo → write row to Google Sheet (+ link to original image) → auto WhatsApp confirmation to driver The confidence_score is the whole trick — it's what stops bad extractions from silently polluting your ledger. Model selection (this drives your bill) Gemini Vision — cost-efficient default, strong multilingual OCR, great on clean receipts. Claude Vision — highest accuracy on degraded receipts; use for high-stakes flows. GPT-4o Vision — competitive, strong structured extraction. Pattern: Gemini for the first pass, escalate only low-confidence cases to Claude / GPT-4o. The economics ~500 receipts/week: vision API $10–40 + WhatsApp API $30–60 + Apps Script free = ~$40–100/month . Versus a clerk at ~25 hrs/week = $2,000–4,000/month in loaded labor. Per-receipt cost: $0.005–0.02 (compress images to ~1024px to cut it further). Accuracy: 92–97% on legible receipts, 75–85% on handwritten/damaged — hence the confidence routing. Pitfalls to avoid Auto-appending with no c

Field-service software has an adoption problem: drivers won't use it. Heavy app, another login, crashes in low-signal areas. So the "real-time" data still shows up as end-of-shift phone calls. The fix that actually sticks: stop building an app and use the one drivers already live in — WhatsApp. With Apps Script and Google Sheets behind it, WhatsApp becomes a frictionless mobile ERP. Here's the build. WhatsApp as a data-entry terminal A driver texts Status ABC-1234 Delivered . An Apps Script doPost webhook receives it, parses it, and updates the Sheet in real time. Latency goes from hours to milliseconds — and there's nothing to install, so adoption hits 90%+ in a week (vs. 50–70% for custom apps). Two-stage parsing for messy input Real drivers type "done," not clean commands. So: Regex first pass — handles ~70% of messages (clean format) instantly and for free. LLM fallback — the remaining ~30% goes to a cheap model (GPT-4o-mini / Gemini Flash) with the known cargo IDs and valid statuses. It returns normalized JSON + a confidence score. Below-threshold messages surface to a dispatcher. The LLM normalizes correctly 95%+ of the time (~5% manual), and it handles multilingual input with zero extra code. Driver msg → Apps Script doPost → regex pass → (fail) LLM fallback w/ confidence score → Sheet update (timestamp + raw-message log) → optional outbound (route change, POD photo request) Why Google Sheets is the right backend Dependent formulas: time-to-delivery, SLA-breach flags Pivot tables for reporting Apps Script triggers for automatic client emails Conditional formatting dashboards Native Calendar / Maps / Drive integration (POD photos → Drive folder) It runs on free Google Workspace infrastructure with minimal API cost. Bidirectional by default The same integration pushes messages back to drivers: route changes, delivery instructions, shift reminders, exception alerts, proof-of-delivery photo requests — all in the same thread. Pitfalls that get your number banned T