Application de pipeline de propositions pour freelances : du Brouillon au Gagné/Perdu

Pourquoi les propositions tombent entre les mailles\n\nLa plupart des freelances ne perdent pas des propositions parce que leur travail est mauvais. Ils les perdent parce que la proposition disparaît.\n\nLe bazar habituel vous dit quelque chose : un brouillon dans un document, un PDF final dans un dossier, le dernier message client enterré dans un e‑mail ou un chat, et le seul « statut » est ce dont vous vous souvenez. Quand vous êtes occupé à livrer, il est facile d’oublier qui attend un devis et qui a besoin d’un deuxième rappel.\n\nLes propositions finissent éparpillées dans des endroits comme :\n\n- Un Google Doc appelé « Proposal v7 FINAL (2) »\n- Un fil d’e‑mail avec trois sujets différents\n- Une note dans votre téléphone avec une date de relance\n- Un rappel de calendrier sans contexte\n- Votre tête (jusqu’à ce qu’il soit trop tard)\n\nLes propositions glissent pour une raison simple : il n’y a pas un endroit unique qui montre la prochaine action. Si vous ne pouvez pas répondre à « Que dois‑je faire ensuite, et pour quel client ? » en 10 secondes, les relances sont retardées. Les relances retardées se transforment en affaires perdues, même quand le client était intéressé.\n\nC’est ce qu’est un pipeline, en termes simples : un petit ensemble de statuts clairs qui montrent où en est chaque proposition et ce qu’il faut faire ensuite. Une application de pipeline de propositions n’est pas une machine de vente sophistiquée. C’est un tableau de score et une liste de tâches en un.\n\nRestez réaliste. Vous ne construisez pas un CRM complexe avec prévisions, territoires et rapports que vous ne lirez jamais. Vous voulez un outil léger qui corresponde à votre façon de travailler et rende la « prochaine étape » évidente.\n\nVoici ce que cela évite. Vous envoyez un devis de refonte de site mardi et vous vous dites que vous relancerez vendredi. Vendredi est chargé. Lundi, vous ne vous souvenez plus si vous avez déjà relancé. Un petit pipeline avec un seul statut visible « En attente du client » et une date de prochaine relance claire empêche cette perte silencieuse.\n\n## Ce que doit faire un pipeline de propositions léger\n\nUne application de pipeline a un seul travail : faire progresser chaque proposition du Brouillon au Gagné ou Perdu avec le moins d’effort possible. Si elle crée du travail administratif supplémentaire, vous arrêterez de l’utiliser juste au moment où vous en avez besoin.\n\nAvant de concevoir quoi que ce soit, décidez ce que vous devez savoir d’une proposition même des mois plus tard. Limitez‑vous aux quelques détails qui vous aident à relancer, prévoir des revenus et comprendre ce qui se vend.\n\nUn minimum pratique pour chaque proposition :\n\n- Client (personne ou entreprise) et moyen de contact\n- Type de service (par exemple : refonte de site, appli mobile, SEO mensuel)\n- Montant estimé (ou fourchette) et date de démarrage prévue\n- Date de prochaine relance\n- Statut actuel (Brouillon, Envoyé, Négociation, Gagné, Perdu)\n\nEnsuite, définissez ce que signifie « terminé » pour que l’app reste digne de confiance. Une proposition ne devrait pas rester indéfiniment en Envoyé. « Terminé » signifie que les éléments bloqués déclenchent des rappels, que les résultats sont enregistrés quand vous avez une réponse, et que vous pouvez voir des rapports simples sans exporter de feuilles de calcul.\n\nGardez la portée réduite au départ. Un seul utilisateur, un seul espace de travail et des champs simples valent mieux qu’un gros système que vous ne maintenez pas. Si vous envoyez trois propositions cette semaine (deux pour « page d’atterrissage + texte » et une pour « support en régie »), un pipeline qui impose une date de prochaine relance et un résultat montrera rapidement quel service se conclut le plus souvent et où vous perdez du temps.\n\n## Choisissez des statuts qui correspondent à votre vrai flux de travail\n\nLes statuts n’aident que s’ils reflètent votre journée réelle, pas un processus idéal que vous ne suivrez pas. Gardez l’ensemble assez petit pour que déplacer une carte en avant reste sans effort.\n\nUn ensemble pratique :\n\n- Brouillon\n- Prêt à envoyer\n- Envoyé\n- Relance due\n- Négociation\n- Gagné\n- Perdu\n\nGardez les noms courts et orientés action. Si vous ne savez pas quoi faire ensuite en lisant un statut, renommez‑le.\n\nEnsuite, définissez quelques règles simples pour qu’aucune proposition ne devienne un zombie.\n\nPar exemple :\n\n- Une proposition ne peut pas passer à Envoyé à moins qu’elle ait un client, un type de service, un prix total et une fenêtre de livraison.\n- Négociation doit signifier que le client a répondu et que le périmètre, le prix ou les conditions changent activement.\n- Gagné doit exiger un signal clair : un accord signé, un acompte payé ou un « oui » écrit.\n\nLes dates de relance sont l’autre garde‑fou. Tous les statuts n’ont pas besoin d’un rappel, mais certains oui. Une valeur par défaut solide est : Envoyé et Relance due doivent avoir une date de prochaine relance. Négociation peut en exiger une aussi, mais seulement quand la prochaine étape dépend de vous.\n\nUn scénario rapide : vous envoyez un devis de refonte le lundi. Si vous n’avez pas de nouvelles le jeudi, il apparaît en Relance due. Si le client répond « peut‑on supprimer le blog et baisser le prix ? », vous le passez en Négociation et fixez la prochaine relance au lendemain. C’est assez de structure pour maintenir l’élan sans transformer votre flux en paperasserie.\n\n## Concevez les données : clients, propositions, services, activités\n\nUne application de pipeline vit ou meurt par ses données. Si la structure est trop lâche, vous sauterez des champs. Si elle est trop stricte, vous arrêterez de l’utiliser. Visez un petit ensemble d’enregistrements fiables, puis ajoutez des détails seulement quand la vraie douleur apparaît.\n\nCommencez par quatre objets principaux : Clients, Propositions, Services et Activités.\n\n### Les tables centrales (et ce qu’elles stockent)\n\nGardez la première version simple :\n\n- Clients : nom, personne de contact, e‑mail, notes (et optionnellement taille de l’entreprise)\n- Propositions : titre, client_id, service_type (ou services), valeur, statut, sent_date, next_follow_up_date, outcome_reason\n- Services : nom (par exemple : « Refonte de site », « Audit SEO »), fourchette de prix par défaut optionnelle\n- Activités : proposal_id, type (note, rappel, appel, e‑mail), timestamp, détails\n\nPour les propositions, next_follow_up_date est le filet de sécurité pour votre futur vous. outcome_reason compte quand vous marquez Gagné ou Perdu, parce que « Perdu : trop cher » et « Perdu : timing » mènent à des corrections différentes.\n\n### Un service par proposition vs plusieurs services\n\nUn type de service par proposition est la configuration la plus rapide et fonctionne si vous vendez des forfaits clairs. Plusieurs services par proposition sont mieux si vous emballez du travail (design + réalisation + maintenance), mais cela ajoute de la complexité. Vous aurez besoin d’une table de jonction (comme ProposalServices) et vos rapports deviennent plus compliqués.\n\nUn bon compromis est de commencer avec un seul type de service et d’ajouter plusieurs services seulement quand vous voyez de vraies propositions mixtes.\n\nLes activités vous donnent un historique léger sans fouiller dans les e‑mails. Après l’envoi d’une proposition, notez rapidement « Envoyé v2, le client a demandé le calendrier ». Plus tard, vous verrez ce qui s’est passé en un coup d’œil.\n\n## Planifiez les écrans : tableau, liste, détails, rapport\n\nUne application de pipeline a seulement besoin de quelques écrans si chacun répond à une question claire. Le but est la vitesse : ouvrez‑la, voyez ce qui nécessite de l’attention, faites une mise à jour, et passez à la suite.\n\n### Tableau de pipeline (vue quotidienne)\n\nC’est l’écran où vous vivez. Chaque colonne est un statut. Chaque carte doit montrer juste assez pour décider de l’action suivante :\n\n- Nom du client\n- Valeur de la proposition (ou retenue mensuelle estimée)\n- Date de prochaine relance\n- Étiquette du type de service\n\nLes actions rapides comptent plus qu’une mise en page parfaite. Depuis la carte (ou un petit panneau de détails), vous devez pouvoir changer le statut, définir une date de relance, ajouter une note et marquer Gagné ou Perdu sans remplir un long formulaire.\n\n### Liste de propositions (vue recherche et rattrapage)\n\nLes tableaux sont excellents pour le flux, mais les listes sont meilleures pour retrouver des éléments. Utilisez une liste en style table simple avec des filtres comme statut, client, type de service et relance en retard. C’est votre vue « rattrapage » quand la semaine devient chargée.\n\n### Pages de détails (modifications rapides, pas de paperasse)\n\nVous n’avez besoin que de deux pages : une page Proposition et une page Client.\n\nLa page Proposition sert au fil d’activité (notes, changements de statut, date de prochaine relance) plus les champs clés comme la valeur et le type de service. La page Client est le contexte : coordonnées, propositions en cours et activité récente.\n\nSi changer une date de relance prend 30 secondes, vous ne la mettrez pas à jour. Optimisez ces pages pour des modifications en un geste.\n\n### Rapport simple (une seule page)\n\nUn rapport léger suffit au départ : taux de clôture par type de service et temps moyen de clôture. Il doit répondre à deux questions : « Que dois‑je vendre davantage ? » et « Où les affaires stagnent‑elles ? »\n\n## Construisez‑la de zéro à utilisable\n\nUne application de pipeline utilisable n’est pas un « CRM complet ». C’est un endroit pour voir ce qui est actif, ce qui est bloqué et ce qui nécessite une relance aujourd’hui.\n\n### Construisez une première version utilisable dans la journée\n\nCommencez par le modèle de données et quelques faux enregistrements pour tester le flux. Créez un client avec deux propositions et au moins deux types de services (par exemple, « Refonte de site » et « SEO continu »).\n\nPuis construisez deux écrans centraux : un tableau (colonnes par statut) et un formulaire de détail de proposition. Le tableau sert pour le scan quotidien. Le formulaire sert aux mises à jour précises.\n\nUn ordre de construction qui vous fait avancer :\n\n- Modèle : Client, Proposal, ServiceType, Activity\n- UI : Vue tableau + Formulaire de détail de proposition (statut, valeur, date d’envoi, prochaine relance)\n- Règles : Bloquer les déplacements de statut si des champs clés manquent (par exemple, Envoyé requiert une date d’envoi)\n- Rappels : Notifier quand une relance est due (et optionnellement quand une proposition devient Envoyé)\n- Tableau de bord : Comptes par statut et un graphique de taux de conversion par type de service\n\n### Ajoutez des vérifications "ne peut pas avancer tant que..."\n\nC’est ce qui rend l’app fiable.\n\nExemple : vous faites glisser une proposition de Brouillon à Envoyé, mais l’app vous bloque s’il n’y a pas d’e‑mail client ou de montant. Cette petite friction évite des données désordonnées plus tard.\n\nUne règle par défaut garde tout en ordre : toute proposition ouverte doit avoir une date de prochaine relance. Si elle manque, affichez un avertissement sur le tableau.\n\nUne définition simple d’« utilisable » :\n\n- Vous pouvez ajouter une proposition en moins de 60 secondes\n- Vous voyez en un coup d’œil qui relancer aujourd’hui\n- Les changements de statut restent cohérents (pas de propositions à moitié envoyées)\n- Le taux de clôture est visible par type de service\n- Les rappels restent discrets quand vous êtes déjà à jour\n\n## Rappels pilotés par le statut qui ne vous énervent pas\n\nLes rappels fonctionnent mieux quand ils sont liés à un moment clair du pipeline, pas à un ping aléatoire du calendrier. Si votre app connaît le statut courant, elle peut vous relancer uniquement quand une proposition risque de devenir obsolète.\n\nVous n’avez pas besoin de nombreux déclencheurs. Une configuration simple ressemble à ceci :\n\n- Quand une proposition passe à Envoyé, exigez une date de prochaine relance.\n- À la date de relance, envoyez un rappel unique.\n- Si aucune réponse n’arrive après X jours en Envoyé, créez automatiquement une tâche de relance.\n\nGardez le texte des rappels court et orienté action. Incluez seulement pour qui c’est, de quoi il s’agit et la prochaine action :\n\n- "Relancer {Client} : {Proposal} - petit point"\n- "{Client} / {Proposal} - demander s’ils veulent des modifications avant approbation"\n- "{Client} / {Proposal} - confirmer calendrier et date de démarrage"\n\nAjoutez des garde‑fous pour éviter le bruit : limitez les rappels à un par proposition et par jour, et offrez des options Snooze (1 jour, 3 jours, semaine suivante).\n\nSuivez aussi ce qui est arrivé à chaque rappel. Stockez un petit journal de résultat : complété, reporté (jusqu’à quand), ignoré ou envoyé.\n\nExemple : vous marquez « Refonte de site - Acme Co » comme Envoyé lundi et fixez la relance au jeudi. Jeudi matin, vous recevez un rappel et le reportez à vendredi. Vendredi, vous relancez, marquez le rappel comme complété, et le minuteur « pas de réponse après X jours » est réinitialisé.\n\n## Suivre les taux de conversion par type de service (et utiliser les chiffres)\n\nUne application de pipeline n’est utile que si elle vous aide à décider quoi faire ensuite. Le moyen le plus simple d’y parvenir est de suivre les taux de conversion par type de service, pas seulement globalement. « Refonte de site » et « maintenance mensuelle » se comportent souvent comme deux entreprises différentes.\n\nD’abord, rendez les résultats cohérents :\n\n- Gagné signifie un oui clair (contrat signé, acompte payé ou date de démarrage confirmée).\n- Perdu signifie que vous ne poursuivez plus (ils ont dit non, choisi quelqu’un d’autre, ou c’est inactif depuis assez longtemps pour être considéré comme mort).\n\nChoisissez une règle et tenez‑vous‑y, sinon vos chiffres deviennent du bruit.\n\nGardez les raisons de perte courtes et cohérentes :\n\n- Prix\n- Timing\n- Inadéquation du périmètre\n- Pas de réponse\n- Choix d’un concurrent\n\nEnsuite, calculez le taux de conversion par type de service sur une fenêtre que vous utilisez réellement (30 ou 90 derniers jours). Si vous avez envoyé 12 propositions « Stratégie de marque » et en avez gagné 3, taux = 25 %. Si vous avez envoyé 6 « Création de landing pages » et en avez gagné 4, taux = 67 %. Pas besoin de perfection, juste de la stabilité.\n\nAjoutez « temps pour clôturer » pour rester honnête. Suivez les jours entre Sent et Gagné ou Perdu. Vous apprendrez peut‑être que « Audit SEO » se conclut en 5‑10 jours, alors que « Refonte complète » prend 30‑45 jours. Cela change la fréquence des relances et la façon de prévoir les revenus.\n\nRendez les chiffres exploitables par une règle simple. Si un service a un faible taux de conversion et un long temps de clôture, resserrez l’offre (périmètre, preuves, tarification) ou qualifiez mieux avant d’écrire la proposition. Si un service a un taux élevé, protégez‑le : réutilisez ce qui marche et augmentez vos prix prudemment.\n\n## Pièges courants lors de la création d’un CRM de propositions\n\nLa façon la plus rapide de rendre inutile une application de pipeline est de la rendre confuse. Les freelances commencent avec de bonnes intentions, puis se retrouvent avec un outil en lequel ils n’ont pas confiance.\n\nUn piège est d’avoir trop de statuts qui veulent dire la même chose. Si vous ne pouvez pas expliquer la différence entre « Envoyé », « Soumis », « Livré » et « En révision » en une phrase, vous avez probablement besoin d’un seul.\n\nUn autre piège est de laisser Envoyé devenir un cimetière. Si vous n’exigez pas une date de relance, vous ouvrirez le tableau plus tard et verrez une pile de propositions sans prochaine étape. Une règle simple corrige la plupart des cas : toute proposition en Envoyé doit avoir une action suivante programmée.\n\nQuelques autres erreurs qui cassent silencieusement la concentration :\n\n- Mélanger propositions et leads généraux, transformant votre pipeline en boîte de réception aléatoire\n- Ne pas enregistrer les raisons de Perdu, pour répéter les mêmes erreurs de prix et de périmètre\n- Sur‑automatiser trop tôt et passer plus de temps à régler les rappels qu’à envoyer des propositions\n\nConservez des rappels ennuyeux et précis. Un rappel lié à la date de relance suffit généralement. Les règles supplémentaires peuvent attendre un mois de données réelles d’utilisation.\n\nSi vous perdez trois propositions d’affilée avec la note « délai trop long », c’est un signal pour proposer une première phase plus petite, pas pour ajouter cinq statuts nouveaux.\n\n## Liste de contrôle rapide avant de vous y fier\n\nAvant de traiter votre pipeline comme source unique de vérité, assurez‑vous que rien ne reste en suspens et que la prochaine étape est évidente.\n\nOuvrez la vue pipeline et chronométrez‑vous. Vous devez comprendre les priorités du jour en moins de 30 secondes. Si vous devez cliquer dans plusieurs propositions pour trouver la prochaine action, votre conception cache le champ le plus important.\n\nListe de contrôle :\n\n- Toute proposition ouverte affiche un statut clair et une date de prochaine relance. Si elle n’a pas d’étape suivante, clôturez‑la.\n- Votre vue « aujourd’hui » montre des actions réalisables maintenant (relancer, envoyer, réviser), pas juste une liste stressante.\n- Quand quelque chose devient Gagné ou Perdu, vous capturez le montant final et une courte raison.\n- Le taux de conversion par type de service est visible pour une fenêtre récente que vous utilisez (30‑90 jours).\n- Les rappels peuvent être reportés, et vous ne recevez pas de doublons pour la même proposition le même jour.\n\nFaites un petit test de solidité. Créez trois propositions d’exemple pour différents services, déplacez‑les entre statuts et déclenchez des rappels. Si vous pouvez le casser en cinq minutes, vous le casserez pendant une semaine chargée.\n\n## Exemple : une semaine simple de propositions (et ce que vous en apprenez)\n\nLundi, vous envoyez cinq propositions. Trois sont pour un package de refonte, et deux pour une retenue de support mensuelle. Tout commence en Brouillon, puis passe en Envoyé une fois l’e‑mail parti.\n\nMercredi, les statuts racontent une histoire :\n\n- Deux propositions de refonte passent à Vu (vous avez vu que le client a ouvert le document)\n- Une proposition de refonte est toujours Envoyé (pas d’ouverture)\n- Une proposition de retenue passe en Négociation (ils demandent d’ajuster les heures)\n- Une proposition de retenue passe en Gagné (ils ont signé)\n\nLes rappels vous empêchent de laisser tomber. Une règle « Vu mais pas de réponse en 2 jours » vous incite à relancer les deux leads de refonte vendredi matin. Une règle « Envoyé mais pas vu en 3 jours » rattrape le silencieux et vous permet de renvoyer avec un message plus court et une action claire.\n\nLa vie réelle est désordonnée. Un client répond tard dimanche « Désolé, semaine chargée » et demande de commencer le mois prochain, vous le passez donc en En attente au lieu de le laisser pourrir en Envoyé. La négociation reste active, mais le rappel ne vérifie qu’une fois, pas tous les jours.\n\nÀ la fin de la semaine, le taux de conversion par type de service est révélateur : retenue de support 1/2 gagnées, refonte 0/3. La semaine suivante, vous changez une chose : resserrer le périmètre de refonte en deux niveaux et ajouter une date limite simple pour les retours.\n\n## Étapes suivantes : livrez une version petite, puis améliorez‑la\n\nLa façon la plus rapide d’obtenir de la valeur est de livrer la plus petite version que vous ouvrirez réellement chaque jour. Une application de pipeline n’a pas besoin de modèles, d’automatisations complexes et de graphiques dès le jour un. Elle doit vous dire ce que vous avez envoyé, ce qui attend et ce que vous devez faire ensuite.\n\nRéglez vos statuts pour que chacun réponde à une question simple : quelle action est attendue maintenant ? Si vous ne pouvez pas expliquer un statut en une phrase, il vous ralentira.\n\nTrois actions à réaliser cette semaine :\n\n- Définir 5 à 7 statuts (Brouillon, Envoyé, Relance due, Négociation, Gagné, Perdu suffit généralement)\n- Construire une vue en tableau pour déplacer les propositions entre statuts en quelques secondes\n- Activer les rappels uniquement pour les cas importants (Relance due, et Négociation quand la prochaine étape dépend de vous)\n\nUne fois que la boucle de base est naturelle, ajoutez des améliorations une à une. Un bon ordre est : rappels d’abord (pour que rien ne glisse), reporting ensuite (pour apprendre), et modèles plus tard (pour gagner du temps). Si vous ajoutez tout en même temps, vous ne saurez pas ce qui aide et ce qui devient du bruit.\n\nSi vous voulez construire cela sans beaucoup de code, AppMaster (appmaster.io) est une option pratique : vous pouvez modéliser la base de données (clients, propositions, services) et construire l’UI et les règles de statut au même endroit, puis itérer à mesure que votre processus change.\n\nGardez les améliorations petites et mesurables. Après une semaine, demandez‑vous : ai‑je relancé plus vite et ai‑je manqué moins de réponses ? Après un mois, demandez‑vous : quel service se vend le mieux et lequel nécessite une meilleure offre ou un prix plus élevé ?\n\nConsidérez la première version comme un outil personnel, pas un produit. Si ajouter une proposition ou la faire avancer prend plus de 30 secondes, simplifiez les champs et les écrans avant d’ajouter quoi que ce soit. Quand l’usage devient sans effort, vous l’utiliserez vraiment et les données resteront fiables.