Leads, support et retours
Opportunités commerciales, demandes de support et retours affluent dans trois boîtes de réception distinctes, jamais une seule où tout le monde fouille, chacune verrouillée par sa propre permission et gardant la trace de qui a lu quoi, et quand.
Chacun résout une étape différente pour faire parvenir un message à la bonne personne, sous la bonne forme.
leads.view et support.view sont accordées indépendamment, si bien qu'un commercial ne voit jamais de tickets de support par accident, et vice-versa, même si les deux passent par exactement le même pipeline sous-jacent.
Un message exige toujours un nom et au moins un e-mail ou un téléphone, mais les champs supplémentaires portent tout ce qu'une organisation souhaite demander en plus, taille du groupe, produit d'intérêt, source de la campagne, sans jamais nécessiter de changement de schéma.
Chaque boîte affiche directement dans la navigation d'administration le nombre d'entrées encore non lues, et la recherche fouille jusque dans le corps du message et chaque champ personnalisé, pas seulement le nom et les coordonnées.
L'export CSV respecte la recherche ou le filtre actif et conserve les champs personnalisés intacts dans une seule colonne JSON, si bien que le format reste stable même quand les formulaires d'une organisation continuent d'évoluer.
Le chat de la vitrine vérifie les vraies données produit et commande avant de dire quoi que ce soit, jamais une supposition, et passe la conversation à une personne dès qu’il tombe sur une question à laquelle il ne peut vraiment pas répondre seul.
Ventes, leads, support et retours s’acheminent chacun vers leur propre canal Slack si une organisation en connecte un, avec un bouton qui ramène directement à l’entrée exacte, si bien que personne n’a besoin de garder la boîte ouverte pour remarquer une nouveauté.
Cinq étapes, depuis la soumission d'un formulaire jusqu'au moment où quelqu'un dans l'équipe agit dessus.
Leads, demandes de support et retours passent chacun par leur propre point d'accès, partageant la même validation et la même isolation par organisation, mais sans jamais se mélanger dans une boîte générique.
La réponse confirme la réception avec une référence opaque et un horodatage, et ne renvoie jamais, volontairement, le nom, l'e-mail ou le message qui viennent d'être soumis.
Le type indiqué sur la soumission, vente, support ou retour, l'achemine directement vers sa boîte correspondante et sa permission correspondante, sans aucune étape de tri manuel pour qui que ce soit.
La première fois que quelqu'un ouvre une entrée, ce moment et cette personne sont enregistrés automatiquement, si bien qu'une équipe sait toujours ce qui a réellement été consulté.
Remarquer une entrée comme non lue est une action normale et prise en charge, pour la confier à quelqu'un d'autre ou la signaler à revoir plus tard, pas un cas limite que l'interface combat.
Un nom, un e-mail ou un téléphone, un message optionnel, et des champs supplémentaires définis entièrement par l'organisation. La réponse confirme la réception sans jamais renvoyer d'information personnelle.
{
"request": {
"name": "Marco Belli",
"email": "[email protected]",
"message": "Interested in a group booking for October",
"extra_fields": {
"group_size": 24,
"product_of_interest": "city-food-tour"
}
},
"response": {
"data": {
"reference": "01J8X8QK6Z9K2R3W4M5N6P7Q8R",
"type": "sales",
"received_at": "2026-08-14T18:15:00Z"
}
}
}Les champs supplémentaires acceptent jusqu'à 50 clés de premier niveau, 16 niveaux d'imbrication et 64 Ko de JSON, si bien qu'un formulaire demandant la taille du groupe aujourd'hui peut se mettre à demander une langue préférée le mois prochain, sans que personne ne touche à la base de données. Ces limites existent pour qu'une intégration trop zélée ne puisse pas transformer discrètement une soumission de lead en envoi sans limite.
Non. leads.view et support.view sont deux permissions distinctes pour deux boîtes distinctes. Un rôle peut recevoir l'une, les deux, ou aucune, et il n'existe aucune vue « contacts » partagée où elles se mélangeraient.
Oui, via les champs supplémentaires, un objet JSON qu'une organisation définit librement, jusqu'à 50 champs, sans jamais nécessiter de changement dans la base de données elle-même.
Une référence opaque, ainsi que le type et l'horodatage de sa soumission, rien de plus. Son propre nom, e-mail ou message ne sont jamais renvoyés dans la réponse.
Non. Ils s'exportent dans une seule colonne JSON, si bien que le fichier garde un format stable et prévisible même quand les formulaires et les questions d'une organisation continuent d'évoluer.
Non, c'est une action tout à fait normale, destinée à confier une entrée à quelqu'un d'autre dans l'équipe ou à la signaler pour y revenir, pas quelque chose que le système traite comme inhabituel.
Dans une limite fixée par l’organisation, oui, et seulement après que le visiteur a confirmé son propre e-mail. Au-delà de cette limite, ou pour tout ce dont il n’est pas sûr, la main est passée à une personne plutôt que de deviner.
Non. Slack est entièrement optionnel. Connectez-le et choisissez lequel des neuf types de notification atterrit dans quel canal ; laissez-le déconnecté et les trois boîtes fonctionnent exactement pareil depuis le tableau de bord.
Tiqory garde disponibilité, tarifs, paiements et accès parfaitement synchronisés à mesure que votre activité grandit. Dites-nous où vous allez ; nous vous montrons comment y arriver sans repartir de zéro.