A sales leader who decides the stage set and the thresholds; a Sales Manager per team for the data check and rehearsal. Sales Operations owns territory rules, rates and the old CRM export; Deal Desk owns prices, floors and the bookings check. Agree who configures extensions, verifies integrations and signs off each process.
Implementation
How a sales team moves onto B2B CRM: mapping the sales process and the rules, configuring, migrating from the old CRM, rehearsing a real week, and going live by team.
The authored specification is the starting point for configuring the application in the ERP.ai engine. Agree the team’s scope, configure the workflows and integrations, and rehearse the process before cutover. The schedule follows the data and acceptance work identified in that review.
Implementation phases
- Map the sales processSales Manager
- Configure and load master dataSales Manager
- Migrate the pipelineTeam and ERP.ai
- Rehearse a real weekDeal Desk
- Go live by teamTeam and ERP.ai
- TuneSales Manager
Phase 1 · Sales Manager
Map the sales process
The stage set with probabilities, forecast categories and exit criteria; the territory structure and its rules; discount authority per role and floor prices per product. Approval thresholds by reason and level, and the forecast basis, annual or total value, per quota type. Then the forecast day, the fiscal calendar, the period rates and the renewal lead time per contract length. This is a workshop with the sales leader, the managers, the deal desk and operations, and it becomes configuration.
| Role | Screens |
|---|---|
| Sales Development Rep | 4 |
| Account Executive | 9 |
| Sales Manager | 13 |
| Deal Desk | 3 |
| Customer Success Manager | 7 |
| Sales Operations | 4 |
| Executive | 3 |
Role permissionsRoles and permissions →
Phase 2 · Sales Manager
Configure and load master data
Roles and users with managers and territories, stages, sources, campaigns, competitors, products, price books, exchange rates and thresholds. Then accounts, sites, contacts and account teams from the old CRM, loaded in the migration order on the data model page and de-duplicated on the way in. Counts and the managers who know their books check the result.
| Role | Screens |
|---|---|
| Sales Development Rep | 4 |
| Account Executive | 9 |
| Sales Manager | 13 |
| Deal Desk | 3 |
| Customer Success Manager | 7 |
| Sales Operations | 4 |
| Executive | 3 |
Role permissionsRoles and permissions →
Phase 3 · Team and ERP.ai
Migrate the pipeline
Load open leads, opportunities with their contacts and products, quotes with evidence of their approval state, and current contracts with their source quote and notice deadline. Import stage and activity history where available. Import historical forecast lines only with their source submission headers, period and rate context; field-change logs alone are insufficient to recreate an approved weekly forecast.
Phase 4 · Deal Desk
Rehearse a real week
Leads arriving and routing, a qualified lead accepted, a quote submitted that breaches a threshold and is approved. A win marked and validated by the deal desk, a forecast submitted and reviewed, a renewal deal opened from a contract date. Each role runs their own steps on their own data.
Phase 5 · Team and ERP.ai
Go live by team
Start with a team whose data and workflow rehearsal passed. Enable mail, calendar and other integrations after their own checks pass. Freeze the migrated team's old records at its cutover while later teams continue in their assigned system; reconcile shared-account ownership and integration routing before the next cutover. Retire the old CRM after all teams and dependent integrations have moved.
Phase 6 · Sales Manager
Tune
Stage exit criteria adjusted from the first reviews, thresholds corrected from the first approvals, territory rules fixed from the first unmatched leads, reports tuned to what the managers actually ask.
| Field | Type | Required | Definition / allowed values |
|---|---|---|---|
| ThresholdName | text | Yes | — |
| Reason | select | Yes | DealSize, DiscountAboveAuthority, DiscountAboveEntryMaximum, BelowFloorPrice, NonStandardTerms, PaymentTerms, BillingFrequency |
| Level | number | Yes | 1 for the first approver, 2 for the approver above them |
| ApproverRole | select | Yes | SalesManager, DealDesk |
| Threshold | decimal | No | Quote total at or above which the step is required; empty for reasons that do not depend on amount |
| Currency | select | No | USD, EUR, GBP, INR, SGD, AUD |
| Active | boolean | Yes | — |
Stages, fields, approval reasons and thresholds, territory rules and whole modules are changed with Proto, on a branch, reviewed, released. The system is expected to change every time the sales process does.
1
Say what you need"Add a second approval above 10,000." Plain language.
2
Review the branchThe change lands on a branch with the diff and a test run.
3
ReleaseMerged into your workspace. Every user gets it.