Velaro Deployments Guide
Velaro Deployments Guide
What is a deployment?
A deployment is a named chat widget placement — a JavaScript snippet you paste into a specific page or section of your website. Each deployment has a unique key (deploymentId) baked into its snippet. Wherever you paste that snippet, the Velaro widget appears and routes conversations to the team you assigned.
Your website Velaro
────────────────── ─────────────────────────────────────
/pricing [snippet A] ──→ "Sales" deployment ──→ Sales team
/support [snippet B] ──→ "Support" deployment ──→ Support team
/contact [snippet C] ──→ "General" deployment ──→ Support team
Deployments B and C above both route to the same team — that is completely fine and very common.
---
Why not just use the team ID in the snippet?
The deploymentId key is permanent — it lives in your website's HTML and never needs to change. If the snippet used a team ID directly:
- Reorganising your teams would change their IDs → every embed on every page breaks
- Reassigning a widget to a different team would require editing the HTML on every page it is on
With a deployment, you reassign the team in the Velaro admin in seconds. The snippet on every page stays exactly the same. This matters most when:
- You merge two support teams
- You hire a specialist team and want to reroute a product area to them
- You rename or restructure your support tiers
- You repoint 40 pages of an enterprise site to a new CSM team without touching a single line of HTML
---
How team assignment works — it is simpler than it looks
The deployment is the trigger. Whichever snippet you paste on a page, that is the team those conversations go to. No rules needed.
- Paste the Sales snippet on
/pricing→ conversations go to Sales - Paste the Support snippet on
/help→ conversations go to Support - Paste the same snippet on every page → everything goes to one team
Rules are an optional layer for conditional logic within a single deployment — for example, routing based on a pre-chat survey answer when you cannot or do not want to use separate snippets per page. But routing rules are not required and most setups do not need them alongside multiple deployments.
---
The real power: knowing where a conversation started
When an agent receives a conversation, Velaro shows them which deployment it came from. This tells them, without asking:
- The visitor was on the pricing page → buying intent
- The visitor was on the documentation page → stuck on setup
- The visitor was on the billing page → payment issue
You can also write routing rules, bot prompts, and workflows that behave differently based on the source deployment. One team, completely different handling per entry point.
---
Real examples
Example 1 — Same team, two entry points, different intake forms (most useful)
A SaaS company has one Support team but wants different pre-chat questions depending on where the visitor comes from:
| Page | Deployment | Pre-chat survey | Team |
|---|---|---|---|
/help |
Help Center | "What product are you using?" | Support |
/billing |
Billing Help | "What is your order number?" | Support |
One team. Two experiences. Zero routing complexity.
---
Example 2 — Different teams per department
An e-commerce retailer with separate specialist teams:
| Page | Deployment | Team |
|---|---|---|
/shoes |
Footwear Chat | Footwear team |
/bags |
Accessories Chat | Accessories team |
/returns |
Returns Chat | Returns team |
Each department owns their page. Agents only see conversations from their area.
---
Example 3 — One widget on every page (most common setup)
A small business pastes the same snippet everywhere:
| Pages | Deployment | Team |
|---|---|---|
| All pages | Main Chat | Support |
This is the most common setup. One deployment, one team, done. Most customers never need more than this.
---
Example 4 — Repointing without touching the website
A company promotes their top agents to a dedicated "Premium Support" team and wants to reroute their enterprise customers immediately. The "Enterprise Chat" widget is already embedded on 40 pages of their documentation site.
They open the Velaro admin, change the deployment's team from "Support" to "Premium Support", and save. Done in 30 seconds. No changes on any of the 40 pages.
---
Is this a power feature?
Yes. Most customers start with one deployment and never need more. Multiple deployments are worth considering when:
- You have more than one team
- You want different pre-chat surveys per page
- You want agents to see which page the visitor came from
- You need to reassign widgets to different teams without editing your website
If none of those apply, one deployment on all pages is the right choice.
---
Setting it up
1. Go to Deployments in the left sidebar.
2. Click New Deployment.
3. Name it after the page or use case (e.g. "Pricing Page Chat").
4. Assign it to a team.
5. Optionally choose a pre-chat survey, post-chat survey, or unavailable survey.
6. Copy the embed snippet.
7. Paste it into your page's HTML just before </body>.
The widget appears on that page immediately.
---
FAQ
Can two deployments point to the same team?
Yes. Very common. Each deployment still carries its own name and context even when routing to the same team.
Can I rename a deployment without breaking the widget?
Yes. The display name is separate from the deploymentId key in the snippet. Renaming never affects the live widget.
Can I change which team a deployment routes to?
Yes, any time, instantly. No changes to your website needed.
Does the widget look different per deployment?
Widget appearance (colors, greeting, position) is currently configured site-wide, not per deployment. If you need this, contact support@velaro.com.
What happens if I delete a deployment?
The widget stops loading on pages using that snippet. Existing conversations are unaffected.
Was this article helpful?