Six Questions Before the Dashboard

Last week a fractional sales leader signed up for T2D3 OS on his own, no demo, no hand-holding. He is close to our ideal customer. He landed on Agency HQ — a screen that says "generate playbooks for your clients" — with zero clients and no obvious first step. He found the GTM Diagnostic eventually, through a widget. Then a report told him to accept eleven recommendations before he understood what accepting meant. Meanwhile his inbox filled with real-time notification emails while he was in the product.

None of this was a bug. Every screen did what it was built to do. The problem was upstream: the product did not know who he was, so it guessed — and it guessed from the wrong signal.

The wrong signal: your plan is not your role

Every self-serve beta account starts on the same plan. That plan happens to be an agency-tier SKU, because agencies are the customers who need the most room. Inside the app, "agency plan" meant "this person operates client accounts", so the first landing was the operator cockpit: add your first client, open Agency HQ.

A founder running her own company hit exactly the same screen. So did an in-house marketing lead. The SKU was routing people, and the SKU knows nothing about them.

This is a common shape of failure in B2B software: a billing attribute doubling as a product attribute. It is convenient right up until the day your pricing changes or your defaults do — and then everyone lands somewhere that makes no sense.

The fix: ask, then route on the answer

T2D3 OS now runs a short progressive wizard before the first dashboard. Six screens, one question each, every answer optional, every answer saved the moment it is given (so an abandoned wizard still banks what was answered). Each question exists because a specific part of the product consumes it. If we could not name the consumer, the question did not make the cut.

Then one confirmation: your growth stage, proposed from the ARR band, confirmed or corrected by you. The done screen does one more thing before handing over the product — it says, in three lines, what will happen next: we read your site and the diagnostic scores you; the AI drafts recommendations, each showing its evidence; you accept or dismiss, and only accepted ones become your plan. Nothing runs without you.

That last part is the thing our sales leader never got told. He was shown a report with an "accept 11" banner and no model of what accepting was. The model is now taught before the report exists.

Why "how should we reach you" is a sign-up question

Most products bury notification preferences three menus deep in settings, defaulted to "everything, immediately". The result is predictable: your most engaged new users — the ones actually in the product — are the ones getting hammered with emails about things they are looking at.

We moved the choice to sign-up and made it two honest options. Not a twelve-toggle matrix, not a digest cadence we cannot yet deliver. Two options that both work today. If you pick in-app only, the app remembers that you were asked — so it never re-defaults you to noise.

What we deliberately did not ask

Phone number is gone. We never called anyone. Company size in headcount is gone; the GTM team size is what the agents need. Job title as free text is gone; the role question is the honest version of it. Every removed field is a field nobody downstream was reading.

From September 1st: a card at sign-up, with nothing charged

Starting September 1st, the done screen offers one more step: add a card. Nothing is charged. The trial runs whether you add one or not, and the step is skippable in one click.

Why ask at all? Because AI work costs real money and the honest way to handle that is to let you buy more when you need more — top up credits the moment a big content run or a deep diagnostic needs them, without a second checkout flow interrupting the work. A card on file at sign-up is what makes "add credits" a one-click action later instead of a form.

The mechanics are worth a paragraph because they are the part most teams get wrong. The card is saved through Stripe's hosted setup flow, so no card number ever touches our servers. The Stripe customer is created and pinned to your account before you are sent to the form, so an abandoned form cannot leave an orphaned record. And the same webhook that already handled credit refills records the saved card — one seam, two doors. While proving this live we found that the existing refill path had been missing a required parameter and would have failed for the first real user; it is fixed in the shared helper, so both doors heal at once.

The agentic part

The wizard is a form. What makes it different from a form is that every answer is a decision the agents no longer have to guess at. The GTM Diagnostic is grounded in your site before you have opened it. The calculator has a prior. The agents know how much initiative they are allowed. The first week is ordered around what you said you came for.

Leader-leader, not leader-follower: the human gives the six facts only they know, and the system takes it from there. Then the human is reserved for the things only a human can do — confirm the stage, accept or dismiss the recommendations, lock the foundation.

What we are still deciding

Two open questions we have not shipped, on purpose. Should we pre-create the first client for operators from a seventh question, so a fractional CMO never sees an empty Agency HQ either? Almost certainly yes. And should the "in-app only" choice also pause the onboarding email sequence? Probably no — those emails teach, they do not nudge, and teaching was exactly what our sales leader was missing. We will publish what we decide.

If you want to see the six questions yourself, the trial is open until October 1st. Bring a website.