Operations Rollup · a working demonstration
Which lead sources are actually producing paid jobs — and what is each paid job costing us?
Tallis & Reed is a fictional Phoenix heating, cooling and plumbing company. Its leads live in a scheduling system, its money lives in a payment processor, and its ad spend arrives as a spreadsheet from an agency. Every morning at 7:00, this pipeline collects all three, verifies them against each other, and answers the question above. Every name and figure is synthetic — the collecting, checking and combining is real.
- Scheduling & CRM · paginated API
- Payments · webhooks + daily totals
- Ad spend · agency spreadsheet
Last 28 verified days · Sep 8 – Oct 5, 2026
Meta Ads (Facebook & Instagram) brought in the most leads — 123, at only $20 each — but just 10% of them became paid jobs. Counted by paying customers, Google Local Services was the efficient channel at $68 per paid job, while each Meta Ads (Facebook & Instagram) job cost $205.
- Ad spend
$9,789
-2% vs Aug 11 – Sep 7, 2026
Agency file
- Paid jobs
98
+7 vs Aug 11 – Sep 7, 2026
Scheduling + Payments
- Collected revenue
$62,530
+12% vs Aug 11 – Sep 7, 2026
Payments
- Cost per paid job
$100
-9% vs Aug 11 – Sep 7, 2026
All three systems
Where paying customers actually come from
One row per channel, sorted by what a paid job costs. Each column names the system it comes from — this table exists because three systems were combined. Select a channel to open the records behind its numbers.
| Channel | Spendagency file | Leadsscheduling | Cost / leadfile + crm | Paid jobscrm + payments | Lead → paid | Cost / paid joball three | Collectedpayments | Per ad $1file + payments |
|---|---|---|---|---|---|---|---|---|
| $1,898 | 52 | $37 | 28 | 54% | $68 | $10,511 | $5.54 | |
| $1,451 | 32 | $45 | 10 | 31% | $145 | $11,522 | $7.94 | |
| $3,983 | 90 | $44 | 26 | 29% | $153 | $15,672 | $3.93 | |
| $2,456 | 123 | $20 | 12 | 10% | $205 | $3,950 | $1.61 | |
| — | 35 | — | 16 | 46% | — | $17,967 | — | |
| — | 14 | — | 6 | 43% | — | $2,908 | — | |
| All channels | $9,789 | 346 | $28 | 98 | 28% | $100 | $62,530 | $6.39 |
- All channels346 leads · 98 paid · $62,530
4 payments totaling $1,104 couldn't be matched to a job number. They're reported here — not guessed into a channel.
Take the spreadsheet with you
The point of a system like this isn't the dashboard — it's that the clean, combined file exists every morning without anyone building it.
Channel report
One row per channel: ad spend from the agency file, leads from Scheduling & CRM, paid jobs and collected revenue from Payments — already joined.
tallis-reed_channel-report_2026-09-08_to_2026-10-05.csv
Paid-jobs detail
One row per paid job: the lead source exactly as the office typed it, the invoice, and the payments that settled it — the spreadsheet someone used to build by hand.
tallis-reed_paid-jobs_2026-09-08_to_2026-10-05.csv
Generated in your browser from the same verified records shown above. Both files contain only data verified through Oct 5, 2026, and every row is labeled as synthetic demonstration data.
When a system doesn't deliver
A report you can trust is defined by its worst mornings. Replay one — see what happens when the payment processor sends incomplete data, and how the report earns the right to advance again.
The setup — a simulated incident
Tue, Oct 6 was an ordinary day: the payment processor settled 7 payment events. But its webhook sender failed at 1:39 PM — the day’s last 3 events were never delivered, and 2 earlier ones were sent twice. The next morning’s refresh has to make sense of that.
Runs only in your browser — nothing you do here changes the demo for anyone else.
Every morning, on the record
56 morning refreshes since Aug 12 — 52 succeeded, 3 recovered on their own, 1 held a day rather than show unverified numbers. When a source didn’t deliver, the report said so and held at the last verified day — it never quietly showed unverified numbers.
- Sat, Oct 3Recovered
The scheduling system asked us to slow down. The refresh waited 42 seconds and continued where it left off — no records duplicated.
Technical detail
- Scheduling & CRM · Leads page 1: asked to slow down (HTTP 429); waited 42 s and retried
- Sat, Sep 26Recovered
5 of 8 payment events hadn't arrived at 7:00 AM, so the totals didn't match the processor. The automatic 7:15 re-check found the late payments — totals matched, nothing duplicated.
Technical detail
- Payments · Webhook deliveries: 3 received — 3 new, 0 already stored and ignored; 5 of 8 payment events for 2026-09-25 have not arrived ($2635.21 in charges, $0.00 in refunds)
- Sun, Sep 20Recovered
The agency's spend file arrived with a renamed column and was rejected rather than guessed at. A corrected file arrived later that morning and the day recovered.
Technical detail
- Ad spend · adspend_2026-09-19.csv: rejected — missing required column Spend (found: Date, Channel, Campaign, Cost (USD))
- Ad spend · 2026-09-19 is not yet covered for every paid channel
- Sun, Sep 13Held
The scheduling system was unavailable after several attempts, so the report held at Sep 11 instead of guessing. The next morning's refresh collected both days.
Technical detail
- Scheduling & CRM · Leads page 1: unavailable (HTTP 503); retried after 2 s
- Scheduling & CRM · Leads page 1: unavailable (HTTP 503); retried after 4 s
- Scheduling & CRM · Leads page 1: unavailable (HTTP 503); retried after 8 s
- Scheduling & CRM · Leads page 1: gave up after 4 attempts; the next try resumes from this page
- Sun, Sep 6Succeeded
The agency re-sent corrected ad spend for an earlier week. 6 rows were replaced in place — nothing was duplicated.
Technical detail
- Ad spend · adspend_2026-08-24_to_2026-08-30_corrected.csv: 42 rows — 0 new, 6 corrected, 36 unchanged, 0 skipped
- Fri, Aug 28Succeeded
The agency re-sent a file it had already delivered. The duplicate was recognized by its content and ignored.
Technical detail
- Ad spend · adspend_2026-08-26.csv: identical to a file already processed; ignored
Under the hood
For the technical evaluator: what this page actually runs, in one screen.
The same pipeline shape described on the service page, running in miniature: three source systems are collected, validated and combined every morning, and nothing is reported past the day all three could be verified. The engine code on this page is the real thing — the systems it reads from are simulated so the demo is safe and repeatable.
Show how this works
The pipeline
- Scheduling & CRMpaginated API, checkpointed
- Paymentswebhooks + daily settlement totals
- Ad spendagency CSV, validated on arrival
- CollectPaged reads, retries with backoff, resumable checkpoints.
- ValidateShape checks and settlement reconciliation before anything counts.
- NormalizeChannel rules, job matching, and duplicate recognition.
- VerifyEach source advances its verified-through day only when checks pass.
Trusted reporting cutoff — the minimum verified day across all three sources
- Dashboard
- CSV exports
- Status & run history
What that involves
- Paginated incremental ingestion
- The scheduling API is read page by page from a checkpoint, honoring rate limits, so a slow morning resumes instead of restarting.
- Webhook deduplication
- Payment events are stored under natural keys — a re-delivered event is recognized and ignored, never counted twice.
- Settlement reconciliation
- A day of payment events only counts once it matches the processor's own daily total.
- File validation & corrections
- The ad-spend CSV is checked header-and-field first; a corrected file replaces earlier rows rather than duplicating them.
- Provenance
- Every stored record keeps its source system, source id, and the run that wrote it.
- Verified source watermarks
- Each source carries its own verified-through day, advanced only by passing checks.
- Global trusted cutoff
- The report shows nothing newer than the least-verified source — incomplete data is held, not blended in.
- Deterministic replay
- The 56-morning history and its bad morning are generated from a fixed seed, so every visitor sees the same world.
Real engine behavior
- Validation
- Normalization
- Retries
- Deduplication
- Reconciliation
- Completeness checks
- Verified cutoff
- Metrics
- CSV exports
Simulated inputs
- The company (fictional)
- Scheduling & CRM data
- Payment processor
- Agency spreadsheets
- API & webhook failures
- The fixed demo clock
In a client build
- The store is a real database with unique constraints doing the deduplication.
- The 7:00 AM schedule is an actual cron job or worker, not a button.
- A failed or incomplete morning notifies a named person, not a status card.
- Credentials stay server-side, scoped and rotated — never in a browser.
Have a report someone rebuilds by hand every week?
Tallis & Reed is fictional — its reporting problem is not. You don't need to know which APIs or databases are involved: tell me what your team currently does by hand and what you wish you could see automatically.
What to expect
- A direct reply from me — never an automated sales sequence.
- An honest read on what your systems will and won't allow.
- A first piece that can be as small as one report or one export.
Something as ordinary as “every Friday I download three spreadsheets and combine them” is a perfectly good place to begin.