IOSOR

IOSOR Guides

Facturation MO inbound contre MT outbound : lignes de portefeuille bidirectionnelles sur un même ledger prepaid

Réponses, STOP et événements de numéro loué débitent. Si la finance n’a modélisé que l’outbound, le ledger ment. Un produit bidirectionnel doit voir MO et MT dans le même export, avec plafond d’auto-réponse.

Le pitch parle d’outbound. En production le numéro loué reçoit des réponses, STOP et parfois des rappels vocaux, et des lignes apparaissent que la finance n’a pas mises dans le modèle. Le MO inbound n’est pas une politesse gratuite. Un produit bidirectionnel fait circuler MT et MO sur le même ledger prepaid. Si l’export ne compte que les « envoyés », la finance traite le débit inbound comme du bruit jusqu’à ce que l’usage vers USD 1,000+ en fasse un sujet commercial.

IOSOR est prepaid white-label : outbound et inbound sur un ledger, erreurs client-safe, pas de portail tiers au quotidien. live est la production bidirectionnelle ; in setup n’est pas une inbox bon marché.

Débits MO que la finance n’avait pas prévus

Si le modèle financier ne multiplie que le tarif MT, il omet les lignes MO du numéro loué : SMS inbound, accusés de mot-clé, parfois événements vocaux. Ces lignes débitent à l’arrivée de la réponse, pas sur le calendrier marketing. Le produit dit « nous sommes bidirectionnels » ; la finance demande « quelle ligne est inbound ». Sans réponse, pas de contrôle.

MT versus MO dans le même export

Mettez MT et MO dans le même export : temps, numéro, sens, débit, correlation ID. La finance doit filtrer par sens, pas noyer l’inbound dans une moyenne outbound. STOP/HELP est une ligne de conformité et peut aussi débiter. Le cycle de vie du numéro loué est lié à l’inbox : libérer le numéro doit couper les événements inbound, sinon des lignes fantômes apparaissent le mois suivant.

La boucle d’auto-réponse vide le portefeuille

Une auto-réponse sans plafond transforme un MO en une file de MT jusqu’à vider le portefeuille. Bot contre bot, HELP qui cite l’original, retries webhook non idempotents, drainent le prepaid. Plafond de réponses par fil et STOP comme suppression immédiate. Voir boucles d’auto-réponse inbound.

Événements d’inbox et corrélation

L’inbox est une preuve, pas un jouet de chat. Chaque événement inbound doit montrer numéro, horodatage et corps expurgé en sécurité, et lier au contexte outbound s’il y a un fil. Ops a besoin d’une file morte rejouable, pas de déverser des payloads amont aux agents. Sans corrélation, la finance n’explique pas le débit MO et le produit ne prouve pas que le bidirectionnel « marche ».

Signaux d’alerte

  • Modèle financier au seul tarif MT
  • Export qui ne distingue pas le sens
  • Auto-réponse sans plafond par fil
  • STOP traité comme du bavardage, sans suppression
  • Agents voyant des payloads amont bruts
  • Numéro libéré avec débits inbound encore vivants
  • Catalogue in setup promis comme production bidirectionnelle

Commencer avec IOSOR

Envoyez un MO entrant et un MT sortant sur le même DID loué. Exportez les deux lignes de portefeuille et prouvez des codes motif distincts. Plafonnez l’auto-réponse pour qu’un inbound ne frappe pas du MT sans borne. C’est l’honnêteté des lignes prepaid à deux sens, pas un rapport de mélange de semaine de facture ni un plafond de stockage média.

À retenir — IOSOR

MO et MT partagent un portefeuille, pas une ligne.

Faites : étiquetez le débit entrant à part du sortant. Ne faites pas : netter le MO dans le MT ni cacher les lignes entrantes jusqu’à fin de mois.

Ce guide vous a-t-il aidé ?

Guides associés