IOSOR Знания

Таксуване на входящ MO срещу изходящ MT: двупосочни редове на портфейла на една prepaid книга

Отговорите, STOP и събитията на наетия номер дебитират. Ако финансите са моделирали само изходящо, книгата лъже. Двупосочен продукт трябва да вижда MO и MT в същия износ, с таван на авто-отговор.

Питчът говори за изходящо. В производство наетият номер приема отговори, STOP и понякога гласови връщания, и се появяват редове, които финансите не са писали в модела. Входящият MO не е безплатна учтивост. Двупосочен продукт движи MT и MO на същата prepaid книга. Ако износът брои само «изпратени», финансите третират входящия дебит като шум, докато ползването близо до USD 1,000+ го направи търговска тема.

IOSOR е white-label prepaid: изходящо и входящо на един ledger, client-safe грешки, без чужд портал за ежедневието. live е двупосочно производство; in setup не е евтина входяща кутия. Вижте гид за двупосочна входяща кутия и събития във входящата кутия на наети номера. Първо доказателство, после мащаб.

Дебити MO, които финансите не са планирали

Ако финансовият модел умножава само тарифата MT, липсват редове MO на наетия номер: входящи SMS, потвърждения на ключова дума, понякога гласови събития. Тези редове дебитират, когато пристигне отговорът, не в маркетинговия календар. Продуктът казва «двупосочни сме»; финансите питат «кой ред е входящ». Без отговор няма контрол.

Посока Какво вижда портфейлът Какво продуктът често пропуска
MT изходящо Единици / сегменти на изпращане Че входящото също дебитира
MO входящо Входящи единици + отговор на ключова дума Корелация с изходящата нишка
Авто-отговор Още един MT Таван на цикъл

MT срещу MO в същия износ

Сложете MT и MO в същия износ: време, номер, посока, дебит, correlation ID. Финансите трябва да филтрират по посока, не да смесват входящо в средна изходяща. STOP/HELP е ред за съответствие и може да дебитира. Животният цикъл на наетия номер се връзва към входящата кутия: освобождаването трябва чисто да отреже входящите събития, иначе следващия месец се появяват редове-призраци. Не позволявайте световна средна да скрие скъп входящ коридор.

Цикълът на авто-отговор изпразва портфейла

Авто-отговор без таван превръща едно MO в ред от MT, докато портфейлът се изпразни. Бот срещу бот, HELP цитиращ оригинала, неидемпотентни retry на webhook, смучат prepaid. Таван на отговори на нишка и STOP като незабавно потискане. Вижте цикли на входящ автоотговор. Когато политиката каже спри, портфейлът спира, дори продуктът да иска «да потвърди още веднъж». Проби от цикъла близо до USD 1,000+ влизат в търговския прочит, не в тикет в 02:00.

Събития на входящата кутия и корелация

Входящата кутия е доказателство, не играчка за чат. Всяко входящо събитие трябва да показва номер, времеви печат и безопасно затъмнено тяло, и да връзва към изходящ контекст, когато има нишка. Ops се нуждае от възпроизводима опашка мъртви писма, не да изсипва upstream payload към агенти. Без корелация финансите не обясняват дебита MO и продуктът не доказва, че двупосочното «работи». Наемите следват календарния месец UTC; собственикът на кутията трябва да знае кога изтича номерът.

Червени флагове

  • Финансов модел само с тарифа MT
  • Износ, който не различава посока
  • Авто-отговор без таван на нишка
  • STOP като бъбрене, без потискане
  • Агенти виждат сурови upstream payload
  • Освободен номер с още живи входящи дебити
  • Каталог in setup обещан като двупосочно производство

Започнете с IOSOR

Изпратете един входящ MO и един изходящ MT на същия нает DID. Експортирайте двата реда на портфейла и докажете различни кодове на причина. Сложете таван на авто-отговора, за да не сече входящото безграничен MT. Това е честност на двупосочни prepaid редове, не отчет за смес през седмицата на фактурата и не таван за съхранение на медия.

Обобщение IOSOR

MO и MT делят портфейл, не ред.

Правете: етикетирайте входящия debit отделно от изходящия. Не правете: да нетирате MO в MT или да криете входящи редове до края на месеца.

Полезно ли беше ръководството?

Свързани ръководства