What it takes to onboard a new client's data.

Reporting is repeatable. It is the same shape every month, on the same sources, and once it works it keeps working. Onboarding is not repeatable, because it happens once per client and it turns on decisions nobody else can make for you.

Treating the two as one job is why adding a client feels like it should be free and is not. The monthly report can be made routine. The setup behind it cannot, because most of it is waiting on somebody to tell you which account is theirs.

Four things per platform, and only one of them is technical.

• The account identifier

  Every platform has an ID saying which account the data belongs to. It looks like the trivial part and it is usually the slowest, because the ID lives with the client rather than with you.

• Access that survives somebody leaving

  Granted to a role or a system user rather than to an individual's login. Access tied to a person disappears when that person changes job, and it disappears quietly, so the first sign is a gap in a report.

• The date to start from

  How far back you want this client's history. Worth deciding deliberately, because some of it stops being available to collect once the window on the platform has passed.

• What this client calls things

  Their campaign naming, the currency they think in, the timezone their week runs on, and what they count as a conversion. None of it is discoverable from the data.

Currency, timezone, naming and the conversion definition are all settled at setup or settled later under worse conditions. Made now, each is a conversation. Made after six months of reports, each is a migration, and every figure already sent to the client changes.

Write them down as you agree them. The place most agencies lose this is that the decisions get made in a call, applied correctly by the person who was on the call, and then reproduced differently by the next person, who never knew a decision had been taken at all.

Pull the first period, then put three figures side by side: yours, the platform's own interface, and whatever the client was using before. They will not match, and the differences are the most useful thing you will learn about this account.

Usually it is one of four things. A different date grain, a timezone offset shifting activity into the wrong day, a conversion window counting the same sale at a different moment, or test spend somebody excluded and nobody wrote down.

Resolve them before the first report goes out. A client who has the difference explained once treats your number as the authoritative one afterwards. A client who finds the difference themselves in the third month treats every number you have sent as provisional.

Some of this is reusable and some of it never will be. Reusable: the source list, the naming convention, the metric definitions, the report template, and the checks you run on the first period. Build those once and the tenth client benefits from all of them.

Not reusable: account identifiers, access, and the four decisions above. Those are per client and always will be, because they are facts about that client rather than about your process.

So the curve flattens and then stops flattening. Any plan that assumes onboarding eventually costs nothing will meet its limit at a certain roster size, and it meets it as a backlog rather than as a warning.

Onboarding is its own step and it is account identifiers per source, which is why it is separate from producing a report. Backfill runs from the date you choose at setup, so a client's history starts where you decided rather than where the pipeline happened to begin.

After that the client is a record. Everything scopes to it, and templates already assigned to the agency arrive pre-wired to that client's own tables, so the repeatable half stays repeatable as the roster grows rather than becoming another build. If the client wants a login to your portal, they get one that shows only their own data.