Customer Onboarding Agent (Closed-Won → Live)

1📋

Overview & business value

When a deal closes, this agent takes the customer from signature to live. It reads the won opportunity, runs the onboarding playbook for the product tier — provisioning the tenant, creating identities, setting up billing and opening the kickoff — and for free-text custom requirements (data residency, SSO) it interprets them and confirms the plan with the account team before provisioning. It reads and reasons freely; every provisioning, identity and billing action is an Action Ticket carrying a MOP.

Problem

Sales closes the deal, then onboarding becomes a manual relay: provisioning waits on IT, billing on finance, identity on security. New customers wait weeks to go live, and custom requirements in the deal notes get lost between sales and delivery.

Solution approach

Event-driven on closed-won. For a standard tier the agent runs the playbook end to end. When the deal notes carry custom requirements, it interprets them, maps them to the right configuration and systems, and confirms with the account team before acting.

Core capabilities

Closed-won detection + deal read
Tier-to-playbook resolution
Tenant / environment provisioning (Terraform)
Free-text requirement interpretation
Data-residency region mapping
Admin identity + SSO setup
Billing activation (Stripe)
Kickoff + onboarding tasks

How it helps

New customers go live in hours, not weeks. Sales is unblocked, environments are configured consistently, and there are no dropped hand-offs between sales and delivery. Custom requirements are honoured, with a human confirming the plan.

Illustrative value model — plug in your own figures

New customers / year

↓ TTL

Days saved to go-live

Revenue recognised earlier

Value = W × onboarding hours saved × rate, plus revenue pulled forward by faster go-live. Placeholders — substitute your baseline.

2📖

The story (for the sales conversation)

The one-liner

"The deal is signed. Now the customer waits weeks while provisioning, identity and billing get set up by hand across teams. This agent turns the signature into a live environment the same day — and reads the fine print in the deal notes."

😣 Today, without the agent

Northwind closes on Friday. The CS manager files a provisioning ticket, emails finance to set up billing, and asks security to create the admin login. The deal notes say "needs EU data residency and SSO via their Okta" — but that detail sits in Salesforce and nobody reads it until the environment is already built in the wrong region. Go-live slips two weeks and the customer's first impression is a delay.

😌 The same day, with the agent

The opportunity flips to closed-won. The agent reads the deal, resolves the Growth-tier playbook, and notices the deal note. It interprets "EU data residency" as the eu-west region and "SSO via their Okta" as a federation setup, and asks the account team to confirm before provisioning. On approval it runs Terraform in eu-west, creates the admin identity, activates the Stripe subscription, and opens the kickoff.

"For a standard tier it just runs. For anything custom — data residency, SSO, a non-standard environment — it interprets the requirement, shows you the plan, and waits for a yes. Provisioning and billing are reversible, audited actions."

The trust point — lead with this for CS, RevOps and Security

The villain: the hand-off gap

Sign-to-live is a manual relay across IT, finance and security.

The hero: playbook + interpretation

The agent runs the tier playbook and reads custom requirements from the deal.

The reason to trust it

Custom config and billing are confirmed by a human; every action is a reversible ticket.

💡How to use this tab: open here for CS / RevOps, tell the before/after, land the trust line, then show "Sample questions" and "Live scenarios". Keep Tools/Governance for the technical buyer.

3📥

Input data

Source system	Field / entity	Type	Purpose
Salesforce	Opportunity (stage, amount, product tier)	sObject	Trigger + tier playbook
Salesforce	Account (region), deal notes	text	Custom requirements to interpret
Terraform	tenant module + variables	script	Environment provisioning
Entra / Okta	admin user, SSO app	object	Identity + federation
Stripe	customer, subscription, invoice	object	Billing activation
ServiceNow	onboarding request / tasks	record	Kickoff + delivery tasks

ℹ️Developer note: trigger is an Opportunity reaching Closed Won (Salesforce event or scheduled salesforce.query). The payload carries the opportunity id.

4⚙️

Processing flow (tools mapped per step)

ℹ️Each step shows its path and whether it is read-only or a write via Action Ticket.

Detect closed-won deterministic

Read the won opportunity, account region and product tier.

salesforce.query · Opportunity WHERE StageName='Closed Won'

Resolve tier playbook deterministic

Map the product tier to its provisioning, identity and billing spec.

tier → playbook spec

Interpret custom requirements non-deterministic human approval

Parse deal notes (e.g. EU residency, SSO); map to config; confirm plan with the account team.

reasoning over deal notes → plan → approval

Provision tenant deterministic Action Ticket

Run the Terraform module with the resolved region and tier variables.

provision.terraform init+apply (via ticket)

Create admin identity + SSO deterministic Action Ticket

Create the customer admin in Entra/Okta and set up the SSO app.

entra.graph / okta provisioning (via ticket)

Activate billing deterministic approval Action Ticket

Create the Stripe customer + subscription on the tier plan.

billing.stripe create_subscription (via ticket)

Kickoff + tasks deterministic Action Ticket

Open the ServiceNow onboarding request and notify the account team.

servicenow.request · teams.post (via ticket)

Go-live verification non-deterministic

Confirm tenant up, identity working, billing active; report readiness.

parallel reads → readiness summary

5🔧

Skills & tools (real connectors)

ℹ️Each tool maps to a real processorKey. Read tools are direct; writes only run inside an Action Ticket.

salesforce.queryREST / BulkSOURCE

salesforce.QuerySalesforceObject / crm.processors.SalesforceBulkAPI

Reads the won Opportunity, Account region and deal notes via SOQL / Bulk. Connected App OAuth 2.0.

SELECT … FROM Opportunity WHERE StageName='Closed Won'

READ · direct

provision.terraformTerraformEXEC

custom.processor.ExecuteTerraform

Executes a Terraform script (init + apply); downloads Terraform if needed; cleans up after. Used to provision the tenant/environment.

terraform init && apply (tenant module)

WRITE · via Action Ticket

entra.graphMS GraphSOURCE

identity.processors.EntraIDGraph

Creates and manages users/apps via Microsoft Graph. Used for the customer admin identity and SSO app.

create_user · register_app (via Graph)

READ direct · WRITE via ticket

okta.usersGroupsOkta APISOURCE

identity.processors.OktaUsersAndGroups

Provisions Okta users/groups and app assignments for SSO. OAuth2 or SSWS token.

users · groups · app assignment

READ direct · WRITE via ticket

billing.stripeStripe APISOURCE

payments.processors.StripeSubscriptions / StripeAPI

Full subscription lifecycle (create, upgrade, pause, cancel) + customer creation; proration and trials. OPERATION selects the call.

create_customer · create_subscription

WRITE · via Action Ticket

servicenow.requestTable APISOURCE

itsm.processors.ServiceNowIncident

Opens the onboarding request and delivery tasks via the Table API.

/api/now/v2/table/{request}

WRITE · via Action Ticket

teams.postGraphSINK

collaboration.processors.TeamsSendMessage

Confirms the plan with the account team and posts the go-live summary.

TeamsSendMessage · channel/chat

WRITE · via Action Ticket

⚠️Connectivity honesty: tenant provisioning uses ExecuteTerraform (init+apply); cloud-native alternatives in the library are AWSStepFunctionsStart / AzureLogicAppsTrigger. SSO "via the customer's Okta" sets up our app and requests their IdP metadata — the customer's side is theirs to complete. Billing uses the real Stripe subscription connector.

6🤖

Agent prompt (production)

🤖 System prompt

You are the Customer Onboarding Orchestrator (Closed-Won to Live).

## Operating rules
1. Read/reason freely across Salesforce and the provisioning/identity/billing systems.
2. You NEVER write directly. Every provisioning, identity or billing action is an
   Action Ticket carrying a MOP; ProcBot executes, Sherlock validates, reversible.
3. Deterministic for: the standard tier playbook, provisioning by template,
   identity by spec, billing on the tier plan.
4. Non-deterministic for: interpreting free-text deal-note requirements
   (data residency, SSO, non-standard env) and mapping them to config.
5. Human approval before: any custom configuration (residency, SSO federation,
   non-standard environment) and before activating billing.
6. Cite the source record for every requirement. Never invent contract terms.

## Tools
READ (direct): salesforce.query, entra.graph (read), okta.usersGroups (read)
WRITE (Action Ticket only): provision.terraform, entra.graph (create/app),
  okta.usersGroups (provision), billing.stripe, servicenow.request, teams.post

## Output (every step)
{ "decision":"...", "path":"deterministic | non-deterministic", "confidence":0.0,
  "action_ticket": { "mop":"...", "scope":"...", "approval":"auto | human" } | null,
  "evidence":[ { "tool":"...", "record":"..." } ], "message_to_user":"..." }

7🛡️

Execution governance — Action Ticket → MOP

No tenant, identity or billing change reaches a system from the model. The agent reasons; an Action Ticket carries the MOP; ProcBot executes; Sherlock validates; the ticket is reversible. Custom configuration and billing activation require human approval first.

1 · Reason

Agent decides to provision / create identity / bill.

→

2 · Action Ticket

MOP id, scope, parameters, approval level.

→

3 · ProcBot executes

Runs Terraform / identity / Stripe. Model never writes.

→

4 · Sherlock validates

Confirms tenant up, identity active, subscription live; rolls back on failure.

{
  "action_ticket": "AT-7001",
  "mop": "MOP-PROVISION-TENANT",
  "approval": "human",   // custom: EU data residency
  "target": { "tool": "provision.terraform", "processorKey": "custom.processor.ExecuteTerraform" },
  "procedure": { "module": "tenant-growth", "vars": { "region": "eu-west-1", "tier": "growth",
                 "data_residency": "EU", "sso": "okta-federation" } },
  "validation": { "owner": "sherlock", "expect": "apply == success && region == eu-west-1" },
  "reversible": true
}

8🔀

Data flow

flowchart TD A([Opportunity Closed Won]) --> B[Read deal + tier + notes salesforce.query] B --> C[Resolve tier playbook] C --> D{Custom requirements?} D -->|Yes| E[Interpret notes EU residency / SSO] E --> F[Human approval of plan] D -->|No| G{{MOP-PROVISION-TENANT}} F --> G G --> H[ExecuteTerraform region + tier vars] H --> I{{MOP-IDENTITY-SETUP}} I --> J[Entra/Okta admin + SSO] J --> K{{MOP-BILLING-ACTIVATE}} K --> L[Stripe customer + subscription approval] L --> M[Kickoff + tasks go-live verification]

9🏗️

Systems touched

☁️ Salesforce — won opportunity + deal notes

🛠️ Terraform — tenant / environment provisioning

🔑 Entra ID — admin identity + SSO app

🔐 Okta — provisioning + federation

💳 Stripe — billing activation

🛠️ ServiceNow + Teams — kickoff, tasks, confirmation

10🗄️

Mock data (seed to demo)

Opportunity

Tier playbook

Terraform apply

Stripe subscription

Identity + SSO

// salesforce.query Opportunity O-55021
{ "opportunity":"O-55021", "account":"Northwind Traders", "stage":"Closed Won",
  "tier":"Growth", "acv":96000, "region":"EU",
  "dealNotes":"Needs EU data residency and SSO via their Okta." }

// Growth tier playbook
{ "tenant":"tenant-growth", "seats":50, "plan":"price_growth_monthly",
  "defaultRegion":"us-east-1", "sso":"optional" }

// provision.terraform apply (region overridden to EU)
{ "module":"tenant-growth", "region":"eu-west-1",
  "apply":"success", "tenantUrl":"https://northwind.eu.app.example.com" }

// billing.stripe create_customer + create_subscription
{ "customer":"cus_NwND01", "subscription":"sub_GROWTH88",
  "plan":"price_growth_monthly", "status":"active" }

// entra.graph create admin + SSO app
{ "adminUpn":"admin@northwind.example.com", "ssoApp":"registered",
  "federation":"awaiting customer Okta metadata" }

11💬

Sample questions (conversational triggers)

The natural-language prompts this agent is built to answer. Each maps to the live scenarios below.

🚀"Onboard Northwind Traders (O-55021)."→ Scenarios 1–8

📋"What does Northwind's setup require?"→ Scenarios 2–3 (playbook + notes)

🌍"They need EU data residency — handle it."→ Scenarios 3–4 (region mapping)

💳"Set up billing for the Growth tier."→ Scenario 6 (Stripe)

🔐"Configure SSO via their Okta."→ Scenario 5 (identity + federation)

✅"Is Northwind ready to go live?"→ Scenario 8 (go-live verification)

🎯 Recommended demo run

Seed the won opportunity, then ask "Onboard Northwind Traders (O-55021)" — the agent reads the deal (1), resolves the playbook (2), interprets the EU/SSO notes and asks approval (3), provisions in eu-west (4), sets up identity + SSO (5), activates billing (6), opens kickoff (7) and verifies go-live (8). Scenarios 9–10 cover an ambiguous requirement and a standard-tier fast path.

12🎬

Live scenarios (tool-execution traces)

ℹ️Ten end-to-end runs. Each step is a read (SOURCE), reasoning, an Action Ticket with a MOP, or an agent message.