Module 1 — Zoho CRM

Leads, Contacts, Accounts, Deals — pipelines, blueprints, workflows, layouts. Bâtir la colonne vertébrale commerciale d'une PME.

🏛️ Architecture des modules CRM

Zoho CRM organise la donnée commerciale en 4 modules natifs principaux, reliés entre eux par des relations many-to-one ou many-to-many.

ModuleRôleRelation
LeadsProspect non qualifié (suspect)Pas de lien avec Account/Contact tant que pas converti
AccountsEntreprise (entité morale) cliente ou prospect1 Account → N Contacts, N Deals
ContactsPersonne physique (interlocuteur d'un Account)N Contacts → 1 Account, M2M avec Deals
DealsOpportunité commerciale ($, stage, close date)1 Deal → 1 Account, N Contacts
💡
Lead vs Contact — la confusion #1

Beaucoup de débutants créent directement des Contacts sans passer par Leads. Mauvaise idée : un Lead permet de tracker le cycle de qualification (source, score, statut) sans polluer la base Contact avec des prospects qui n'aboutiront pas.

Règle : tout nouveau contact entrant (formulaire web, salon, scrapping) → Lead. Une fois qualifié (BANT validé, intérêt confirmé) → conversion en Contact + Account + Deal.

🚦 Pipeline et stages

Un pipeline = une séquence de stages qu'un Deal traverse jusqu'à signature. Zoho CRM permet plusieurs pipelines parallèles (ex: Vente Logiciel, Vente Services, Vente Maintenance) — chacun avec ses propres stages.

Stages par défaut

Qualification (10%)
  ↓
Needs Analysis (20%)
  ↓
Value Proposition (40%)
  ↓
Proposal/Quote (60%)
  ↓
Negotiation (80%)
  ↓
Closed Won (100%) ━━┓
Closed Lost (0%)  ━━┛

Chaque stage a une probabilité (%) utilisée pour calculer le weighted_amount = amount × probability. C'est ce qui alimente vos prévisions de CA.

Créer un pipeline custom

  1. Setup → Customization → Modules → Deals → Layouts → Pipeline
  2. Bouton + New Pipeline
  3. Nommer (ex: Pipeline SAV Madagascar)
  4. Ajouter stages personnalisés avec probabilités
  5. Mapper sur un layout (pour montrer ce pipeline à certains profils ou produits)
⚠️
Renommer un stage n'est pas anodin

Si vous renommez un stage déjà utilisé, tous les Deals historiques voient leur label changer mais conservent leur état logique. Les workflows et reports basés sur l'ancien nom de stage peuvent casser. Préférez désactiver l'ancien stage et créer un nouveau, plutôt que renommer.

⚙️ Workflow Rules — automatiser sans code

Un Workflow Rule = règle déclenchée sur événement (création/modif/date), qui exécute une ou plusieurs actions. C'est l'outil d'automatisation principal de Zoho CRM (avant Deluge).

Triggers disponibles

TriggerQuand ?Exemple
On a Record ActionCreate / Edit / Field Update / ConvertQuand un Deal passe en Closed Won
On a Date/TimeDate relative à un champ (J+7 après création)Relance auto si Deal sans activité depuis 14 jours
On a Record's ScoreQuand le scoring atteint un seuilLead score ≥ 80 → assigner au commercial senior
Via WebhookAppel externe POSTFormulaire web envoie un Lead

Actions possibles

Exemple concret — auto-assignation par région

Rule: "Auto-assign Lead by country"
Module: Leads
Trigger: On Create
Conditions:
  Country IS "France"
Actions:
  Field Update: Lead Owner = "Commercial FR"
  Email Alert: notify-commercial-fr@ezway-technology.com

Condition: ELSE IF Country IS "Maroc"
Actions:
  Field Update: Lead Owner = "Commercial MA"
Limite de workflow rules par module

30 sur Standard, 50 sur Professional, illimité sur Enterprise. Si vous dépassez, regroupez plusieurs actions dans une seule rule via Custom Function Deluge.

🗺️ Blueprints — imposer un process

Un Blueprint définit un flux linéaire ou conditionnel entre statuts. Contrairement aux workflows (passifs), un Blueprint bloque les transitions non autorisées et exige validations / champs obligatoires / actions à chaque étape.

Cas d'usage typique

Un Deal ne peut passer de Proposal Sent à Negotiation que si :

Sans Blueprint, le commercial peut sauter ces étapes silencieusement. Avec Blueprint, la transition est bloquée tant que les critères ne sont pas satisfaits.

Setup d'un Blueprint

  1. Setup → Process Management → Blueprints → + Create Blueprint
  2. Choisir le module (Deal, Lead, Custom) + champ de statut
  3. Construire visuellement le graph des transitions
  4. Pour chaque transition : ajouter Before Transition (champs requis), During (actions auto), After (Deluge function éventuelle)
  5. Activer + assigner aux profils utilisateurs concernés
⚠️
Blueprint vs Workflow — choisir le bon outil

Si vous voulez juste réagir à un changement → Workflow Rule. Si vous voulez imposer un process avec validations bloquantes → Blueprint. Beaucoup d'organisations utilisent les deux : Blueprint pour cadrer le commercial, Workflows pour les alertes side-effects.

🎨 Layouts — formulaires custom par profil

Un Layout = un agencement de champs (ordre, sections, obligatoires, lecture seule) qu'on assigne à un profile utilisateur. Permet d'avoir des formulaires différents pour les commerciaux BtoB vs BtoC, par exemple.

Sections et champs custom

Dans Setup → Customization → Modules → [Module] → Layouts :

Formula fields — colonnes calculées

Comme dans Excel : un champ formula calcule sa valeur à partir d'autres champs.

// Champ : Days_to_Close (Number, formula)
${Closing_Date} - ${Created_Time}

// Champ : Full_Name (String, formula)
${Salutation} + " " + ${First_Name} + " " + ${Last_Name}

// Champ : Deal_Bucket (Picklist, formula)
if(${Amount} >= 50000, "Enterprise",
  if(${Amount} >= 10000, "Mid-Market", "SMB"))
Formula fields ≠ workflow field update

Un formula field est recalculé en temps réel et non éditable. Un field update via workflow stocke une valeur figée. Choisissez formula si la valeur dépend uniquement d'autres champs ; workflow si la logique est plus complexe (Deluge requis) ou s'il faut une valeur éditable plus tard.

🔌 API REST — bases

L'API REST Zoho CRM permet de tout faire en programmatique : CRUD records, recherches, conversion de Lead, déclenchement de workflows…

Authentification OAuth 2.0

  1. Créer un Self Client dans api-console.zoho.com
  2. Récupérer client_id, client_secret
  3. Générer un grant_token avec scopes : ZohoCRM.modules.ALL,ZohoCRM.settings.ALL
  4. Échanger le grant_token contre un refresh_token (longue durée) + access_token (1h)
  5. Stocker refresh_token côté serveur, regénérer access_token à chaque appel ou en cache court

Exemple — créer un Lead

POST https://www.zohoapis.eu/crm/v2/Leads
Authorization: Zoho-oauthtoken 1000.xxxx.yyyy
Content-Type: application/json

{
  "data": [{
    "Last_Name": "Dupont",
    "First_Name": "Jean",
    "Email": "jean.dupont@example.com",
    "Company": "ExampleCorp",
    "Lead_Source": "Web",
    "Phone": "+33612345678"
  }]
}

// Response : 201 Created
{ "data": [{ "code": "SUCCESS", "details": { "id": "554023000001235001" } }] }
Datacenter — attention au domaine

Zoho a plusieurs datacenters (US, EU, IN, AU, CN, JP). Votre tenant est dans UN seul — typiquement EU pour les comptes français (RGPD oblige). Si vous appelez la mauvaise URL (zohoapis.com au lieu de zohoapis.eu), vous aurez un 401 sans message clair.

Vérifiez le datacenter dans Setup → My Account → Datacenter avant tout dev API.

Rate limits API

ÉditionAPI calls / user / jourOrg cap
Standard1 000100 000
Professional2 000200 000
Enterprise5 000500 000
Ultimate / CRM Plus10 0001 000 000

Les imports en masse passent par Bulk API (jusqu'à 25 000 records/job, 50 jobs/jour) — pas par les endpoints unitaires.

🔗 Ressources officielles

📋 Quiz de validation

Accueil Module 2 — Zoho Books →