Our new client onboarding checklist, in full

A slow start to a project is rarely the agency's fault alone; it's usually a missing access credential or an unanswered question sitting in someone's inbox for a week. Our onboarding checklist exists specifically to front-load every dependency so the actual work can start moving immediately, and we've refined it after enough projects to know exactly where delays tend to originate.

It's tempting for an agency to treat onboarding as a formality to get through quickly on the way to the "real" work, but that framing gets the order of operations backward. The projects that move fastest overall are consistently the ones where onboarding was treated with the same seriousness as the design or development phases, not rushed through as a box to check before the interesting work begins.

Domain registrar, hosting or DNS provider, existing CMS admin, analytics, and any third-party tools we'll need to integrate with. We ask for all of it in the first onboarding call rather than discovering a missing credential in week three when we actually need it, which is a common and entirely avoidable source of delay.

We use a shared password manager specifically for this, rather than emailing credentials back and forth, both for security and so there's a single, current source of truth rather than an outdated credential sitting in an old email thread nobody can find later.

Every client fills out who has final sign-off authority on design and content decisions. Not who's involved, who decides. Projects with an unclear decision-maker are the ones most likely to cycle through multiple rounds of conflicting feedback, because two stakeholders can each approve a direction the other one later reverses.

We ask this question directly rather than inferring it from who shows up on the first call, because the two aren't always the same person. A marketing manager who runs point on communication isn't necessarily the person with final sign-off, and assuming otherwise has cost us real revision cycles in the past, when a design approved by our day-to-day contact got reversed by someone more senior who saw it for the first time weeks later.

Logo files, brand guidelines if they exist, past design files, even ones the client is embarrassed by. Seeing what's already been tried, including what didn't work, tells us more about a client's actual taste and constraints than a mood board built from scratch.

A client who shares an abandoned design direction alongside an explanation of what didn't work about it, too corporate, too playful, the client's boss hated it, saves us from re-proposing a direction that's already been tested and rejected. That kind of history is uncomfortable to share but genuinely valuable, and we make a point of asking for it directly rather than waiting for a client to volunteer it on their own.

We ask for actual copy, or a clear commitment on who's writing it and by when, before design starts rather than designing around lorem ipsum and hoping real content fits later. Content gaps discovered during development are one of the most common causes of late-stage timeline slippage we see.

"We'll have copy ready by then" is one of the most common onboarding promises that doesn't hold up, not out of bad faith but because writing real copy is genuinely harder and slower than most non-writers expect. We ask for a specific commitment with a specific date attached, and if a client doesn't have writing resources lined up, we flag that as a project risk in week one rather than discovering it as a bottleneck in week seven when development is ready for content that doesn't exist yet.

Beyond the sales and scoping conversation, we schedule a separate kickoff call specifically with the people who'll be doing the day-to-day work on both sides, our project lead and the client's actual point of contact, so the working relationship starts with a real conversation rather than an email thread introducing two people who've never spoken.

We don't block the whole project on one missing item. We flag exactly what's outstanding, what it's blocking, and by when we need it to stay on schedule, so a client with a slow IT department for domain access, for example, knows precisely what's at stake rather than getting a vague "we're still waiting on some things" update.

This specificity matters because a vague delay warning tends to get deprioritized against whatever else is competing for a client's attention that week. "We're waiting on DNS access" is easy to ignore. "We're waiting on DNS access, and it's currently blocking the staging environment setup that needs to happen before design review can start next Tuesday" gets escalated internally on the client's side far more reliably, because the actual stakes are visible rather than implied.

For a small handful of clients on a compressed timeline, we've built a condensed version of this checklist covering only the items that would actually block week one work from starting: access, the named decision-maker, and a commitment on content timing. Everything else can follow in the first week without costing real time, since those three items are the only ones that sit directly on the project's earliest critical path.

Every item on this list is something that has, at some point, caused a real delay on a real project when it was missing. The checklist isn't bureaucracy for its own sake, it's a running list of past failure points converted into a preventive step.

We update it every time a new project surfaces a delay we hadn't anticipated, which means the checklist has genuinely grown longer over the years, not because we enjoy adding process, but because each addition represents a real week or two of delay that happened to an actual client project before we started asking about it upfront.