Résultat
custom fields configured across three core objects
Résultat
automation flows built to manage the full account lifecycle
Résultat
distinct sales pipelines
● Context
When the Sales Motion Gets More Complex Than the Tool
Maki (short for MakiPeople) is a Paris-based AI-powered talent acquisition platform founded in 2021. Their product uses conversational AI to automate up to 80% of the recruitment process on behalf of clients. After raising a €26M Series A in January 2025 and expanding into the US, their revenue team had grown into a genuinely complex sales operation: multiple deal pipelines, enterprise accounts, a sophisticated post-sales motion managed in Planhat, and a sales methodology built around MEDDPICC.
HubSpot had served them well in the early stages but Maki's sales motion had evolved beyond what the setup could support at that stage.The Salesforce migration had already started internally, the sales team was operating in Salesforce and Marc Desazars, Head of Revenue Operations at Maki, was steering it. The challenge: standing up a Salesforce org from scratch that could support how their sales team actually worked, mirror the field-level data Planhat was already consuming from HubSpot, and do it without disrupting live deals.
That's when Maki brought in Cashmyrr.
Common scenario: At a certain stage of complexity like multi-pipeline, MEDDPICC methodology, bidirectional CS integration, the question isn't which CRM is better, but which one fits how your team actually works.
What a Clean HubSpot to Salesforce Migration Looks Like
A successful CRM migration at this stage isn't just about moving records. It requires rebuilding the revenue architecture around the team's real process. For Maki, the objectives were:
- Stand up a production-ready Salesforce org with the full field structure their sales team required, no temporary workarounds, built to last.
- Migrate all historical deal data from HubSpot to Salesforce, including legacy pipelines, without breaking downstream integrations with Planhat.
- Implement MEDDPICC natively in Salesforce, with validation rules enforcing data quality at each stage progression.
- Rebuild the Planhat integration on Salesforce, replacing the existing HubSpot–Planhat sync with a logic-driven connection built around Maki's evolving CS process.
● The Cashmyrr solution
Architecture First, Migration Last
We treated this as a full revenue infrastructure build, not a data export. The migration was the final step, not the first.
Before a single record moved, we designed the CRM architecture around Maki's actual sales motion: how their AEs qualified deals, what data the CS team needed in Planhat, and which historical records still needed to be accessible post-cutover. We structured the project in phases:
- object design and field configuration first,
- validation logic and automation second,
- data migration and integration last.
This sequencing matters. In most failed CRM migrations, data moves before the destination is ready. Fields don't exist yet. Picklist values don't match. Automations fire on incomplete records. Starting with architecture prevents that.
● Steps
Full Salesforce CRM Implementation
1. Mapping ~200 Fields Across Three Core Objects
The first task was translating Maki's entire data model from HubSpot into Salesforce. We identified and documented every field across three objects:
- Account: ~100 fields (10 standard, 98 custom): Account Tier, Account Segment, Territory, Account Status, and more
- Contact: ~ 45 fields (standards and customs): Contact Persona, Seniority, LinkedIn ID, and more
- Opportunity: ~ 55 fields (standards and customs): MEDDPICC fields, ANUM qualification fields, forecast category mapping
This wasn't a copy-paste job. We mapped each field to its correct Salesforce type, proposed picklist values for every dropdown, and produced structured validation files for Marc's team to approve before a single field was deployed.
2. Sales Pipeline Configuration and MEDDPICC Enforcement in Salesforce
We configured Maki's main sales pipeline across eight stages:
| Stage | Name | Forecast Category |
|---|---|---|
| S00 | Engage | Pipeline |
| S0 | Qualify | Pipeline |
| S1 | Prescribe | Pipeline |
| S2 | Build Value | Best Case |
| S3 | Align | Best Case |
| S4 | Validate | Commit |
| S5 | Contracting | Commit |
| S6 | Won / Lost | Closed |
A separate Upgrade pipeline (U1–U4) was built for the Customer Success team to manage expansion revenue alongside the new-logo process.
Validation rules, the guardrails that keep your CRM data clean:
- MEDDPICC fields become required the moment a deal progresses past S1
- Stage rollback past S2 is blocked entirely
- ANUM qualification fields must be filled at S0 and are locked once the deal advances to S1
- At account level: a customer status, once set, cannot be removed
- At contact level: first name, last name, and associated account are mandatory; each contact must have either an email or a phone number; LinkedIn ID uniqueness is enforced across the database
Why this matters for CRM data quality: Validation rules are the difference between a CRM that reflects reality and one that reflects what reps remember to fill in. Enforcing MEDDPICC at stage progression means the pipeline data is actually usable for forecasting.
3. Six Salesforce Automation Flows for Account Lifecycle Management
We built six trigger-based flows that move accounts through their lifecycle automatically, no manual status updates required:
- Open → Assigned: fires when an account owner is set
- Assigned → Working: fires after manual activity is logged within a 30-day window
- Working → Qualifying: fires when a new opportunity at stage S00 is created against the account
- Qualifying → Pipeline: fires when that opportunity advances from S0 to S1
- Pipeline → Customer: fires the moment an opportunity closes as Won
This means account status in Salesforce always reflects the real commercial relationship, with no dependency on a rep remembering to click.
4. CRM Data Migration: Including the Messy Parts
Data migration from HubSpot to Salesforce meant dealing with pipelines mid-transition. The Renewal pipeline, which Maki planned to sunset post-migration, still had historical deals that needed to land in Salesforce for Planhat's NRR tracking to stay accurate.
Our approach:
- Created a temporary Renewal pipeline in Salesforce specifically to absorb these records, then locked it to prevent new deals from being added
- Prioritized Closed Won renewal deals for migration first, validated by the CS team
- Where Contact IDs were missing from migrated opportunities (a known gap from the legacy data model), we reconciled ~ 200 records with full transparency on the ~160 that could not be matched
5. Rebuilding the Planhat Integration on Salesforce
Planhat is the platform Maki's CS team uses to manage customer accounts and track Net Revenue Retention. Until this project, it synced directly with HubSpot.
Our job: replicate that integration logic in Salesforce, field by field, picklist value by picklist value while extending it to support Maki's evolving process.
Key integration logic:
Export to Planhatfield on both Account and Opportunity objects as the sync trigger- Account creation in Planhat fires automatically when a deal enters the Commit 90% forecast category (S5: Contracting)
- Upgrade pipeline syncs bidirectionally with Planhat so CS expansion revenue stays in sync with the sales pipeline
Contract Start DateandContract End Dateset as mandatory fields on deal creation, ensuring Planhat always receives the data it needs to calculate ARR accurately
● Result
What Maki Walked Away With
| Deliverable | Detail |
|---|---|
| Custom fields configured | ~ 200 across Account, Contact, Opportunity |
| Sales pipelines live | 3 (Main Sales, Renewal historical, Upgrade) |
| Automation flows | 6 managing full account lifecycle |
| Validation rules | MEDDPICC, ANUM, stage rollback, contact integrity |
| Planhat integration | Rebuilt on Salesforce with contract date tracking |
| Documentation | Full field mapping in structured Excel files |
| Ongoing support | Monthly Salesforce retainer |
Before and After: Single Source of Truth vs. Two Systems Out of Sync
Before:
Maki's revenue team operated across two systems increasingly out of sync, HubSpot for parts of the sales and CS workflow, Salesforce as the intended destination that hadn't been fully built. Deal data lived in pipelines that no longer matched the team's real process. Planhat was syncing from HubSpot through a connection about to be cut.
After:
Salesforce is Maki's single source of truth for the full sales cycle. Every account moves through a defined, automated lifecycle. Every deal must carry the qualification data the methodology requires before it can advance. The CS team's Planhat sync runs off Salesforce without any manual export. The sales team has a CRM built around how they actually sell, built around how they sell today, not how they sold at Series Seed.
● FAQ
For a revenue team of this complexity, 200+ fields, multiple pipelines, a third-party CS platform integration, expect 6–10 weeks for a properly sequenced migration. Rushing the architecture phase to move data faster is the most common cause of post-migration rework.
Yes, but it requires upfront mapping of every object, field, and pipeline stage before any data moves. Legacy pipelines that no longer match your new process (like Maki's Renewal pipeline) need a deliberate migration strategy, not just a bulk export.
MEDDPICC works in Salesforce through a combination of custom fields on the Opportunity object and validation rules that make those fields required at specific stage progressions. Without validation rules, MEDDPICC stays optional in practice regardless of what the methodology says.
The key is rebuilding the integration logic natively — not relying on a generic connector. That means mapping every synced field explicitly, matching picklist values exactly, and defining the trigger logic (which Salesforce event creates or updates a Planhat record) before going live.
● More case studies
