Reciprok Docs
Vue d'ensemble

Spécification fonctionnelle

La spec complète telle que définie par le fondateur, input non-modifié

Vision

Reciprok est une plateforme interne de mise en relation entre des organisateurs d'événements (les clients) et des membres (établissements, restaurants, lieux, prestataires). L'équipe Reciprok utilise cette application pour traiter des demandes d'événements de bout en bout : recevoir la demande, trouver les meilleurs lieux, envoyer un catalogue personnalisé, suivre la négociation, et facturer la commission.

L'application intègre un assistant IA (Claude) à chaque étape. Cet assistant dispose de sa propre base de connaissances alimentée par les membres eux-mêmes, peut exécuter des actions concrètes (chercher, modifier, envoyer), et s'améliore au fil du temps grâce aux corrections de l'utilisateur.

Les 3 Acteurs

L'utilisateur interne, L'équipe Reciprok. Utilise l'application au quotidien pour traiter les demandes, chercher les membres, composer les catalogues, envoyer les emails, suivre les deals, facturer les commissions, et interagir avec l'IA.

L'organisateur, Le client. Il cherche un lieu pour son événement. Il envoie sa demande (par email, téléphone, formulaire, ou vocal), reçoit un catalogue, négocie, et finalise. Il peut être nouveau ou récurrent (la commission change). Il peut avoir été référé par un membre.

Le membre, Un établissement, restaurant, lieu événementiel, ou prestataire inscrit dans la base Reciprok. Il a une fiche descriptive, des espaces/salles, des disponibilités. Il peut alimenter la base de connaissances de l'IA en enregistrant des audios ou en envoyant des messages texte.

Module 1, Les Membres

Fiche Membre

Un membre est une entité unique, qu'il soit un restaurant, un rooftop, un château, un fleuriste, un DJ, ou un traiteur. Pas de distinction technique entre "établissement" et "prestataire", c'est le même objet avec les mêmes capacités.

Chaque membre possède :

Identité :

  • Nom
  • Code unique lisible (ex: #102), utilisé partout dans l'app et par l'IA pour éviter les confusions
  • Description
  • Adresse, ville, code postal
  • Coordonnées GPS
  • Email, téléphone, nom du contact
  • Site web
  • Groupe d'appartenance (optionnel, ex: chaîne de restaurants)
  • Photos (galerie, ajout/suppression/réordonnancement)
  • Actif ou inactif

Capacités par configuration de salle :

On adopte le standard Kactus (7 configurations événementielles reconnues par le marché). Chaque salle ou espace déclare la capacité maximale qu'elle accepte pour chaque configuration qu'elle supporte. Une salle ne supporte pas forcément les 7 configurations.

ConfigurationDescriptionUsage typique
RéunionTable de réunion classiquePetit comité, board meeting
Salle en UTables disposées en U avec chaises à l'extérieurPrésentations interactives, formations
ThéâtreChaises alignées face à un orateurConférences, keynotes
CabaretPetites tables rondes avec chaises (style restaurant)Présentations conviviales, workshops
Rang d'écoleTables alignées en rangéesFormations, examens
BanquetGrandes tables rondes pour repasRepas, soirées de gala
CocktailDebout, libre circulationCocktails dînatoires, networking

Chaque configuration est associée à une capacité maximale par salle. Une même salle peut accueillir 60 en cocktail mais seulement 30 en théâtre, c'est la configuration qui détermine la jauge utile pour l'événement.

Tarification :

  • Budget bas / Budget haut
  • Montant minimum de réservation

Espaces / Salles : Un membre peut avoir plusieurs espaces. Chaque espace a son propre nom, description, image, capacités déclarées par configuration (les configs qu'il supporte avec la jauge max pour chacune), tarifs minimum, horaires d'ouverture, et tarif de privatisation.

Tags : Les membres sont classés par des tags qui décrivent leur profil sur plusieurs dimensions : typologie (rooftop, péniche, château, loft, jardin...), ambiance (festif, chic, décontracté, intimiste...), services (traiteur intégré, DJ, décoration...), cuisine, et tout autre critère pertinent. Ces tags sont en partie structurés automatiquement par l'IA à partir des descriptions et des audios enregistrés par les membres.

Dashboard Membre (accès externe simplifié)

Le membre accède à un espace personnel via un lien sécurisé. Cet espace est volontairement minimaliste :

  • Voir les demandes qui le concernent et leur avancement

  • Voir ses commissions

  • Modifier ses informations de base

  • Gérer ses disponibilités de manière naturelle : pas de calendrier complexe à remplir case par case. Le membre écrit ou dicte ses indisponibilités en langage naturel. Exemples :

    • "Je suis complet le 12 mai, salle 1 privatisée"
    • "Pas disponible le 17 mai à partir de 18h, lieu entier"
    • "Fermé du 1er au 15 août"

    L'IA interprète ces messages et met à jour les disponibilités en base de manière structurée. Le membre peut aussi envoyer ces infos via un lien externe (audio ou texte) sans même se connecter au dashboard. L'objectif : zéro friction, le membre ne doit pas se battre avec un calendrier, il dit juste quand il n'est pas libre.

Module 2, Les Organisateurs

  • Nom de l'entreprise, type, contact, poste
  • Adresse, code postal
  • Email (unique), téléphone
  • Référé par (quel membre a envoyé cet organisateur, important pour la commission)
  • Nouveau client ou récurrent (la commission n'est pas la même)
  • Date de premier contact

Création automatique

Quand une demande est créée, si l'organisateur n'existe pas en base (vérification par email), il est automatiquement créé à partir des informations de la demande.

Module 3, La Demande

C'est le coeur de l'application. Tout tourne autour de la demande.

Cycle de vie

Chaque transition est enregistrée dans la timeline de la demande.

3 façons de créer une demande

  1. Formulaire manuel, l'utilisateur remplit (description, participants, budget, configuration(s) de salle souhaitée(s) parmi les 7 standards Kactus, voir Module 1, plusieurs dates possibles, zone géo, infos complémentaires riches, contact organisateur, membre référent). L'organisateur peut accepter plusieurs configurations (ex: cocktail OU banquet selon le lieu)
  2. Email entrant parsé par l'IA, l'email arrive, Claude extrait les champs, pré-remplit le formulaire, l'utilisateur valide
  3. Message vocal, l'audio est transcrit par Whisper, Claude extrait les champs, l'utilisateur valide

Le champ "Informations complémentaires"

Ce champ mérite une attention particulière. Les organisateurs y mettent souvent les détails les plus importants : l'ambiance souhaitée, les contraintes spéciales, le type de clientèle, ce qu'ils veulent absolument ou absolument pas. L'IA doit systématiquement analyser ce champ pour enrichir sa compréhension de la demande, affiner ses recherches, et identifier des critères non couverts par les champs structurés.

Module 4, Requalification

Les demandes arrivent souvent incomplètes. Email de requalification généré par l'IA, envoyé à l'organisateur, logué dans la timeline. WhatsApp jumelable. Réponse captée (email webhook ou lien vocal). L'IA extrait les nouvelles infos. Historique conversationnel structuré dans la demande.

Module 5, Recherche de Membres

Pipeline en 3 couches pour gérer 70 000+ membres en quelques secondes :

  1. Filtrage technique (DB), élimine sur critères durs (géo, capacité, budget, dispo, tags) → quelques centaines de candidats
  2. Classement sémantique, compare le profil sémantique de la demande avec celui de chaque candidat (description, infos complémentaires, KB du membre) → top 15-20
  3. Analyse Claude, l'IA reçoit uniquement le top 15-20, classe et explique → 8 à 12 suggestions finales argumentées

L'utilisateur peut envoyer la demande à un membre, un groupe entier, une sélection, ou un pool ciblé. Sans ajout manuel un par un, mais avec retrait individuel possible.

Module 6, L'Assistant IA (Chat)

Chat intégré dans la page de demande. L'IA peut :

  • Chercher ("Trouve-moi un rooftop dans le 8ème")
  • Modifier ("Change le budget à 15 000€", "Retire #102")
  • Analyser ("Cette demande ressemble à quoi dans l'historique ?")
  • Agir avec confirmation ("Envoie un email de requalification")

Identification systématique des membres par leur code unique (#102). Persistance complète de l'historique. Interaction écrite ou orale.

Module 7, Base de Connaissances IA

Chaque membre alimente sa propre KB via un lien personnel :

  • Audios de présentation, l'IA transcrit (Whisper), structure par thème (description, espaces, tarifs, ambiance, contraintes...), stocke en base
  • Mises à jour de dispo en langage naturel, "Complet le 12 mai salle 1 privatisée" → l'IA stocke ça en KnowledgeEntry typée availability_rule. La réponse définitive pour une demande active passe par RequestAvailabilityCheck (magic link envoyé au membre)
  • Notes de l'équipe, saisie manuelle, audits, observations

Chaque entrée est sourcée, typée, et indexée pour la recherche sémantique. Quand l'IA cherche des membres, elle consulte automatiquement la KB des candidats pour affiner ses recommandations.

Module 8, Le Catalogue

  • 4 "Fortement recommandés" + 4 "Compatibles"
  • Drag & drop pour réordonner / déplacer entre tiers
  • Mix des suggestions IA et des choix utilisateur
  • Tableau détaillé directement visible (pas caché)
  • Envoi par email + lien online + WhatsApp jumelable
  • Logué dans la timeline

Module 9, Disponibilités

Demande de disponibilité : depuis une demande, envoi d'un email à un ou plusieurs membres avec lien de réponse. Le membre clique → choisit Disponible / Partiel / Non disponible + notes. Réponse enregistrée et visible.

Mise à jour des dispos :

  1. Réponse à une demande de dispo spécifique (lien email)
  2. Lien personnel : le membre dicte ou écrit en langage naturel ("Pas dispo le 17 mai après 18h")
  3. Dashboard membre : même principe, langage naturel, pas de calendrier à cliquer case par case

L'IA interprète et structure : date, créneau (midi/soir/heures), espace concerné, statut (disponible/partiel/non/option), notes.

Module 10, Pipeline d'un membre dans une demande

Avancement direct depuis la carte du membre dans la demande. Sélection du gagnant → email au gagnant + emails aux non-retenus. Statut demande → "Gagné" → étape commission. Demande perdue → raison + log timeline.

Module 11, Timeline

Journal de bord structuré de la demande. Chaque événement : type, contenu, acteur (user/ai/system/member/organizer), horodatage. Tout est tracé : création, statuts, emails, requalifs, catalogues, disponibilités, ajout/retrait de membres, sélection gagnant, recommandations, commissions, notes, suggestions IA, WhatsApp, vocaux.

Le membre référent peut accéder à une vue simplifiée de la timeline via un lien sécurisé.

Module 12, Emails et Communications

Types d'emails liés au flow : requalification, catalogue, demande de dispo, notification de dispo, recommandation, sélection, non-sélection, relance, satisfaction, commission.

Emails marketing (boutons rapides sur cartes membres) : "Découvrir Reciprok", "Découvrir les prestataires", "Vérifier vos critères", "RefleX Reciprok".

Threads conversationnels structurés. Jumelage WhatsApp pour chaque envoi. Règle absolue : aucun email ne part sans trace dans la timeline.

Module 13, Actions Rapides sur les Cartes Membres

Sur chaque carte de membre dans une demande :

  • Recommandation, un clic = email envoyé + log
  • Avancer dans le pipeline, directement depuis la carte
  • Boutons marketing, Découvrir Reciprok, etc.

Module 14, Notifications et Alertes

  • Push navigateur : nouvelle demande, réponse à requalif, dispo membre, événement passé
  • Alerte 48h : si aucune action sur une demande depuis 48h, alerte sur le dashboard
  • Post-événement : notification + propositions (email satisfaction, demande règlement commission)

Module 15, Calendrier des Événements

Vue globale des événements à venir basée sur les dates des demandes en cours/gagnées. Identifier les périodes chargées, repérer les événements non clôturés, anticiper les suivis.

Module 16, Commissions

Page de gestion globale

Configuration des règles de commission :

  • Taux par défaut
  • Taux différencié nouveau client vs client récurrent
  • Taux différencié premier referral vs referral récurrent
  • Override individuel par membre
  • Override individuel par demande

Vue d'ensemble :

  • Liste de toutes les commissions (en attente, facturées, payées)
  • Filtrage par membre, période, statut
  • Totaux : en attente / facturé / payé
  • Historique par membre

Actions :

  • Enregistrer une commission sur une demande gagnée
  • Envoyer l'email de facturation
  • Marquer comme payée
  • Voir le détail (demande, organisateur, membre, montant, taux appliqué + raison)

Module 17, Training de l'IA

Demandes fictives : l'IA génère des demandes réalistes, propose un catalogue, l'utilisateur corrige. Chaque correction est enregistrée comme donnée d'entraînement.

Comparaison historique : pour chaque nouvelle demande, l'IA cherche les demandes passées similaires et signale ("Cette demande ressemble à REQ-2025-0847, voici le catalogue proposé à l'époque").

Apprentissage continu : chaque correction utilisateur (chat, résultats, catalogue) alimente le modèle.

Module 18, Édition en Contexte

L'utilisateur ne quitte JAMAIS la page de demande pour corriger une fiche membre. Tout se fait via modales, panneaux latéraux, formulaires inline :

  • Ajouter une photo manquante
  • Compléter une fiche
  • Modifier les tags
  • Mettre à jour les disponibilités

C'est le principe le plus important pour le fondateur.

Module 19, Dashboard Principal

  • Demandes en cours par statut
  • Alertes d'inactivité (48h)
  • Calendrier événements à venir
  • Notifications non lues
  • Actions en attente (requalifs, dispos)
  • Statistiques (nombre de demandes, conversion, commissions en attente)

Module 20, Groupes

Membres regroupés en chaînes / groupes hôteliers. Nom, logo, liste de membres. Permet d'envoyer une demande à un groupe entier en un clic.

Les 20 Entités

#EntitéDescription
1MemberLieu/restaurant/prestataire (entité unifiée)
2RoomEspace/salle au sein d'un membre
3RoomCapacityCapacité d'une salle pour une configuration Kactus (réunion, U, théâtre, cabaret, école, banquet, cocktail)
4OrganizerClient cherchant un lieu
5RequestDemande d'événement (entité centrale)
6RequestDateDate(s) associée(s) à une demande
7RequestResultLien demande ↔ membre candidat (position, tier, score IA, statut pipeline)
8CatalogSélection finale envoyée à l'organisateur
9EmailThread / EmailCommunications structurées en fils
10TimelineEventHistorique structuré des actions sur une demande
11AiConversation / AiMessageChat IA lié à une demande
12KnowledgeEntryBase de connaissances alimentée par les membres
13RequestAvailabilityCheckRéponse de dispo par magic link (par request_result)
14TagClassification des membres
15GroupRegroupement de membres
16CommissionSuivi individuel d'une commission
17CommissionRuleRègles de calcul (taux par défaut, overrides)
18TrainingSessionSession d'entraînement IA (fictif + corrections)
19UserUtilisateur interne Reciprok
20NotificationNotifications push et alertes

Contraintes

  • Performance : recherche en quelques secondes sur 70 000+ membres (DB → sémantique → IA sur le top)
  • Traçabilité : aucune action sans trace, aucun email sans log timeline
  • Fluidité : ne jamais quitter la demande pour corriger une fiche
  • IA omniprésente : disponible à chaque étape, capable d'agir
  • Multi-canal : Email + WhatsApp + vocal + push, jumelables
  • Simplicité pour les membres : pas de calendrier, pas de formulaires interminables, langage naturel
  • Scalabilité : architecture qui supporte la croissance

On this page