Four items from the source doc that are real but thin: a map that should sync itself, an invoice-request flow, a name with no scope attached, and a Manager Playbook we haven't read yet. Most are small once defined — but two of them are honestly discovery items, not builds. This page treats each one straight, gives a concrete first-pass approach, and is explicit about what we need before we can put a number on it.
These four ideas live at the bottom of the source doc for a reason: they're under-described. Rather than pad each into its own full spec and pretend we know more than we do, we've put them on one page. Each gets a short, honest treatment — the problem, a first-pass approach we'd actually try, and an effort + dependency read. Where an item isn't a build yet but a conversation, we say so plainly with a NEEDS DEFINITION note. Nothing here is sized to the day until the discovery questions at the bottom are answered.
Keep the stores-and-coverage map current automatically, instead of hand-editing pins as the network changes.
Redline keeps a Google My Maps of stores, reps, and managers. The trouble with any hand-maintained map is the same: it drifts. A store gets added or lost, a rep changes territory, a manager picks up a new region — and the map only catches up when somebody remembers to open it and move a pin. The map's whole value is being trusted as current; the moment people suspect it's stale, they stop using it and go ask a person instead. This is low-effort-per-edit, high-forget-rate work — exactly the shape that should be driven from the systems that already know the answer.
Drive the map from the sources of record rather than from human edits. Two inputs:
A small scheduled job joins those two, geocodes any store without coordinates, and regenerates the map layer on a cadence (nightly is plenty). Added stores appear, lost stores drop off, and rep/manager labels follow their Rippling assignments — no manual pin-pushing.
S. A scripting job against two data sources plus geocoding. If we render our own map layer (path b), the data-sync core is a day or two; the map page is another day or two. The KML re-import path (a) is even less code but leaves a manual click in the loop.
Read access to the store list (source/format TBD) and Rippling rep/manager assignments. A geocoding key (Google/Mapbox) for any address without coordinates. A decision on My Maps vs. a real mapping layer.
Listed under "NON OPS Automation Ideas" as a single line. We have a guess at the shape, but this one genuinely needs definition before it's a build.
One line: "Handling invoice requests." That's it. So everything below is a first-pass guess at intent, offered to give the discovery conversation something to react to — not a spec we'd build against as written.
The most likely shape is an intake + routing automation: someone (a dealer, a rep, an internal team) asks for an invoice; today a person reads that request, figures out what's being asked, looks it up, and either issues the invoice or hands it to whoever can. A small system could:
That's a tractable agent/intake build if the assumptions hold. They might not.
S–M, unknown. If it's "route a structured request to a human," it's small. If it's "generate invoices against an accounting system with real money attached," that's larger and carries correctness/financial risk that pushes it toward a careful build. We can't honestly size it until the flow is described.
The invoicing system's API or export. The request channel (email mailbox / Slack / form). And — most importantly — a short walkthrough with whoever handles these today.
In the source doc this is a name and nothing else. We're not going to invent scope for it.
"Mike Bolan tasks" appears under NON-OPS ideas with zero content — no description, no examples, no link. We could fabricate a plausible-sounding workflow here, but that would be guessing about a person's job we know nothing about, and it would waste everyone's time when the real tasks surface and don't match. So we're treating this honestly as a placeholder.
Standard for any "automate my repetitive work" request: have Mike list tasks, then for each ask three things — how often, how rule-based (could a clear checklist do it, or does it need judgment?), and how much time it eats. High-frequency + rule-based + meaningful-time items rise to the top. Anything that's rare, or genuinely needs Mike's judgment, stays manual. That filter usually turns a vague "automate my job" into one or two crisp, buildable wins.
Effort: unknown — currently zero scope. Dependency: time with Mike Bolan to produce the task list. Until then this is a calendar invite, not a line item.
The doc references a "Manager Playbook" alongside the visitation notifications. It almost certainly contains more RM work worth automating; we just need to read it.
The Visitation Notifications build already tackles the most visible repetitive RM task — the 2-3 weekly coverage messages. But the source doc points to a broader Manager Playbook document describing the rest of an RM's standing responsibilities. Playbooks are, by nature, a list of recurring, templatable duties — which is exactly the raw material for small automations. There's a good chance several items in it are the same shape as the visitation notifications: assemble known facts, draft something, get a human's nod, send it.
Reusing the notifications plumbing is the point: once we've built the "fetch facts → LLM draft → RM approves → post" loop, each additional RM message type is mostly configuration, not a new system.
S per item, once identified. Anything that folds into visitation notifications is incremental — new template, new data field, same approval loop. Standalone reminders/summaries are individually small. The total depends entirely on how many duties the Playbook turns up.
The Manager Playbook document. The visitation-notifications system existing first (so we have plumbing to reuse). Whatever data each specific duty touches — most likely the same Predian / Rippling / Slack sources.
Three of these four reuse machinery Redline is already getting from the larger builds, which is why they're cheap once defined. There's no new platform here — just small jobs hung off existing rails.
EventBridge (nightly)
│
▼
sync-map Lambda
├── Store list ......... active stores + addresses
├── Rippling ........... rep / manager assignments
└── Geocoder ........... fill missing coordinates
│
▼
regenerate map layer
├── (a) write KML/CSV → re-import to My Maps
└── (b) write GeoJSON → render own Maps/Mapbox pageRequest in (email / Slack / form)
│
▼
intake Lambda — parse + classify
├── who · which account · what period
└── new invoice vs. copy
│
▼
┌── generate from billing system
└── OR route structured ticket → humanItems 3 and 4 have no architecture yet — by design. They get one after their discovery conversation, and most likely they slot into the rails above rather than introducing anything new.
The honest plan for this page is discovery first, then small builds. Two items can start scoping immediately; two cannot start until a conversation happens. We've ordered the phases accordingly.
One short session each: confirm the map's data sources and how attached Redline is to My Maps; walk the current invoice-request flow end to end; sit with Mike Bolan to enumerate his repetitive tasks; and get the Manager Playbook document. After this, three of the four convert from "idea" to "scoped small build" and we can put real numbers on them.
Build the store-list + Rippling join, geocoding, and layer regeneration. Ship the KML/CSV re-import path first (fastest to value), and propose the own-rendered map layer if Redline wants a fully hands-off result.
Take the triaged Playbook duties and implement the automatable ones, reusing the notifications plumbing wherever the shape matches. Each is small; the count comes out of Phase 0.
Build invoice intake once the current flow and issuing system are known. Build whatever rises out of the Mike Bolan triage. Both could be quick wins, both could turn out not worth automating — that's the honest range, and discovery decides it.
What each item needs from Redline. The "Discovery answer" column is the thing that has to exist before we can quote the build, not just connect to it.
| Item | Systems / access | Discovery answer required |
|---|---|---|
| Map sync | Store list (read), Rippling (assignments), geocoding key | Stay on My Maps (KML re-import) or move to a rendered map layer? |
| Invoice requests | Invoicing system API/export, request channel (mailbox / Slack / form) | Who requests, which system issues invoices, and the current manual flow |
| Mike Bolan tasks | TBD — depends entirely on the tasks | The task list itself (none exists yet) |
| Manager Playbook | Same sources as visitation notifications, per duty | The Playbook document + which duties are templatable |
For the items that are real builds, run cost is small — these are scheduled jobs and intake handlers, not always-on services. The genuine "cost" here is upstream of code: the discovery time to define them.