A scheduled job sends each Merchandising Specialist a personalized Slack recap of their prior period — hours worked, billing, VINs serviced, utilization, and progress against the $20k weekly goal. Redline did this by hand years ago; it was a lot of effort. This is the same cron → script → Slack pattern Pasley Hill already runs reliably.
Redline has a "Success Plan" framework for Merchandising Specialists and a set of Canned Emails / Performance Management templates, but the data that should drive coaching lives in two systems that don't talk to anyone automatically. Billing and income sit in Predian. Hours worked sit in Rippling. To tell an MS how their week actually went, a manager has to open both, reconcile the numbers, and write it up.
Redline ran a version of this manually a few years ago. It worked — reps respond to "here's your week, here's the goal" — but it was enough hand-effort that it didn't survive. Today most MSs get goal context only through the periodic regional Slack updates ("Last Week $3,003.88, VIN's Serviced 176, Weekly Billing Goal $20,000"), which are coverage-focused and not per-rep. The individual feedback loop the Success Plan assumes simply isn't running.
The cost here is not a big software bill — it's the missing routine. Without an automatic, per-rep recap, the Success Plan is a document instead of a habit, and managers either spend hours assembling numbers or skip the individual feedback entirely.
A scheduled job wakes up on a cadence (weekly to start — see open questions), pulls each MS's prior-period numbers from Predian and Rippling, computes a small set of KPIs, and posts a personalized recap as a Slack DM to that MS. A second pass builds a manager rollup. There is no AI magic required here and we won't pretend there is — this is deterministic data assembly plus templated messaging. The only "intelligence" is the KPI math and a clean, readable message.
Every recap is built from a fixed core, plus opt-in metrics each MS or Redline can toggle on:
Personalization matters: an MS who consistently clears goal gets a different framing than one trending down three weeks running. The message template can pull the right tone and (where Redline wants) the matching Canned Email / Performance Management language, so the recap reinforces the Success Plan 2026 framework instead of being a bare number dump.
cron (weekly, Mon AM)
│
├─► Predian API ──► billing $, VINs serviced (per MS, prior period)
├─► Rippling API ─► hours worked (per MS, prior period)
│
▼
compute KPIs per MS
• utilization = billing / capacity(hours)
• wow trend = this period vs. stored last period
• goal attain = billing / $20,000
│
├─► render per-MS template ──► Slack DM to each MS
└─► aggregate ──────────────► Slack manager rollup (region/team)
│
▼
persist this period's KPIs (for next week's WoW + Success Plan history)Alongside the individual DMs, the job posts a manager rollup: a sorted table of reps by goal attainment and utilization, so a Regional Manager sees at a glance who's ahead, who's slipping, and who to coach this week. This is where the Success Plan stops being paperwork and becomes a weekly review artifact.
This reuses muscle Pasley Hill already has in production: a scheduled Lambda pulls from upstream APIs, does light computation, writes to a small store, and posts to Slack. No new infrastructure pattern, no servers to babysit.
EventBridge ─► Lambda (Python)
├─ fetch: Predian, Rippling
├─ join on MS identity (employee ↔ billing rep)
├─ compute KPIs, diff vs. DynamoDB last-period
├─ post: Slack DM per MS + manager rollup
└─ write: DynamoDB (this period) + S3 (raw)
Secrets Manager ─► API tokens (Predian, Rippling, Slack)The one piece of real engineering is identity joining — matching a Rippling employee record to the right Predian billing rep so hours and billing line up for the same person. Worth getting right once; cheap to maintain after.
Get read access to Predian and Rippling. Confirm the fields (billing $, VINs, hours) and build the MS identity map between the two systems. This phase is the actual risk; everything downstream is straightforward once data flows.
Implement utilization, week-over-week trend, and goal attainment vs. $20k. Stand up DynamoDB to persist each period so trends and Success Plan history accumulate. Verify the math against a hand-checked sample week.
Build the personalized message template, wire opt-in metric toggles, and tie tone/language to the Success Plan 2026 + Canned Email framework. Add the manager rollup table. Dry-run to a test channel before any real DMs go out.
Put it on EventBridge, add failure alerts (a job that silently stops is worse than no job), pilot with one region, then roll out. Total build is small — call it ~1.5 weeks of focused work, faster with AI-assisted dev.
Build time is short; the schedule is gated entirely on Redline providing access to the two upstream systems. Nothing below is exotic, but each needs a credential and a confirmed field mapping.
| Source | What we need | Used for |
|---|---|---|
| Predian | API/read access to billing & income per rep, plus VINs serviced, per period | Billing $, VINs, goal attainment |
| Rippling | API/read access to hours worked per employee (and the MS roster) | Hours, utilization, identity map |
| Slack | Bot token with DM + channel post scopes; manager channel IDs | Per-MS DM delivery + manager rollup |
| Redline (people) | MS ↔ billing-rep identity mapping; expected capacity / billing-per-hour baseline | Joining the two systems; utilization math |
| Redline (framework) | Success Plan 2026 doc + Canned Email / Performance Management templates | Recap tone, coaching language, goal definitions |
| Redline (config) | Cadence decision + default/opt-in KPI list per MS | Schedule + personalization |
Data access is the whole project. The build is small and well-understood; the dependency that can stall it is getting clean, programmatic read access to Predian and Rippling. If either only exposes data via export or an awkward integration, Phase 1 grows. Confirm both APIs (and the fields we need) before committing a date.
Identity matching. Hours (Rippling) and billing (Predian) must resolve to the same person. Mismatches produce wrong utilization numbers — and a confidently-wrong recap erodes trust fast. We hand-verify the mapping in Phase 1 and fail loudly on unmatched reps rather than guessing.
Cadence — weekly, biweekly, or monthly? The source frames this as undecided. Weekly matches the existing $20k weekly goal and the regional update rhythm, so it's our default recommendation, but Redline should confirm. Cadence affects nothing structural; it's a config value.
Opt-in metrics. Core KPIs are fixed (billing, VINs, hours, utilization, WoW, goal). Which extras can an MS toggle on, and who controls that — the rep, the RM, or Redline ops? Needs a short decision so we know how configurable to make it.
Manager rollup scope. One company-wide summary, or per-region rollups to each RM? Drives Slack channel/permission setup, not the build.
This is a scheduled job, so run cost is negligible — a Lambda that fires weekly plus a tiny DynamoDB table and a few S3 objects lands in single-digit dollars per month. There's no server, no always-on service, nothing to scale.
The real ongoing cost is upstream change. If Predian or Rippling changes an API or a field, the job breaks and someone has to fix the mapping. That's why Phase 4 includes failure alerting: a recap job that quietly stops sending is worse than never having built it, because everyone assumes the numbers are still flowing. Budget a few hours a quarter for that kind of maintenance and nothing more.
Net: low build, low run, low maintenance. The honest caveat is the dependency, not the cost — once Predian and Rippling access is in hand, this is one of the cheapest high-value automations on the board and it directly powers the Success Plan coaching loop Redline already wants to run.