Demandes de fonctionnalités

il serait intéressant de pouvoir ajuster la date de fin de caution (affichage sur la page du paiement) selon les conditions d'annulation de chacun. Actuellement la date est fixée au jour d'arrivée et cela peut poser souci dans le cas d'un défaut de paiement qui suivra l'annulation de la réservation, il sera difficile de relouer le jour même de l'annulation. Restant à votre disposition pour plusde détails. D. Bernardin

Lors d’un encaissement de caution, Swikly applique 5 % de frais. Pour des raisons légales, ces frais ne peuvent pas être facturés directement au locataire. En revanche, il serait très utile que l’interface calcule et affiche automatiquement le montant brut à encaisser nécessaire pour couvrir le montant net du dommage. Exemple : pour un dommage de 128,50 €, il faudrait encaisser 135,26 € afin de compenser les 5 % de frais (soit 6,76 €). Cela éviterait aux utilisateurs de refaire les calculs manuellement et permettrait de répercuter correctement le montant au locataire sans que Swikly soit responsable légalement.

Serait-il possible de voir si le client a souscrit l'assurance Swikly lors du dépôt de sa caution? Par avance, merci de voir si possible d'ajouter cette fonctionnalité Cordialement,

Avec mon saas je souhaite creer et envoyer automatiquement un lien de caution au locataire a la signature du contrat pour que le locataire mettent les fond et que le propriétairepuisse les retirer si la reservation est annuler moins d'un mois avant la datesd'entré

Depuis cette année , le nom et le prenom du client a disparu , pour moi utilisateur quotidien , c'est une perte de temps lorsqu'on ne se souvient pas si on fait l'appel ou pas .Seul le numero de téléphone ne nous indique pas assez de détails. merci

En cas de procédure de recouvrement, l’adresse postale du client est indispensable. Or, cette information n’est pas accessible dans le dashboard ni via les intégrations PMS. Suggestion : → Ajouter l’adresse postale du client dans : La fiche de dépôt de caution. Les exports ou API. L’intégration PMS, si disponible. Impact utilisateur : 📬 Donnée essentielle pour des cas légaux, de facturation ou de recouvrement.

Problème : Les statuts affichés ("accepté", "validé", "terminé", etc.) sont ambigus et parfois contradictoires, ce qui rend difficile le suivi des encaissements en cours ou terminés. Suggestion : → Repenser la nomenclature des statuts pour qu’ils reflètent clairement : L’état du mandat (accepté / refusé). L’état de l’encaissement (tenté / réussi / échoué / en attente). L’état du suivi (recouvrement engagé / clôturé, etc.). Impact utilisateur : 🧠 Moins d’ambiguïté = meilleure compréhension des actions à entreprendre.

Problème : L’interface actuelle ne permet pas de comprendre clairement ce qui s’est passé lors d’un encaissement. Statuts ambigus ("validé", "accepté", "terminé"), pas d’historique des tentatives, pas de détails sur les montants ni sur les raisons des échecs. Conséquences : UX confuse, sentiment d’instabilité. Augmentation des tickets au support. Difficulté à prendre les bonnes décisions rapidement (ex : relancer un client ou non). Suggestion : → Ajouter dans l’interface : Un historique détaillé des tentatives d’encaissement (montant, date, statut). Le nombre de tentatives et leur issue. Le motif de l’échec, si connu. Impact utilisateur : 🔎 Plus de transparence = meilleure autonomie + réduction du besoin d’assistance.

Problème : Actuellement, aucune notification n’est envoyée après une tentative d’encaissement de caution. Cela crée une incertitude pour les utilisateurs : on ne sait pas si le prélèvement a été effectué, échoué ou même tenté. Conséquences : Perte de temps à vérifier manuellement ou contacter le support. Risque de litiges ou de retard dans les relances. Baisse de confiance des partenaires (ex : propriétaires dans notre cas). Suggestion : → Envoyer automatiquement un email de confirmation : Lors d’un encaissement réussi, avec le montant, la date, et un lien vers la fiche de l’opération. Lors d’un encaissement échoué, avec le motif si disponible (plafond atteint, carte expirée, etc.). Impact utilisateur : 💡 Meilleure traçabilité = gain de temps, moins de stress, moins de recours au support.

pouvoir modifier la date du swik suite à une modification du sejour