The deal closed six weeks ago and nobody can say whether the customer is live. Here is the model behind a tracker, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
A customer onboarding tracker is four parts: a plan generated from what the customer bought rather than one checklist for everyone, tasks split by who owns them including the customer, a definition of live that everybody agreed before starting, and time-to-value measured from the close date. The part teams get wrong is customer-owned tasks. Most onboarding delay is waiting on the customer for data, access or a decision, and a tracker that only shows your own tasks reports green while nothing moves.
Customer onboarding
14
In flight
3
Stalled over 14 days
62%
Of delay is customer-side
41 days
Median close to live
Halden Foods
410K · closed 19 days ago, not started
Vantor
135K · 5 weeks in this stage
Fenwick
48K · on track
Northrise
240K · waiting on their export, 11 days
Brightsea
88K · live date 14 Oct
You run customer success, onboarding or implementation. Deals close and then something happens for six weeks that nobody can describe. What you want is one view per customer, an honest picture of who is holding things up, and a number for how long it takes.
What happens between a deal closing and a customer actually using what they bought.
Products, integrations, user count, whether there is migration or a security review. One checklist for every customer serves nobody.
Counted separately, so nine outstanding tasks with seven of them theirs is a different conversation.
Specific and checkable. An onboarding with that field blank is the one that runs for six months.
Which turns the weekly status meeting from an argument into a list.
A customer stuck in configuration for five weeks is a renewal risk before it is a delivery problem.
Because close to kickoff is usually the biggest interval and the one nobody owns.
An onboarding tracker is not a project plan per customer. It is four parts, and the second one is what makes it honest.
Tasks assembled from what the customer bought: which products, which integrations, how many users, whether they need data migration or a security review. A single checklist serves nobody.
Ours, theirs, and joint, each visibly separate. Customer-owned tasks are where the time goes, and hiding them makes the report useless.
Written down before kickoff and shown on the record. Onboarding without a finish line does not finish; it fades.
Measured from the close date, through kickoff, to first value and to live. The close-to-kickoff gap is usually the largest and least owned part of it.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
Not one checklist for everybody.
In this Helix project, build me a customer onboarding tracker.
An onboarding record per customer: account, close date, contract value,
products bought, our owner, their project lead, target live date, current
stage, and status.
Then task templates with conditions, so the plan assembles itself. Each
template has a description, an owner side (us, them, or joint), a stage,
a day offset from kickoff, whether it blocks progress, and the conditions
under which it applies.
Conditions run over what the customer actually bought: which products,
whether they need data migration, whether a security review is required,
how many users, which integrations, whether they are regulated.
A customer buying one product with no migration should get eight tasks. A
complex enterprise rollout should get forty. Giving both the same
checklist means the first is annoyed and the second is under-served.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.The single most useful thing this app does.
Now split tasks by who owns them, and make the customer-owned ones as
prominent as your own.
Three owner types: us, them, joint. Every task has one, plus a named
person on that side.
Show a per-customer view with three columns, and count them separately.
"Nine tasks outstanding, seven of them theirs" is a completely different
conversation from nine outstanding tasks.
Track how long each task has been waiting, and report waiting-on-customer
time separately from our own. Most onboarding delay is a customer who has
not sent the data, granted the access or made the decision, and a tracker
that reports only our tasks says green while nothing moves.
Give the customer their own view if you want them to have one, showing
only their tasks and the overall progress. Nothing internal.Worth knowing. Reporting waiting-on-customer time separately is what turns a status meeting from an argument into a list.
Because onboarding without a finish line fades rather than finishes.
Add a written definition of live, agreed at kickoff and shown on the
record.
It should be specific and checkable: which integrations are connected,
how many users are active, which workflows are running in production,
what the customer has confirmed. Not "the customer is happy".
Then add stages between kickoff and live, with entry criteria: kickoff,
configuration, data migration, integration, training, pilot, live. Let me
edit that list, and show the criteria when somebody moves a customer
forward.
Flag any onboarding with no definition of live recorded. Those are the
ones that run for six months, and the absence of that field is the
earliest warning you get.Because the gap nobody owns is at the start.
Last, the measurement, and start the clock earlier than feels natural.
Track four intervals: close to kickoff, kickoff to first value, first
value to live, and total close to live. Report them separately.
Close to kickoff is usually the largest and is owned by nobody, because
sales think they have handed over and delivery think it has not started.
Measuring it is the whole reason to start the clock at close.
Surface stalled onboardings ranked by contract value and days stalled,
and show them to the account team as well as the delivery team. A
customer stuck in configuration for five weeks is a renewal risk before
it is a delivery problem, and the account owner usually finds out last.
Then report time to live by product and by segment, the tasks that most
often block, and the proportion of delay that was ours versus theirs.
That last number will be uncomfortable and it is the one worth having.The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<Salesforce>. Read the closed deal, what they bought and the contract
value, and write onboarding status back so the account team can see it.
<Okta>. Authenticate internal staff, kept separate from however customers
sign in, so the app can tell the two apart before deciding what to show.
<Slack>. Chase the owner of a blocking task, and tell the account team
when an onboarding stalls.
<Gmail>. Send the customer their outstanding tasks, which is most of what
an onboarding manager does by hand.
<Amplitude>. Read whether the customer has actually started using the
product, which is the honest test of first value.
<Zendesk>. Show tickets raised during onboarding, since a customer
struggling usually appears here first.
<Google Drive>. Hold the migration files and configuration documents
alongside the plan rather than in an email thread.
<Snowflake>. Push onboarding history into the warehouse so time to value
by product and segment is a query.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. If you give customers a view of their own tasks, set Access Control before sharing so they see only theirs.
An onboarding tracker sits between the deal and the product, so it reads from both ends.
Salesforce
Read the closed deal, what they bought and the contract value, and write onboarding status back so the account team can see it.
Okta
Authenticate internal staff, kept separate from however customers sign in, so the app can tell the two apart before deciding what to show.
Slack
Chase the owner of a blocking task, and tell the account team when an onboarding stalls.
Gmail
Send the customer their outstanding tasks, which is most of what an onboarding manager does by hand.
Amplitude
Read whether the customer has actually started using the product, which is the honest test of first value.
Zendesk
Show tickets raised during onboarding, since a customer struggling usually appears here first.
Google Drive
Hold the migration files and configuration documents alongside the plan rather than in an email thread.
Snowflake
Push onboarding history into the warehouse so time to value by product and segment is a query.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working tracker. It may be shown to customers and it feeds a renewal conversation, so it needs to be run properly.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
If customers get a view of their own tasks, this has internal and external users. SSO plus scoped access is what keeps a customer to their own onboarding and away from anything internal.
App Security
Reading closed deals and writing status back to the CRM needs real access. Granting it to the app rather than pasting a key into it means it can be rotated or revoked without a redeploy.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
It generates an onboarding plan from what each customer bought, splits tasks by who owns them including the customer, holds an agreed written definition of live, and measures time to value from the close date.
Because most onboarding delay is waiting on the customer for data, access or a decision. A tracker that only shows your own tasks reports green while nothing moves, and the status meeting becomes an argument rather than a list.
Because a customer buying one product with no migration needs eight tasks and a complex enterprise rollout needs forty. Give both the same checklist and the first is annoyed while the second is under-served.
Something specific and checkable, agreed in writing before kickoff: which integrations are connected, how many users are active, what is running in production. Not "the customer is happy". Onboarding with no finish line fades rather than finishes.
Because close to kickoff is usually the largest interval and is owned by nobody. Sales think they have handed over, delivery think it has not started, and the only way anyone notices is if the clock starts at close.
Yes. The prompts here are written for Claude Code, Codex or Cursor and stage the build. The judgement calls are your task conditions and your definition of live, and the second one is worth arguing about before you build anything.
Customer Success
Build a health score from signals that actually predict renewal, show the trend rather than the number, and turn a red account into a named action. Prompts to build it, and what it takes to run it.
Customer Success
Work renewals from the notice date backwards, with a stage for each step, an owner, and a forecast leadership can trust. Prompts to build it, and what it takes to run it.
People
Generate the right task list per role, route each task to the team that owns it, and prove that access was actually removed. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.