Implementation and support

# Implementation and support

## Goal

Design the onboarding and early-support system that takes a closed beachhead customer to first valued use without founder heroics hiding inside “white-glove.” Define activation, time-to-value, required inputs, support boundaries, and what happens when adoption stalls.

This is operating design. Do not message customers or change production. Do not invent activation rates.

Complete the analysis autonomously. Do not stop to ask clarifying questions. When evidence is missing, design the narrowest path the current product can honor, or return `HOLD`.

Do not modify application code.

## Prerequisites

Read the latest ICP, pricing, deals, and product implementation; onboarding docs, empty states, checklists, support threads, implementation logs, and founder-time notes; and any existing `docs/gtm/onboarding.md`, `docs/gtm/onboarding.yaml`, and `docs/gtm/onboarding-changelog.md`.

The initial use case and value metric in the ICP are the destination. If the product cannot reach them without custom work, say so.

## Evidence standard

Use the shared GTM labels.

A kickoff meeting is not activation. A login is not value. A support ticket is not a product failure by itself, and the absence of tickets is not success.

Separate: provisioned, first key action, first valued output, repeat use, support burden, founder hours.

## Step 1: Define activation and time-to-value

Write operational definitions:

* provisioned: the customer can start the first workflow
* activated: the first key action that historically precedes value
* valued: the ICP value metric moved, with a baseline
* time-to-value: clock start and clock stop

If historical customers exist, compute what actually happened, including failures. If not, label targets `ASSUMED`.

## Step 2: Map the implementation path

From closed-won to valued use, list the steps the customer and the vendor must take: access, data, configuration, integrations, training, first job.

For each step:

* owner
* required input
* typical duration
* failure mode
* whether it is product, services, or founder labor
* what happens if it does not occur by a dated time

Identify the longest pole. If it is founder-only tribal knowledge, the path is not yet a system.

## Step 3: Support boundaries

Define what support will do in the first 14, 30, and 90 days:

* channels
* response expectations the team can keep
* issues that are product bugs versus implementation versus out-of-scope
* when a request becomes billable services
* when a customer is a bad-fit and should be unwound rather than endlessly accommodated

Do not promise 24/7 if the repository shows a founder inbox.

## Step 4: Stall and rescue

Write the stall signals: no first action, no data connected, only the champion logged in, value metric untouched.

Write the rescue play and the stop play. Endless concierge is a hidden discount.

## Step 5: Capacity

State how many concurrent onboardings the company can run without slipping time-to-value. Tie this back to campaign and pipeline volume. If sales can sell more than onboarding can activate, the constraint is onboarding. Say so.

## Step 6: Desk-test

1. Activation is observable.
2. The path uses the current product, not the roadmap.
3. Founder hours are visible.
4. Support promises match staffing.
5. Stalls have a stop condition.
6. RED-style custom work is not in the default path.

## Decision

* `INSTALL`: the path may be used for new beachhead customers
* `INSTALL NARROWLY`: founder-led concierge with a dated sunset
* `HOLD`
* `REVISIT PRODUCT` if the first valued use is not implementable
* `REVISIT OFFER` if the package implies a path the product cannot deliver

Lead with:

“As of [date], a new [beachhead] customer is considered activated when [definition], with expected time-to-value [range], capacity [N] concurrent, decision [INSTALL / INSTALL NARROWLY / HOLD / REVISIT PRODUCT / REVISIT OFFER].”

## Deliverables

### 1. `docs/gtm/onboarding.md`

Definitions, path, support boundaries, stall/rescue, capacity, desk tests.

### 2. `docs/gtm/onboarding.yaml`

`version`, `status`, `decision`, `activation`, `time_to_value`, `path`, `support`, `stall_signals`, `capacity`, `founder_labor`, `assumptions`, `unknowns`, `sources`.

### 3. `docs/gtm/onboarding-changelog.md`

Append only.

## Boundaries

* Do not contact customers or change production.
* Do not invent activation or CSAT numbers.
* Do not hide services inside “onboarding.”
* Do not design a path the current product cannot complete.
* Do not promise support the team cannot staff.
* Preserve uncertainty.

## Done when

* Activation, time-to-value, path, and capacity are explicit.
* Founder labor is labeled.
* Desk tests passed or forced `HOLD`.
* The three files agree.