Skip to main content
Getting a brand live on StateSet is one flow, not six sign-ups. Onboarding provisions the brand across every engine it needs, idempotently — run it twice and it creates only what is missing.
Onboarding never invents your business rules. Policy and article lists start empty; the intake translator turns the plain-language policies you provide into KB articles, ResponseCX rules and NSR clauses — and leaves blank what you leave blank.

​
The portal — onboarding.stateset.com

onboarding.stateset.com is the self-service path. The sequence is built to be safe for a browser and for retries:
1

Fill in the intake

Brand identity, domains, support email, your shipping / returns / escalation / tone policies in plain language, and which services to activate. No service-specific syntax anywhere.
2

Preview

The intake is translated deterministically into the exact provisioning plan — the KB articles, rules and defaults it will create — with preflight results, before anything runs.
3

Approve and launch

Approval freezes the configuration (drafts are revision-checked, so a stale tab cannot overwrite a newer edit); launch is idempotent, so a retried click returns the original run rather than provisioning twice.
4

Watch it run, then verify

Progress streams live, one line per service. Verification then probes all six services and reports present / absent / partial for each — configuration drift shows up as partial, and a re-run heals only what is missing.
Roles follow least privilege: a viewer reads, an editor drafts and previews, an approver approves, launches, cancels and retries.

​
The operator CLI

For operators with service credentials, the same pipeline is a command. It lives in the ss-onboard-agent repository (not yet on npm) and reads the service keys from .env:
check separates launch-blocking errors (schema, credentials) from content warnings (an empty knowledge base, no support rules). Every step is idempotent, so the retry story is always --only the steps that failed. Add --json when a program is reading the output.

​
The provisioning API

The portal is a client of a provisioning API you can also drive directly — asynchronous jobs, so a web app can provision without holding service admin keys. The shape:
Jobs run queued → running → succeeded | failed | interrupted | cancelled; failed means at least one step failed — retry creates a new job for only the incomplete steps, with retryOf lineage. Every job stores an immutable configuration snapshot with a SHA-256 hash, and audit events are metadata-only: policy text, credentials and raw errors are deliberately excluded. Terminal webhooks are available for success, failure and cancellation.

​
For AI agents: the MCP server

The repository ships an MCP server so an agent can onboard a brand itself — the same six steps, tool by tool:
deprovision_brand deletes live configuration across six services. Give an agent this server with the same care you would give it the keys — and prefer dryRun first, always.

​
After onboarding

Onboarding is phase one of six — Launch a brand that runs itself is the whole path, from this page to a brand operating autonomously with every control explained.

Talk to your agent

The five-minute ResponseCX quickstart, against the org onboarding just created.

Put it on the phone

The Voice agent was created unpublished — review it, then publish.

See the decisions

The NSR rules seeded at onboarding are what gate refunds; here is how a verdict works.

Wire up your store

Connect Shopify, NetSuite and your 3PL through the Sync Server.
Last modified on August 31, 2026