---
name: "create-sales-experience"
description: Create and schedule a CloudShare sales experience (POC, POV, demo, or trial) from one or more blueprints, tied to a CRM opportunity, with a main sales pro, then hand the user a ready-to-share package (summary, access details, prospect invitation, sales pro checklist). Uses the CloudShare MCP tools (list_* lookups, list_sales_pro, get_sales_experience_default_values, create_sales_experience). Use whenever the user asks to create, set up, schedule, or prepare a CloudShare sales experience, POC, POV, demo, customer trial, or prospect environment, even if they only name a blueprint, opportunity, customer, or date. For training classes with students and instructors, use create-training-experience. For plain environments, use create-env-from-bp or create-env-from-scratch.
---

# CloudShare Sales Experience Creator

Create a CloudShare sales experience (POC / POV / demo / trial) and return a package the user can use or forward as-is.

Be efficient: extract everything the user already stated, resolve the rest with tools, ask only for what is genuinely missing, and do all confirmation in a single step.

**How this differs from a training experience** (don't mix them up):
- Participants are **prospects/customers**, and the staff are **sales pros** (not instructors).
- Every sales experience is tied to a CRM **opportunity** identifier (required).
- Access is **always passphrase-based** (no SSO), and there are **no student caps, concurrency caps, or early-access settings**.
- Type is `poc` | `pov` | `demo` | `trial` (not instructor-led / self-paced).
- There is **no tool to add participants or sales pros after creation, and no tool to update a sales experience** (`update_experience`, `add_instructor`, `add_student_to_training_experience`, and `send_invitations` are training-only — never use them here). Everything must be right at creation time, so collect additional sales pros before creating.

## Workflow

### 1. Capture intent (don't re-ask what's already stated)

Pull from the user's message: name, sales type, start (and end), time zone, opportunity, project, blueprint(s), main sales pro, additional sales pros, passphrase, registration type, customer/prospect name. Anything missing gets a default (below) or is resolved in later steps.

Only these are required from the user (ask once, batched, if missing):
- **Name**
- **Start date/time**. Never assume a date.
- **Opportunity** — the CRM opportunity identifier (required by the tool, no default exists). Never invent one.

**Mode question (second question, after name, start and opportunity):** once those are known, ask the user whether they want to add a mode to the experience — unless they already mentioned one (e.g. "multi-step", "with a shared environment"), in which case skip the question and use it. Ask it as a single short question with these options:
1. **Shared Blueprint Experience** — adds a shared environment to the experience
2. **Multi-Step Experience** — several blueprints run as ordered steps
3. **Classic Standard Experience** — the default; one blueprint, no extras

If the user doesn't pick or says "default"/"no", use Classic Standard. Never ask the mode question in the same batch as name/start/opportunity, and never ask it twice. Modes can be combined only if the user says so.

Everything else has a default, so don't ask — show what was assumed in the confirmation step so the user can correct it:
- **Type** → whatever the user said ("POC"/"proof of concept" → `poc`, "POV"/"proof of value" → `pov`, "demo"/"product demonstration" → `demo`, "trial"/"free trial" → `trial`); **`poc` when the user didn't say**. Always pass the resolved type explicitly as `type` to `get_sales_experience_default_values` so the tool's own default never overrides it. Never ask "POC or demo?" up front.
- **End date/time** → optional. Pass `end` only if the user gave one; otherwise omit it and never ask for it. If `create_sales_experience` rejects the call for a missing end, ask the user once and retry.
- **Time zone** → the user's actual time zone (see below), shown by name. A zone the user states explicitly always wins.
- **Mode** → `Classic Standard` when the user didn't pick one.
- **Blueprint** → the most-used blueprint in the project (step 2). Several blueprints only in Multi-Step mode (or if the user names several). This is only how the choice is made — when presenting it, show the blueprint's actual name and specs, never the "most-used" label.
- **Passphrase, policy, region, main sales pro, team, registration type** → from defaults (step 3). A passphrase the user states always wins.
- **Additional sales pros** → none unless the user names them.

**Default time zone:** use the user's approximate location that Claude already has in context (IP-derived) and map it to the matching Windows-style zone ID the tools expect (e.g. `Israel Standard Time`, `Eastern Standard Time`, `W. Europe Standard Time`). Don't call an external IP-lookup service — the sandbox network can't reach one. If no location is available, use the `timeZone` returned by `get_sales_experience_default_values`; only ask the user if that is also empty. **How to display the zone** (confirmation, summary, invitation): always the actual zone in Windows display-name form — `(UTC±HH:MM) City`, e.g. `(UTC+02:00) Jerusalem`, `(UTC-05:00) Eastern Time (US & Canada)`. Never write "yours", "your time zone", or "from your location". The offset in the label is the zone's standard offset; if DST is in effect on the start date, you may add the actual offset after it in plain words (e.g. "currently UTC+03:00").

### 2. Resolve project, region, blueprints

Use `purpose: CreateSalesExperience` on lookups. `list_policies` and `list_owners` accept it explicitly; if `list_projects`, `list_regions`, or `list_blueprints` reject that value, retry with `purpose: CreateExperience`. Never use `EnvCreationFromBp`.

- `list_projects` (filter by `name` if given). If the user named none and several come back, prefer the one with `isMostUsed` (then `isRecentlyUsed`) and show it in the confirmation; ask only if none stands out.
- `list_regions` with the `projectId`. Prefer `isDefault`. `list_blueprints` requires a `regionId`.
- `list_blueprints` with `projectId`, `regionId`, filtered by `name` when the user gave one. If a name matches several, ask. Never use a blueprint ID that did not come from this tool.
- **No blueprint named:** call it without `name` and pick the one with `isMostUsed: true` (fall back to `isRecentlyUsed`; if neither is set, show the user the blueprint list — name, VMs, CPU, RAM, and a marker for public-cloud ones — and ask them to pick). In the confirmation, present it by its actual name and specs (e.g. `Win 11 RED (1 VM, 2 CPU, 8 GB RAM)`), not as "the most-used blueprint".

### 2b. Apply the chosen mode

- **Classic Standard:** one blueprint, nothing extra.
- **Multi-Step:** needs two or more blueprints in order. If the user hasn't named them, show the blueprint list and ask which ones and in what order. Also ask whether participants may switch steps themselves → `allow_participants_switch_steps`.
- **Shared Blueprint:** needs a shared environment on top of the regular blueprint. Use `list_shared_env_blueprints` (IDs start with `SE`) to find the shared blueprint; if the user named none, show the list and ask. Set `shared_env_blueprint_id`, take `shared_env_policy_id` from `list_policies` (prefer `isMostUsed`/`isRecentlyUsed`, otherwise reuse the experience policy), and ask once whether to enable shared lab view access → `is_shared_lab_view_access_enabled`.

### 3. Get creation defaults

Call `get_sales_experience_default_values` with `projectId`, `experienceName`, `start`, plus any overrides the user stated (`type`, `blueprintIds`, `regionIds`, `mainSalesProEmail`, `policyId`, `timeZoneId`, `passphrase`, `registrationType`).

**Time zone trap:** this tool wants `start` in **UTC, no offset** (e.g. `2026-09-01T09:00:00`). `create_sales_experience` wants `start`/`end` in the **experience's own time zone**. Convert the user's local time (in the zone resolved in step 1) to UTC for this call (mind DST; use `bash_tool` with Python `zoneinfo` if unsure), pass that zone as `timeZoneId`, then use the user's local time with the returned `timeZone` when creating. "EST" said in summer means US Eastern time (currently EDT) — convert with DST applied.

Use the returned values directly: blueprints, regions, policy, mainSalesPro, timeZone, experienceName, passphrase, registrationType, and any cloud region/zone fields (`awsCloudRegion`, `azureCloudRegion`, `googleCloudProviderRegion`, `googleCloudProviderZone`).

**If the call fails**, fall back to individual lookups in parallel (`purpose: CreateSalesExperience`):
- `list_policies` — prefer `isMostUsed` / `isRecentlyUsed`
- `list_teams` — if empty, omit `team_id`
- `list_sales_pro` (needs `projectId`; optional `teamId`) — pick the main sales pro; also use `list_owners` (needs `teamId`; prefer `isMe` / `isRecentlyAssigned`) if `list_sales_pro` yields nothing
- `list_regions` — prefer `isDefault`
- passphrase: if none was returned and the user gave none, ask once (1–60 characters)

If an invalid blueprint ID is the cause, the whole call fails; fix the blueprint via step 2 rather than retrying blindly. An inaccessible region ID is silently dropped, so verify the returned regions match what was requested.

**Additional sales pros:** if the user named any, verify each with `list_sales_pro` (use `name` to search, 3+ characters). Each email must already exist as a candidate in the project or creation fails. Report any that don't match and ask once.

### 4. Validate before showing the plan

Catch these now — `create_sales_experience` is all-or-nothing and creates nothing if any rule fails:

| Rule | Check |
|---|---|
| Name | 5–100 characters |
| Type | one of `poc`, `pov`, `demo`, `trial` |
| Opportunity | 1–100 characters, supplied by the user |
| Passphrase | 1–60 characters (always required; passphrase-only access, no SSO) |
| `end` | optional — omit unless the user gave one; if given, must be after `start` |
| Public cloud blueprints | AWS / Azure / GCP region (GCP also zone) required — take from defaults; ask the user if null |
| Multi-Step mode (several blueprints) | at least two blueprints; ask whether participants may switch steps → `allow_participants_switch_steps` |
| Shared Blueprint mode | `shared_env_blueprint_id` (`SE…`) and `shared_env_policy_id` (`PO…`) required; `is_shared_lab_view_access_enabled` only applies here |
| Description | max 500 characters; `external_id` 3–50 characters |
| Regions | 1–3 region IDs |
| Main sales pro email | max 100 characters; must be a valid candidate in the project |
| Additional sales pros | each email must already exist as a candidate in the project |
| `registeredParticipantsOnly` | participants cannot be registered through MCP tools — warn the user they must register them in the CloudShare UI, or use `anyParticipants` |

Map defaults to create fields: `regions` → `cloudshare_region_ids`; `blueprints` → `blueprint_ids`; `mainSalesPro` → `main_sales_pro_email`; `timeZone` → `time_zone`; `policy` → `policy_id`. `type` comes from the user, or `poc` if they didn't say.

Don't set optional extras (`allow_audio_video`, `allow_multiple_environment_activations`, `block_free_email_domains`, `email_domain_blocklist`, `preconfigure_participant_environments`, `labels`, `custom_fields`, `description`, `external_id`, `use_custom_invitation_email`) unless the user asked for them. If the user asks to block free email domains (Gmail, Hotmail) for a prospect-only trial, use `block_free_email_domains`.

### 5. Confirm once

Show all resolved values (names, not IDs) and wait for approval:
- Name, **type** (POC / POV / Demo / Trial; note if defaulted to POC), **opportunity**, mode (Classic Standard / Multi-Step / Shared Blueprint; note if defaulted), start (and end if given) with the time zone in `(UTC±HH:MM) City` form — no "yours"/"your location" wording
- Project, blueprint(s) (as ordered steps if multi-step; actual blueprint name and specs — never "most-used" wording), region(s), policy, team
- Main sales pro + additional sales pros
- Access: passphrase (shown in full), registration type
- **Invitations: `send_invitations` defaults to `salesProsAndParticipants` — real emails go out to everyone who can be reached.** State this explicitly and offer `dontSend` / `salesProsOnly` / `participantsOnly`. Remind the user that participants can't be added after creation through these tools.
- Any extras the user asked for

### 6. Create

Call `create_sales_experience` with the confirmed values. It returns the experience ID and the defaults it applied. If it returns validation errors, show all of them, fix with the user, and retry — nothing was created.

There is no follow-up add/update step. If the user later wants changes (more sales pros, different blueprint, new dates, registered participants), tell them plainly that these tools can't edit a sales experience and that it must be changed in the CloudShare UI — or offer to create a corrected one if the original is no longer needed (never delete or recreate without an explicit yes).

### 7. Deliver the package

Return one compact package, not a wall of text:

0. **Experience link** (first line of the package). Only if `create_sales_experience` returned a URL, or the user has given you the sales experience URL pattern in this conversation. Present it as a named link introduced by a short lead-in: `Here is a link to your experience - [Open - <experience name>](<url>)`. **Do not guess the URL** — the training pattern (`…/training/<ID>/users`) is not known to apply to sales experiences. If no URL is available, show the experience ID in the first line instead (`Your sales experience was created - ID: <ID>`) and say the link wasn't returned.
1. **Summary**: experience ID, name, type, opportunity, schedule + time zone, step(s)/blueprint(s), region, policy.
2. **Access details**: passphrase shown in full, registration type, invitation setting.
3. **People**: main sales pro, additional sales pros, and who was or wasn't invited (per the `send_invitations` setting).
4. **Prospect invitation** — a short, ready-to-paste message for the customer/prospect with the experience name, date/time with time zone, how to join (passphrase), and what to expect (e.g. a hands-on look at the environment, with the sales pro available). Do not invent a join URL; include one only if a tool returned it, otherwise leave a clearly marked `[join link]` placeholder. Keep it customer-facing: no internal opportunity ID, no internal notes.
5. **Sales pro checklist** — 3–5 items tailored to this setup (e.g. confirm the blueprint boots and the demo flow works before the prospect joins, share the passphrase through a separate channel from the link, confirm the opportunity ID matches the CRM record, if multi-step walk through the step order, if `registeredParticipantsOnly` register participants in the UI).

End the package with one line offering to adjust the invitation tone/language. Then stop; there is no add-people phase for sales experiences.

## Quick reference — tool call order

| Step | Tool(s) | Notes |
|---|---|---|
| 2 | `list_projects`, `list_regions`, `list_blueprints` | `purpose: CreateSalesExperience` (fall back to `CreateExperience` if rejected); blueprints need `regionId` |
| 2b | `list_shared_env_blueprints` (Shared Blueprint mode only) | Mode chosen after name + start + opportunity |
| 3 | `get_sales_experience_default_values` | `start` in **UTC** here |
| 3 (fallback) | `list_policies`, `list_teams`, `list_sales_pro`, `list_owners`, `list_regions` | Parallel; omit `team_id` if none |
| 3 | `list_sales_pro` | Validate additional sales pro emails |
| 5 | — | Single confirmation, call out invitation emails |
| 6 | `create_sales_experience` | `start`/`end` in the experience's time zone; no add/update tools exist afterwards |
| 7 | — | Link (only if real), then summary, access, people, prospect invitation, sales pro checklist |

## Common mistakes

- Using training tools (`create_training_experience`, `add_instructor`, `add_student_to_training_experience`, `update_experience`, `send_invitations`) for a sales experience.
- Asking for instructors, students, SSO, max students, early access, or instructor-led/self-paced — none of these exist for sales experiences.
- Omitting the opportunity (required) or inventing one.
- Asking the user for the type up front instead of reading it from their message, or defaulting to anything other than `poc` when they didn't say.
- Asking for a time zone, passphrase, or blueprint instead of defaulting (user's location zone; returned passphrase; project's most-used blueprint).
- Skipping the mode question when the user didn't mention a mode, asking it in the same batch as name/start/opportunity, or asking it when the user already stated one.
- Sending a local `start` to `get_sales_experience_default_values` (needs UTC) or a UTC `start` to `create_sales_experience` (needs the experience time zone).
- Creating before confirming, and especially forgetting that invitation emails are sent by default.
- Collecting additional sales pros after creation — they can only be set at creation, and each must already be a candidate in the project.
- Promising to add participants or edit the experience later via these tools.
- Choosing `registeredParticipantsOnly` without warning that participants can't be registered through MCP tools.
- Fabricating a join URL, or guessing the experience link pattern instead of using a returned URL or showing the ID.
- Leaking the internal opportunity ID or sales notes into the prospect invitation.
- Labelling the time zone "yours" instead of naming it (`(UTC+02:00) Jerusalem`), or labelling the blueprint "most-used" instead of naming it.
- Forgetting the AWS/Azure/GCP region for public-cloud blueprints.
- Using a blueprint, region, policy, or sales pro that didn't come from a tool result.