The information you don't collect at the start is the information you'll be chasing halfway through the project when it's suddenly urgent. A simple onboarding checklist means fewer awkward gaps and fewer delays caused by missing details.
There's a particular sort of preventable chaos that happens when you're three weeks into a project and suddenly realise nobody knows who's actually approving the final deliverables, or that the client's brand guidelines are locked in someone's drawer who's currently on holiday in the Maldives. It's avoidable chaos, which somehow makes it more annoying than the unavoidable kind.
A proper client onboarding process isn't about being officious or creating unnecessary bureaucracy. It's about not having to send increasingly desperate emails later when you're up against a deadline and missing something fundamental. Think of it as future-proofing against your own frustration.
The basic contact information (boring but essential)
Start with the obvious stuff, because the obvious stuff has a way of not being quite as obvious as you think. You need more than just one email address for one person who might be on annual leave when you need a quick answer.
Primary contact name, email, phone number, and their actual job title
Who covers when the primary contact is unavailable
Decision-makers and approvers (these aren't always the same as your day-to-day contact)
Any other stakeholders who'll inevitably appear halfway through with opinions
Preferred communication channels and response time expectations
Time zones if you're working across borders
It's worth noting whether your contact prefers email, phone calls, carrier pigeon, or has strong feelings about being messaged after 5pm. Some people live in their inbox; others treat email like a monthly obligation they get round to eventually.
Project scope and objectives
This is where you establish what you're actually doing and why, which sounds straightforward until you realise that different people often have different ideas about what they've commissioned. Get it in writing now, whilst everyone's still optimistic and agreeable.
Specific deliverables with descriptions detailed enough that there's no room for creative reinterpretation later
What success looks like for this project (actual metrics, not vague aspirations)
What's explicitly out of scope (arguably more important than what's in scope)
The business problem this work is meant to solve
Any context about why this project exists now
The "out of scope" bit tends to feel awkward when you're trying to start a positive working relationship, but it's significantly less awkward than having the scope-creep conversation when you're halfway through. "As we discussed at the start" is much easier than "this wasn't part of the original brief" when someone's already expecting something.
Timeline and availability
Deadlines are fairly useless without knowing when people are actually available to provide feedback, approvals, or the various bits of information you'll need along the way. A two-week turnaround sounds reasonable until you discover the key decision-maker is available for approximately forty minutes across those two weeks.
Final deadline and any immovable dates along the way
When you'll need feedback or approvals from the client
Any holidays, conferences, or blackout periods
How long they typically need for review and approval
Consequences of missing the deadline (is this genuinely urgent or optimistically urgent?)
It's also worth understanding whether the deadline is "we're announcing this at a conference on the 15th" or "we'd quite like it by the 15th but it's not the end of the world". These are rather different situations masquerading as the same deadline.
Access and assets
Few things create delays quite like needing access to something that requires three people to approve, two systems to navigate, and IT to raise a ticket that takes five working days to process. Sort this out before you need it urgently.
Login credentials for any systems, platforms, or tools you'll need
Brand guidelines, style guides, tone of voice documents
Existing assets (logos, images, fonts, previous work)
Access to relevant drives, folders, or documentation
Any templates or formats that must be used
Legal or compliance requirements
If something requires security clearance, Non-Disclosure Agreements, or approval from someone who's notoriously difficult to pin down, you want to know that now, not when you're trying to start the actual work.
Budget and payment terms
Money is awkward to discuss, which is precisely why you should discuss it clearly at the start when it's only theoretically awkward, rather than later when it's awkward and also causing actual problems.
Total budget and payment schedule
Purchase order numbers or whatever bureaucratic identifiers are needed
Process for approving additional costs if scope changes
Who handles invoicing queries
Payment terms and method
What happens if the project is paused or cancelled
Understanding the client's payment process matters more than you'd think. Some organisations pay invoices within days; others have baroque approval processes that take six weeks and require forms in triplicate. This affects your cashflow planning somewhat.
Communication and reporting
Establishing how you'll actually work together prevents the situation where you think everything's going brilliantly and the client thinks you've disappeared into a void, or vice versa.
How often you'll have check-ins or progress updates
Format for these updates (quick email, detailed report, video call where everyone's camera is off)
How to handle urgent issues or roadblocks
Preferred file sharing methods
How feedback will be collected and consolidated
Who needs to be copied on what
Some clients want detailed weekly reports; others are perfectly happy with a message every fortnight saying "all fine, progressing as planned". Neither approach is wrong, but you do need to know which type you're dealing with.
Technical requirements and constraints
Every organisation has its peculiar technical requirements, legacy systems, or IT policies that seem designed to make everything slightly more complicated than it needs to be. Find out about these before they surprise you.
File formats and compatibility requirements
Any systems or software that must (or must not) be used
Security or data protection requirements
Accessibility standards that need to be met
Browser or device compatibility needs
Hosting, deployment, or handover requirements
Discovering that everything needs to be compatible with Internet Explorer 11 or that files can't exceed 10MB due to email policies is the sort of information that's helpful to have from day one.
Sign-off and approval process
This might be the most important section, because even the best work sits in limbo if nobody knows whose approval is actually needed or who has the authority to say "yes, this is done".
Who needs to approve what, and in what order
How many rounds of revisions are included
What constitutes final approval
Process if approvers disagree with each other
Turnaround time expected for approvals
What happens if feedback contradicts previous approved decisions
The nightmare scenario is when you think you're done, but then the work needs to go to someone senior who hasn't been involved and has comprehensive thoughts about starting from scratch. Knowing the approval chain upfront means you can involve the right people at the right time.
Actually using your checklist
Having a checklist is pointless if it lives in a drawer and gets ignored because it feels like too much effort when you're keen to just crack on. Build it into your actual process—send it as part of your proposal acceptance, schedule a proper kick-off call to go through it, or include it in your project management system.
Not every project needs every item on this list, and some will need additional things specific to your industry or type of work. The point isn't to create a bureaucratic obstacle course; it's to spend an hour at the beginning collecting information that will save you days of delays and confusion later.
You'll still have surprises—clients will remember crucial information they forgot to mention, requirements will change, and unforeseen complications will emerge. That's just how projects work. But you can at least eliminate the predictable problems, which leaves more energy for dealing with the genuinely unexpected ones.
Useful answers
Frequently asked questions
- What's the most important thing to ask a client before starting a project?
- Who approves the final deliverables and in what order. Even brilliant work goes nowhere if you don't know whose sign-off you actually need, and discovering there's a senior stakeholder with veto power halfway through is a nightmare you can easily avoid.
- How do I handle scope creep without damaging the client relationship?
- Define what's explicitly out of scope during onboarding, in writing, while everyone's still agreeable. It feels awkward upfront but saying 'as we discussed at the start' is much easier than arguing about whether something was included after the client's already expecting it.
- What client information causes the most delays if you don't get it early?
- Access credentials and brand assets. Needing logins that require three approvals and an IT ticket, or brand guidelines locked in someone's drawer while they're on holiday, will stall your project immediately. Sort out access to systems, tools, and all necessary files before you actually need them.