An onboarding fee that actually covers setup

The first thirty days of a new engagement consumes far more delivery capacity than a steady-state month, and almost none of that extra effort is visible in the deliverable the client receives. Access requests, discovery, documentation, baselining, tooling, the first attempt at a report that gets rejected and rebuilt. It is real work and it produces almost nothing the client would describe as output.

Waiving the setup fee does not make that cost disappear. It moves it onto the monthly fee, which means the retainer has to carry both the ongoing work and the amortised setup, and it means a client who leaves in month four leaves you short.

This is not an argument that every engagement needs a setup fee. It is an argument that the decision should be arithmetic rather than habit. Compute what month one costs, decide how you are recovering it, and write that down.

Every row in that table is one-time, and the last two columns are why setup gets underpriced. The activities do not recur, so they do not belong in a monthly fee, and most of them are absent from the estimate entirely because they are invisible until you are inside the account.

The last row is the expensive one and the one nobody quotes. You cannot report on a measurement setup that is broken, so before the retainer can do its job, somebody has to fix the thing the retainer assumed was working. That is remediation, it is a build, and it is not what the client thinks they bought.

Separate it explicitly. A short paid discovery phase before the retainer starts, with its own scope and its own fee, is the cleanest structure available. It gives you the information to price the retainer properly and gives the client a real deliverable before they commit to twelve months.

The third column is the one that matters and the one people skip. You do not recover setup out of revenue, you recover it out of contribution, which is the fee less the cost of delivering that month. The 30 per cent used in the column is an illustration of the arithmetic, not a claim about what any agency earns. Substitute your own figure and the ratio holds: divide the setup cost by the monthly contribution and you have the payback period in months.

Run it once and the waived setup fee stops looking generous. If setup costs you twice a monthly fee and your contribution is a third of that fee, the client has to stay most of a year before the engagement has broken even, and every client who churns before then was a loss regardless of how well the work went.

The contribution figure is where most of the error lives, because it depends on your delivery cost and the utilisation you actually achieve rather than the one you plan for. Deriving it properly is the subject of designing a rate card you can defend, and the Business Development Bank of Canada's net profit margin calculator is a reasonable structure for establishing the margin side of it on your own numbers.

Charge it separately. A stated setup fee, invoiced at signature, covering a named list of one-time activities. Cleanest, most defensible, and it filters out clients who were never going to commit. The objection you will get is that a competitor does not charge one, and the answer is that the competitor is charging it inside the monthly fee where the client cannot see it.

Amortise it into a minimum term. No separate setup fee, but a stated minimum commitment long enough to cover the payback period you just computed. This is the structure most clients accept most easily, because it feels like a discount rather than a fee. Make sure the term is derived from the arithmetic rather than rounded to twelve months because twelve is a familiar number.

Absorb it deliberately. Sometimes correct: a strategic account, a sector you are trying to enter, a client whose reference is worth real money. The word that matters is deliberately. Absorbing a cost you have quantified is a decision. Absorbing one you never measured is a leak.

Whichever you choose, the boundary between setup and ongoing has to be written down in the same document that describes the retainer, because a fuzzy boundary means every month-two request is an argument about whether it was included. The document structure that carries that boundary is what statement of work scoping produces.

Onboarding has a start, an end, a deliverable set and a dependency chain. That is a project, and treating it like one removes most of the ambiguity that makes it expensive.

Decompose it. Atlassian describes a work breakdown structure as a way of breaking a project into smaller, more manageable components, which is exactly what turns an unpriceable blob called onboarding into a list of items you can estimate and check off.

Then give it acceptance criteria, so both sides know when it has finished and the retainer has started. Atlassian's definition of acceptance criteria as predefined requirements and conditions that a task must meet to be marked complete and accepted applies directly. Access granted to every named system. Baseline documented and signed off. Tracking verified end to end in the destination platform. First report produced and reviewed live.

A decomposed onboarding also becomes reusable, which is where the real money is. The clinical research program that was turned into 159 tracked work items with acceptance criteria, phased and sequenced is the extreme version of the same discipline. At agency scale it means the eleventh client's onboarding costs materially less than the first, because the list already exists.

Once onboarding is a checklist rather than a memory, the repetitive parts become automatable, and that is where the setup fee turns from a cost recovery into a margin.

Account and property provisioning, naming convention enforcement, template deployment, the standing report skeleton, the permission grants. None of it is intellectually interesting and all of it is done identically every time. The case for building it once is straightforward, and where it pays is covered in automating client onboarding steps.

Do not automate the discovery. The conversation where you find out how the client's business actually works, who signs things, and what the previous agency got wrong is the part that determines whether the engagement succeeds, and it is not a form.

A useful test for what to automate: if the output is identical for every client, build it. If the output depends on what someone tells you, book the meeting. Most agencies do the opposite, running the same discovery template on autopilot while hand-building the same GA4 configuration for the fortieth time.

Estimate the onboarding hours from the decomposed list, not from a memory of how long the last one took, because the last one is remembered as the version without the problems.

Apply your derived rate to those hours. Add a contingency for the remediation you will find, or exclude remediation explicitly and quote it separately when you find it. Excluding it is usually better, because it keeps the setup fee predictable and stops you carrying an unknown at a fixed price.

Then sanity-check the payback. If the setup fee you have landed on still leaves a payback period longer than a typical client relationship, the structure is wrong rather than the number: either the minimum term needs to be longer or the setup work needs to be smaller.

One last fence. How a setup fee is recognised and recorded is your accountant's question, not a pricing one. What belongs in the pricing conversation is what the fee covers, when it is invoiced, and what the client gets for it. Answer those three in writing and the rest is somebody else's department.