Case Study Skeleton: Invoice Follow-Up Agent for a Design Studio

Nexus AgentWorks · Case study (skeleton — numbers to be filled from a real pilot)

Status: SKELETON. Sections marked [PILOT DATA] are populated only with measured results from an actual engagement — never estimated.
Dry-run evidence (simulated). Our deterministic pilot simulator already exercises this exact agent stack end-to-end: over a 14-day simulated dry run it reviewed 70 open invoices, drafted 34 dunning reminders across the gentle→reminder→final aging ladder (every draft passed a banned-phrase tone gate), paused 8 follow-ups on customer payment promises, and escalated 28 accounts to humans (disputed invoices under contact freeze plus 90-day-plus accounts handed to human collections). All figures are from a simulated dry-run against synthetic data (see the live demo scenario). No real customers were involved.

The client

Small design/creative studio (fictional persona used for this skeleton), one owner who splits her week between client work and chasing money. Overdue invoices live in the billing system; the follow-up process lives in her outbox and her memory — a sticky-note dunning cadence of gentle nudges, firmer reminders, and the occasional awkward final notice. [CLIENT NAME PENDING CONTRACT]

The problem

What we deployed

An Invoice Follow-Up Agent running our standard loop on top of a deterministic collections policy (CollectionPlanner) whose guardrails live in code, not in the prompt:

Results framework (fill during/after pilot)

MetricBeforeAfterSource
Owner hours spent chasing invoices per month[PILOT DATA][PILOT DATA]client timesheets
DSO / average days-to-payment[PILOT DATA][PILOT DATA]billing-system reports
% of overdue invoices touched on schedule[PILOT DATA][PILOT DATA]reminders.jsonl audit log
Disputes routed to humans same-day[PILOT DATA]escalation records
Cost per dunning touch[PILOT DATA][PILOT DATA]token ledger

Pricing fit

Invoice follow-up runs on our platform-fee-plus-usage model: $550/mo platform fee + $8.00 per collected invoice (an invoice paid after an agent touch within the cycle). Because each touch is a small deterministic decision with a tiny token footprint, the internal simulated worked example clears our enforced 30%-margin floor easily — at ~90% contribution margin per collected invoice in the simulated dry-run estimate (see reports/pricing_model.md §6, and pricing). Disputed invoices are never billed or messaged, so revenue only accrues on clean, successful collections — the pricing aligns our incentive with the client's cash flow.

Why the deterministic dunning policy matters

In collections, one wrong message can cost the relationship the invoice was worth. The aging tier, the dispute freeze, the promise pause, and the handoff thresholds all live in deterministic code the language model cannot override — the LLM only drafts within a tier the planner has already chosen, and every draft must clear a banned-phrase tone gate before it exists as a candidate. A disputing customer never receives another automated message, and every touch is attributable to its invoice record, its aging rule, and a loop cycle.

Lessons learned section

[POST-PILOT: list top 3 lessons from data/loops/<project>/ — real ones, verbatim.]

SIMULATED DATA — every dry-run figure on this page is a simulated estimate against synthetic data; none comes from a real engagement yet.

Questions before a pilot? See the FAQ and our trust & safety notes, or start the conversation.