Written by The problem: results are delivered, payment isn’t
Growth marketing work is easy to under-bill for the same reason it’s easy to under-value: the deliverable is often a report, a set of experiment results, or a live campaign — not a physical product with an obvious “done” moment. That fuzziness bleeds into payment. You wrap up a funnel audit or an A/B test cycle, send the findings, and then wait while the client’s “we’ll process it at month end” clock quietly starts.
The fix isn’t a heavier invoicing process. It’s making payment part of the delivery message instead of a separate step that depends on someone else remembering to act on it.
Why the old workflow stalls
The typical sequence — deliver, invoice, wait, follow up — breaks down for reasons that have nothing to do with whether the work was good:
- Invoices read as paperwork, not as an action with a deadline.
- Approvals get stuck with whoever isn’t in the room (a manager, a finance contact who wasn’t on the project).
- International clients add currency conversion and bank-transfer friction on top of the delay.
- Smaller retainers or one-off audits don’t justify setting up a full vendor/invoicing relationship.
A payment request — a link the client can pay immediately — collapses that chain: deliver, send the link, done.
A workflow that fits how growth work actually ships
- Finish the deliverable (audit, sprint, campaign setup).
- Package the results in a short, skimmable summary.
- Send the payment request link in the same message as the summary.
- The client pays, or forwards the message internally if they need approval first.
The order matters: if the payment request arrives in a follow-up message rather than the handoff itself, it becomes a second task the client can defer.
Example scenarios
Funnel audit. Deliverable: a written breakdown of drop-off points across the signup or checkout flow, with prioritized fixes. Send the audit doc and the payment request together — don’t wait for the client to “review and get back to you” before billing; the audit itself is the deliverable.
Experiment sprint (A/B tests). Deliverable: a defined set of tests run over an agreed period, with results and a recommendation. Bill at the end of the sprint, tied to the number of tests run or the time period agreed at the start — not to whether every test produced a winning variant, which isn’t something you control.
Paid ads setup. Deliverable: campaign structure, targeting, and initial creative live in the ad platform. This is a clear, verifiable “done” — the campaign is either running or it isn’t — which makes it a good moment to attach a payment request.
Lifecycle email optimization. Deliverable: updated sequences, triggers, or segmentation live in the client’s email tool. Same principle: once it’s live and verifiable, that’s the payment moment, not “once we see the open-rate lift.”
What to include with the request
A short summary block next to the link avoids the most common source of delay — the client being unsure what exactly they’re paying for:
- What was delivered (the audit, the sprint’s test count, the campaign, the sequence)
- Where to verify it (a doc link, the live campaign, the live sequence)
- The payment request link
A note on retainers
For ongoing growth work billed monthly, a reusable payment link shared once (rather than a fresh request each cycle) can reduce friction further — see payment links for how that differs from a one-off payment request.
Using Gitpay
Gitpay lets service providers create a payment request and share the link directly with a client — useful for exactly this kind of project-based marketing work where there’s no ongoing invoicing relationship to fall back on.
Where to go next
- How our payment works — fees and how payouts are connected to Stripe, Whop, or PayPal.
- How to request payment after delivering software work — the same workflow applied to code delivery, if that’s part of your scope too.
If you want to try this instead of waiting on an invoice, create your next payment request on Gitpay.
