✉ Inbound Mail ⏱ Service responses 📦 Inventory 🛣️ Mileage log
Creates a dispatcher login (username + PIN) used on this Admin Panel and the main board. Admin role can manage users and the Distance Matrix. Deactivate instead of deleting when someone leaves so history stays intact.
Saved on this login only. Does not create or edit a technician record.
Control who receives SMS alerts when trouble tickets arrive, which states they cover, and their active hours. If the recipient name matches a technician card (or their dispatcher login is linked to one), Watchdog uses the SMS address from that card. Set Verizon/AT&T/T-Mobile there once. Hours and states stay on this tab.
Compare current default technician assignments against the distance matrix. Flags locations where a closer employee exists and fills in any missing defaults. Contractors are never suggested, and sites already set to a contractor are left alone, since using a contractor is a call-by-call decision. Requires the distance matrix to be built for this state.
Creates the same spreadsheets TJ keeps by hand, from the live locations and technicians. Bulletins, manuals, and new-employee forms can live here later.
One tab per state, with primary and fallback technician assignments.
The company-wide roster. Safe to circulate. It does not include home addresses.
Same roster, plus home addresses for the distance matrix. Do not send this copy company-wide.
Use this after adding ONE new technician or ONE new location to a state that's already built out. Only prices that one new item -- cheap, safe, no options to get wrong.
Not needed for adding one technician or one location. These can cost real money, so they stay locked until you enter the Distance Matrix admin password.
Step 1 — Geocode addresses (first-time setup or after adding new locations/techs). Skips records that already have coordinates unless Force is checked.
Step 2 — Build the distance matrix. Haversine is free and instant. Drive-time uses Google Maps API (~$5–6 per GA+FL full refresh).
Step 3 (optional) — Build real driving distances between every pair of sites in this state, for stop-order routing (2-opt currently uses straight-line distance for this). One-time per state — costs scale with site count squared, not tech count, so this is priced separately from Step 2. Requires Step 1 (geocoding) already done. Adds to the same matrix Step 2 builds; doesn't overwrite it.
Incremental (default, both boxes below unchecked): only fills in pairs involving sites that are brand new since the last build. Plainly put -- if a site already has SOME pairs on file from an earlier build, incremental won't go back and add its missing pairs, even if it was never paired with every other site. It guarantees a site has been touched at least once, not that it's fully paired. A site that's only ever shown up as the destination half of a pair can permanently miss pairs toward sites earlier in the list, even after incremental reports "0 new, done."
Use this if a state's site-to-site coverage looks incomplete (e.g. after an interrupted build) -- it finds and queries only the specific pairs still missing, at no extra cost for pairs already on file.
Only needed to backfill real Google usage the tracker missed (e.g. from before this tracker existed). Does not call Google -- just adjusts the local counter used for cost previews.
Import the "Completed Service Appointments" report from Salesforce. Same file restock tracker uses — nothing here changes that, this is a separate import into the dispatch app's own history.
Found 2026-07-23: a real bug where sites with "Co"/"County" phrasing differences between Salesforce's Account Name and the real site name could get silently matched to the wrong site instead of correctly flagged for review. Fixed for future imports -- this re-checks every already-imported row against the corrected logic and fixes any that were mismatched.
Separate pipeline covering non-Salesforce sites (testing stations, OTC/counter printers). Runs automatically every day, pulling closed BlueFolder Service Requests into a staging table -- this doesn't yet feed the main closed-ticket view above, it's reference data for a future matching/display pass.
The daily sync only pulls forward from whenever it first ran. To pull in older closed tickets, run backfill chunks one at a time (BlueFolder caps each request at ~6 months) -- each click walks further back and reports what it actually found, since BlueFolder history has some known gaps from past cleanup and there's no way to know the real depth in advance.
📁 Open BlueFolder ArchiveFlags sites with 3+ trouble tickets for the same issue category within a rolling window — standard practice is to replace the hardware on the 3rd return trip for the same complaint. Pulled from parsed trouble ticket emails (issue_category field), not closing notes.
Weekly incoming trouble volume for a problem type, across one state or all states. Catches fleet-wide patterns (a bad ribbon lot, a journal driver, Florida form stock) even when no single store has hit the Repeat Issues threshold. Built from parsed ticket emails, so history only goes back as far as mailbox ingest.
Closed-ticket import rows where the site name couldn't be matched confidently enough to auto-link. Grouped by raw name, since the same unmatched name usually covers many rows — fix it once here and every row sharing that name gets updated together.
Same cycle-detection logic as restock tracker, running live against Supabase instead of a manually re-uploaded report. Average cycle length filters out outlier gaps; a site is marked overdue (visited) instead of flat overdue if a trouble-ticket visit happened after its last real restock, since consumables may have been informally topped off then.
Inventory received → Technician mileage entry → Mileage Check (review tool) →
A ballpark sanity check against each technician's biweekly mileage log, not a precise audit -- catches an odometer/mileage number that's wildly off (a mistyped digit, a transposed pair, a negative-mileage leg) by comparing each drive against the known distance between those two stops. Small differences from lunch detours or a mid-route errand are expected and won't be flagged. Timesheets forwarded to dispatch@mcrdispatch.net (filename containing "_Expense_") are picked up automatically -- use the upload below to test one manually or reprocess an older file.