标签：#freelancing

The single hardest thing about getting paid isn't writing the invoice. It's the follow-up — knowing when to nudge a quiet client, and doing it in a tone that doesn't torch the relationship. Most tools solve this with a dumb cron job: "send a reminder 7 days after the due date." That's wrong for almost everyone, and here's why. The problem with fixed reminder schedules Payment behavior isn't uniform. One client pays like clockwork on day 32 of a "net 30" invoice — not late, just their rhythm. Another pays on day 5 but only if you remind them on day 3. A blanket "day 7 past due" reminder annoys the first client (who was always going to pay) and misses the second (who needed the poke earlier). So the real problem is per-client timing prediction , not scheduling. You want to model each client's payment distribution and act at the point where a reminder has the highest marginal effect — the moment they're most likely to convert intent into a transfer. Modeling payment rhythm as a per-client distribution Every invoice gives you a labeled data point: (sent_date, due_date, paid_date, amount, was_reminded) . Over time, per client, that's a distribution of "days from send to pay." The naive move is to average it. Don't — averages hide the shape, and the shape is the whole signal. We model each client's pay-day as a distribution and track two things that matter more than the mean: Dispersion — a tight distribution (always day 30–32) means a reminder before day 30 is noise. A wide one means the client is reminder-sensitive. Reminder lift — comparing paid-day distributions with and without a nudge tells you whether reminders actually move this client, and by how much. for client in clients : hist = paid_events ( client ) # list of days-to-pay p50 , p90 = quantiles ( hist , [. 5 , . 9 ]) lift = mean ( days_without_reminder ) - mean ( days_with_reminder ) # act just before the client's own habitual pay point, # but only if a nudge historically helps them if lift > MIN_LIFT_DAYS :