Open the last three onboardings you finished. Write down the contract date and the date you told the customer they were live.
If those two dates were never written in the same place, you do not know how long onboarding took. You are guessing.
Most articles skip that and give you a table: two weeks for small accounts, thirty days for mid-market, ninety for enterprise. Those numbers are almost never sourced. They do not know your product, your integrations, or whether this customer has anyone doing the work.
How long should customer onboarding take? As long as it takes to reach a first-value event you both named, and no longer than a date you can justify from your own past projects plus what you know about this customer.
How long should customer onboarding take?
Nobody outside your company can give you the number.
A published range is about someone else’s product and someone else’s idea of “done.” Even a careful range would still be the wrong number for this customer.
You need a real date. Teams usually do one of two things instead, and both fail.
They say “it depends on the customer.” That is not a date. Sales cannot set expectations. The customer cannot plan their time. You cannot tell a late project from a normal one.
Or sales picks a date because it helped close the deal. That date was never based on how long the work actually takes. Implementation then spends the project explaining why it was never realistic.
A date you can keep comes from three things, in this order:
- Your finished onboardings, timed the same way each time.
- What about this customer makes the work longer or shorter than those past projects.
- Written rules for when the date moves, agreed before anyone is late.
If you do not have enough finished projects yet, say that. Commit after kickoff, once you have owners and a first-value event. The kickoff is where the date should be written down.
What are you actually measuring?
Teams argue about length while timing four different things.
| What you time | Starts | Ends | What it tells you |
|---|---|---|---|
| Signature to kickoff | Contract signed | First working session | How fast you start |
| Signature to go-live | Contract signed | ”Live,” if you defined it | Whether setup is finished, if “live” is a real event |
| Signature to first value | Contract signed | Customer uses the product for a real job they bought | Time to the outcome they paid for |
| Signature to working without you | Contract signed | They can run the important work without your team | When you can step back |
These are not the same. A project can be “live” in your CRM and still waiting on the first real workflow. Another can deliver first value while your team still does every admin task.
Promise signature to first value.
First value is the first time the customer does a job they paid for, in their environment, with their data, well enough that they would accept it without you in the room. “Admin account created” is not that. “Ops lead used the weekly report in Monday’s meeting” can be.
Go-live is fine as a checkpoint if it means something concrete: production login in use, first live transaction, first campaign sent. Do not promise against go-live if your team means “every setup ticket is closed.” That list grows forever.
Keep the other intervals. Signature to kickoff shows whether the sales-to-onboarding handoff is wasting days. First value to working without you shows whether they still need you for the important work. Report them separately. One mixed number explains nothing.
Write what the date means next to the date. “Onboarding complete” is not a definition.
How do you derive your own number from your last N onboardings?
Do this this week.
1. Choose one end event. First value, in one sentence. Use that sentence for every project. If an old project has no first-value date, skip it or rebuild it from something real (first production ticket, first live send, first approved report). Do not guess.
2. Pull the last 15–20 finished onboardings that look like the work you sell most often. Same product. Same delivery model. Do not mix a two-hour self-serve setup with a multi-system implementation and then average them.
3. Record four dates per project: signature, kickoff, first value, and the date you left the important work, if you have it. Start and end give you the length. The extras show where time went. Use the metrics guide once you have the dates.
4. Look at the range, not the average. Sort the lengths. Write the shortest, the middle, and the longest. The long ones usually share a cause you already know: a security review, no customer owner, a data import sold as simple.
5. Promise a date you usually hit, not the average. If you promise the average, about half of similar future projects finish later than that. Customers remember the miss. They do not give you credit for the early ones that pulled the average down.
Example only: a team with 20 finished onboardings might see most projects land between five and nine weeks, with two at fourteen because a security review sat in the way. Promising “seven weeks” because it sits near the middle would miss the long ones. Promising a date that already covers most of the group, and saying a security review adds time, is a date you can keep.
If you have fewer than ten similar finished projects, do not pretend you have a pattern. Promise the longest clean one. Treat anything faster as a bonus you do not sell in advance.
Do not mix unlike work. Agency retainers, product-led seats and enterprise implementations are different jobs. The agency version is in client onboarding for agencies.
What actually makes onboarding longer?
Once you know your usual length, adjust it. These are the usual reasons a project runs long. Several sit on the customer’s side. That is why you write down what the date depends on.
Integrations and data migration. One SSO login is not the same as three systems plus a history import that has to be clean enough to run payroll. Count the systems that must work before first value, not the systems on the sales slide.
Number of approvers. Every extra person who must sign off adds waiting, not work. Ask who can say yes without a committee.
Security, legal or procurement still in the way. If a review can block access, logins or the right to put data in your product, it can stop the project even if sales called the deal closed. Give it an owner and a date.
How much you wait on the customer. Exports, brand files, decisions, sample records, approved workflows. The more first value needs those, the more your date is their date. The questionnaire should ask only for what blocks that first event.
Whether anyone on their side is assigned. No named owner adds weeks. A busy owner who cannot pull in colleagues is next. Ask who gets in trouble if this is late. If the answer is “a steering group,” you do not have an owner.
Write the adjustment in one sentence next to your usual length. “This looks like our nine-week group, plus a security review we have seen add a month, minus a single-system scope.” Do not add a vague “enterprise” buffer.
What should you actually put in writing?
A date. What that date means. The customer tasks it depends on. What happens when a task is late.
A weak version:
Target onboarding timeline of four to six weeks, depending on customer availability and complexity.
Nobody can plan around that. Nobody can say you missed it. “Depending on” names no owner and no consequence.
A version you can keep:
First value is the weekly operations report running from live data in your production account, used by the ops lead in a real meeting. Target date: 3 November. This date holds if (1) Priya Shah completes the data export in the agreed format by 8 October, (2) IT grants production SSO by 15 October, and (3) no security review is opened after kickoff. If a numbered item misses its date, first value moves by the same number of working days. If a security review is opened, we will send a new date within three working days of knowing how long the review takes.
Put that where both sides can see it after the call. A shared plan the customer can open without creating an account is enough; Valuecase is one way to keep the date, owners and conditions in that kind of Space. A shared doc beats a project plan only your team can open.
Say the same thing at kickoff. If sales quoted a different window, fix that before the customer hears both.
Keep it with the rest of the plan, not in a side email. If you still need that plan, start from a process and a checklist that already have owners and done-when tests.
What do you do when the date is going to slip?
Change the date when a named task is late. Not when the original date is close.
Here is the usual mess. A customer export misses 8 October. Your plan still says 3 November. Everyone pretends the old date is real. Two weeks later you admit it is not. The customer hears a surprise, not the rule you already agreed.
Do this instead:
- On the task’s due date, check if it is done or stuck.
- The same day it is missed, move the date in the shared plan.
- Write to the customer: what slipped, the new first-value date, and which tasks still apply.
- If it stays stuck, use the escalation path you set at kickoff.
The person who owns this customer on your side should send that note. Not a shared inbox. Not a quiet edit to a date field.
A useful note:
The data export was due 8 October and is not in. Under the conditions we agreed, first value moves from 3 November to 12 November if the export arrives by 15 October. If it arrives later than that, we will send a new date the day we have it. Priya remains the owner.
If you leave an old date in the plan, both sides stop treating dates as real. If the project has gone quiet rather than missed a known task, use the restart sequence.
How do you make the number shorter?
Do not publish a tighter date and leave the work the same. You will miss it again.
Cut work that blocks first value. Order tasks so a late customer item does not stop everything else. Ask for fewer inputs up front. Get a real owner. Drop scope the customer does not need for the first job they will actually do.
That is a separate job. Use how to reduce time to value for the sequence, and the stall guide when the project has already gone still.
Your usual length should drop after you change the work, not after you change the slide. Recalculate from new finished projects. Until then, keep promising the date you can already keep.
Take your last 15 similar onboardings this week. Pick one definition of first value. Write the dates down. Your number is already in that list.