AI-embedded new service: how far to help clients onboard, and when to stop
When a client stalls in onboarding, walk one step through together and set how far you help and when it ends.
Key points
- Watch them do one step if setup stalls
- Assign owners per step in a 3-way sheet
- Give clients an end rule and a time cap
- Count the next request, not work you did
Contents
If onboarding stalls, watch them do one step
A&A perspective
When a client who agreed to a trial stalls in first-time setup, start by watching them work through one step themselves. Here, first onboarding means the preparation and setup a client needs, after agreeing to try the new service you started by building AI into your core business, to run their first real job through it.
A&A perspective
About a stalled trial, you know only two things: the client agreed to try it, and they have not used it yet. Between those two points, the reasons vary. Documents don't surface inside their company, an access request isn't approved, or the words on screen don't match what they call things.
A&A perspective
A service with AI built in adds one more reason. The client can't decide alone whether the output is fit to use in their company, and they stop there. More how-to documents won't fix that.
From the sources
Paul Graham, who has long invested in early-stage companies, told the early story of Stripe in a July 2013 essay, naming it one of the most successful startups they have funded. According to the essay, more diffident founders, when someone agrees to try the product, reply that they will send a link.
From the sources
The two brothers who founded Stripe did not send a link and wait. When anyone agreed to try Stripe, they would say "Right then, give me your laptop" and set them up on the spot, the essay says.
From the sources
Y Combinator, which makes small investments in early-stage companies, published a post in October 2018 in which partner Gustaf Alströmer answered founders' questions. As a question to ask users, he suggests having them actually do something and say out loud everything they are thinking as they go.
A&A perspective
Automate & Augment (A&A), the company writing this article, sees the difference between the two stories as who operates the product. The Stripe brothers finished the setup themselves; in Alströmer's question, the user operates. When a first client stalls, A&A chooses the latter.
A&A perspective
Only while the client's hands are on the controls can you see which word confused them and which screen they backed out of. If you type it in for them, the setup gets done, but you still won't know where the next client will stall.
From the sources
Graham also writes about operating the software himself. His team built online stores for merchants, using their own software on the merchants' behalf. He writes that this experience taught them how merchants would feel using the software.
Assign owners per step in the first-run step sheet
A&A perspective
Keep the first-run step sheet to one page, and for each step choose one of three owners: the client does it, you sit in and help, or it is out of scope this time. Make it something you can show your team or board as is.
A&A perspective
Unless there is a reason not to, the owner is the client. Documents only the client has, and actions the client will repeat, go in the client's column from the start. Sitting in is the exception, and when you choose it, write down why.
A&A perspective
The one step you watched first becomes one row of this sheet. Once you see where the client stalls, set owners for the remaining rows too. Sit-in rows can grow beyond the one row you watched.
A&A perspective
Write at least one out-of-scope row. A step sheet with no out-of-scope row is the same as help with no limit.
A&A perspective
Write the condition for ending help as a fact the client can check, such as "the client redid the setup with their own login" or "one job went through on a request the client wrote." Do not write it as whether you felt it was done.
Hypothetical example
Say a company that does research on clients' behalf starts a new service that reads clients' internal documents with AI and produces research reports. This is a hypothetical example, not a real client, with no prices or results. The first run could be split as in the table after this section.
A&A perspective
With this one page, when a question comes up mid-setup, you can check which row it belongs to before answering on the spot.
A&A perspective
The table's "Checking the AI output" row matters most in a service with AI built in. If the client can't judge pass or fail on the output themselves, a second request never comes.
| First-run step | Owner | Condition to end help |
|---|---|---|
| Preparing input documents | Client does it (only the client has the documents) | Client placed a second document on their own |
| Account setup | Sit in and help (the client operates) | Client redid the setup with their own login |
| First request | Client does it (advice only on how to word it) | One job went through on a request the client wrote |
| Checking the AI output | Sit in and help (have them put pass/fail reasons into words) | Client gave pass/fail reasons in their own words |
| Connecting to existing internal systems | Out of scope this time | Not touched this time; discuss separately when needed |
Give clients an end rule and a cap on sit-in time
A&A perspective
Once you decide to sit in, write down a time cap and an end condition before you start, and give them to the client. The cap is not there to save time. It is the line at which you rethink the approach.
From the sources
In the same essay, Graham writes that consulting-style attention is safe to give so long as you are not being paid to. So long as a product company is merely being extra attentive to a customer, he writes, the customer is very grateful even if you don't solve all their problems.
From the sources
But when customers start paying you specifically for that attention by the hour, he continues, they expect you to do everything for them.
A&A perspective
A&A thinks you should write down the scope and the end even when you start sitting in for free. When you move to paid help, write the scope all the more, before anyone expects "everything." For free and paid help alike, this view is not something the source states directly.
A&A perspective
If you reach the cap without meeting the end condition, it does not mean you helped too little. It is a signal that the problem lies in how the steps are split, or in how the service itself works.
A&A perspective
At that point you have three moves. If the step isn't needed for the trial, move it out of scope. If the step stalls no matter who operates it, rebuild the step itself. If the client shows no reason to keep trying, stop serving this client here.
A&A perspective
Writing down the third move, stopping, in advance matters. If it isn't written, you will keep extending help out of inertia even when a decision to stop is needed.
Hypothetical example
In the hypothetical, you sit in on only two rows: "Account setup" and "Checking the AI output." The cap is set for those two rows, say two hours in total. The note you hand the client could read like this.
Hypothetical example
"We will sit in for up to two hours in total for the initial setup and the first check of results. By the two-hour mark, the goal is that you can redo the setup with your own login and judge pass or fail on the results yourself. If we don't get there, we will review how the steps are split and talk it over with you."
Count the next request the client sends, not your work
A&A perspective
When you report the new service's adoption to your team or board, leave out the actions you finished on the client's behalf and count the next request the client sends on their own. If you did half the operating, all you can say is that it runs in this client's environment.
A&A perspective
To count the two apart, the surest way is to split the record columns. Add two columns to each row of the step sheet: "actions done for the client" and "actions the client finished themselves." Next week, look only at the second.
From the sources
Graham writes that when you only have a few users, you can sometimes get away with doing by hand things you plan to automate later. When you finally automate yourself out of the loop, he writes, you will know exactly what to build because you will have muscle memory from doing it yourself.
A&A perspective
A&A thinks hand-done work becomes a clue for what comes next only when what you did is on record. Write not "helped with setup" but "set the notification destination for them." If the same step keeps landing in the "done for the client" column for the second and third clients, that is the place to fix.
Hypothetical example
To continue the hypothetical, say that after sitting in, the account setup row shows "setting the notification destination" under actions done for the client, and "login, granting access, choosing the save location" under actions the client finished themselves.
Hypothetical example
Next week, what you check is whether the client sent a second request on their own. If they did, the next conversation is about the terms for continued use.
Hypothetical example
If they didn't, the client handled the login and access themselves, so you can rule out a stall in setup. What remains are reasons after setup, such as "there was no such work this week," "they forgot how to send one," or "they can't decide whether the output can be used in their company."
A&A perspective
If you merge the two columns and write "one adoption," you lose this narrowing. On the one page you give your team or board, keep the two columns separate too.
Summary
A&A perspective
When a client stalls in the first onboarding of your AI-embedded new service, watch them operate just one step.
A&A perspective
In the first-run step sheet, set each step's owner as the client, a sit-in, or out of scope this time.
A&A perspective
Give the client the time cap for sitting in and the end condition before you start.
A&A perspective
In reports, leave out what you finished for the client and count the next request the client sends on their own.
In the first onboarding of an AI-embedded new service, watch the client operate one step, then use a step sheet to set owners and the out-of-scope line, and hand over a sit-in cap and end condition up front. What you decide next is the sit-in cap for the second client, based on the time the first one actually took.
FAQ
Do you sit in even with clients who can already set it up themselves?
No. Sitting in is only for clients who stalled in first-time setup. You also don't perform actions for which the client's consent or access is not in place.
Is there a rule of thumb for the sit-in time cap?
There is no one-size-fits-all figure. The two sources cited here are both advice to early-stage companies, not studies that measured effects on retention or revenue. Use the time the first client actually took as the starting point for the second client's cap.
Does this step sheet also decide what to give the client on the first run?
No. This article covers who operates during first-time setup and where help ends. What to give back on the first run is covered in a separate article, "AI writing service as a new business: first session is one note on a draft."
Sources & editorial note
Primary pages read for this article. Publication dates below belong to the sources; access dates record our research.
- Do Things that Don't Scale
Paul Graham · July 2013
Accessed 2026-10-27 - Growth AMA with YC Partner Gustaf Alströmer
Y Combinator · 2018-10-29
Accessed 2026-10-27