Atlas
  • All-in-one
  • Solutions
  • Compare
  • Pricing
PricingGet started
  1. Atlas
  2. Guides
  3. Client Onboarding for Advisory Firms: The First Two Weeks
August 30, 2026·11 min read·client onboarding, mobilisation, professional services, engagement management

Client Onboarding for Advisory Firms: The First Two Weeks

Most engagements that finish late were already late by the end of week two, and nobody noticed because nothing had visibly gone wrong.

Mobilisation is the phase with the least visible output and the greatest leverage. Nothing is delivered, so nothing appears to be at risk. Meanwhile the decisions that determine whether the engagement can run at pace are being taken or deferred: who the client contacts are, what access exists, what data will arrive and in what form, and who is allowed to say yes.

The failure is almost always deferral rather than error. Each item is left because it seems minor next to starting the analysis, and the accumulated delay surfaces in week six as a schedule problem with no single cause.

Days one to three: the commercial and legal foundation

  • The engagement letter or contract is signed. Starting work on an unsigned letter is common and it removes every protection the letter contains at the moment it is most likely to be needed.
  • Acceptance is complete and recorded, including conflicts, independence and any safeguards imposed as a condition.
  • The billing arrangement is set up on the client side, including a purchase order if one is required. A purchase order raised in month three delays the first invoice by longer than anyone expects.
  • The engagement is created in the firm's systems with its fee model, budget and team, so that every subsequent record attaches to something real rather than being reconciled later.

Days two to five: people and access

Name the counterparts, not the roles. An engagement that lists "finance team" as a dependency has no dependency; it has a hope. Each workstream needs a named client contact with a stated availability, and the sponsor should confirm those names rather than the team assuming them.

Access is where mobilisation most often stalls, because it depends on a client function with no stake in the engagement. Request it on day two, request all of it at once, and state precisely what is needed: which systems, at what permission level, for which named people, and by when. A request that arrives in pieces gets processed in pieces, each with its own queue.

Set up client-side visibility at the same time. If the client is to have a portal, invite the contacts during the first week while the engagement is a novelty, not in month two when it is one more thing to log in to.

Days three to eight: the plan and the request list

The plan agreed at proposal was built on assumptions. Mobilisation is where those assumptions meet the client's calendar, holiday periods, board dates and reporting cycles. Rebaseline once, deliberately, in the first two weeks, and state what changed and why. A plan that is quietly out of date from week one is a plan nobody trusts by week five.

Issue the information request list in full, in one document, with a named owner and a date for each item. Partial lists teach the client that more is coming, which encourages batching on their side, which is the most common source of delay in the whole engagement.

Days five to ten: governance and the first report

Agree the governance schedule explicitly: who is on the steering committee, how often it meets, what the status ladder means, who can approve a change and up to what value, and what happens when the approver is unavailable. Doing this while the relationship is comfortable is far easier than doing it during the first disagreement.

Then issue the first status report in week two, even though there is little to report. Its purpose is to establish the format, the cadence and the expectation that the section headed "needed from you" is answered. A first report issued in week five never establishes that expectation.

The omissions that cost the most

  • Nobody confirmed who can accept a deliverable, so the first acceptance takes three weeks to obtain.
  • The data was requested without specifying the format, and arrives as a report rather than an extract.
  • Client holiday and reporting periods were not mapped, and a milestone lands in the client's year-end close.
  • Security or vendor onboarding on the client side was discovered in week three and takes a month.
  • The team began work before access existed and burned budget on preparation that had to be redone.

A mobilisation exit check

Treat the end of mobilisation as a gate with conditions rather than a date that passes. The conditions are short: the contract is signed, access is granted and tested by a named person, the request list is issued and acknowledged, the plan is rebaselined and agreed, the governance schedule is agreed, and the first report has gone out.

If any condition is unmet at the end of week two, that is the first status item, and it should be raised while it is still a mobilisation problem rather than after it has become a schedule problem.

Keep reading

  • Engagement Acceptance: What to Check Before the First Billable Hour
  • Engagement Management Software: What It Actually Has To Do
  • Building a Delivery Playbook Your Firm Will Actually Use
  • Building a Rate Card That Holds Up in Negotiation
  • How to Close an Engagement Properly
  • How to Write a Weekly Status Report a Client Actually Reads
  • Free PDF tools
  • The all-in-one work OS

FAQ

Questions, answered.

What should happen in the first two weeks of a consulting engagement?
Sign the contract and complete acceptance, set up billing including any purchase order, create the engagement in the firm's systems with its fee model and budget, name the client counterparts for each workstream, request and test all system access at once, issue the full information request list with owners and dates, rebaseline the plan against the client's calendar, agree the governance schedule, and issue the first status report.
Why do engagements stall during mobilisation?
Because mobilisation has no visible output, so deferral looks harmless. Access requests depend on a client function with no stake in the engagement, information requests arrive in pieces and are answered in batches, and the plan is not rebaselined against the client's real calendar. The accumulated delay surfaces weeks later with no single identifiable cause.
Should an information request list be issued all at once?
Yes, in one document with a named owner and a due date for each item. Partial lists teach the client that more is coming, which encourages them to batch their responses. Batching on the client side is the single most common source of delay in an engagement.
When should client portal access be set up?
During the first week, while the engagement is new and the contacts are engaged. Invitations sent in month two compete with everything else the client is doing and are frequently ignored, which means the portal never becomes the place the relationship runs.

Ready when you are

One workspace, not ten.

Atlas replaces the stack with one platform for tasks, projects, CRM, contracts, e-signature, PDF tools, and analytics. Start free.

Get started freeSee pricing
AtlasWork, planned itself.

The AI-native, all-in-one work platform. Tasks, projects, CRM, contracts, and analytics in one calm workspace.

All systems operational
  • SOC 2 II
  • ISO 27001
  • HIPAA
  • GDPR

Product

  • Overview
  • PDF tools
  • Diagram tools
  • People & HR
  • Integrations
  • Marketplace
  • Pricing

Resources

  • Guides
  • Glossary
  • Compare
  • Docs
  • API reference
  • Support
  • Changelog
  • Status

Company

  • About
  • Careers
  • Press
  • Contact

Legal & trust

  • Trust center
  • Security
  • Privacy
  • Terms
  • DPA
  • GDPR
  • SLA
  • Refunds
  • Google API data
Atlas, a product by wrxstack.com·© 2026 wrxstack·All rights reserved
PrivacyTermsSecurityStatus