IOSOR

IOSOR База знань

Списання inbound MO поруч із outbound MT: два напрямки в одному prepaid-гаманці

Відповідь, STOP і події орендованого номера теж списують. Модель лише на вихідному MT бреше. Двосторонній продукт бачить MO і MT в одному експорті й тримає стелю авто-відповіді.

На демо говорять про розсилку. Після запуску орендований номер починає приймати відповіді, STOP і інколи голосовий callback — і в гаманці з’являються рядки, яких не було в фінансовій моделі. Inbound MO не «безкоштовна ввічливість мережі». Двосторонній продукт рухає MT і MO по одному prepaid ledger. Якщо експорт уміє лише «надіслано», фінанси довго вважають вхідне списання шумом — доки usage біля USD 1 000+ не робить його темою комерційного розбору.

IOSOR — white-label prepaid: вихід і вхід на одному ledger, помилки без чужих брендів, без стороннього кабінету на щодень. live — двостороння production; in setup — не дешевший inbox. Див.

MO-списання, яких не було в моделі

Якщо фінанси лише множать тариф MT на обсяг розсилки, вони гублять рядки MO: вхідне SMS, підтвердження keyword, інколи голосові події на тому ж номері. Вони списуються в момент відповіді, не в день медіаплану. Продукт каже «ми двосторонні»; фінанси питають «який саме рядок — вхід». Без відповіді немає контролю.

Напрямок у спільному експорті

MT і MO мають жити в одному файлі: час, номер, direction, сума, correlation ID. Фінанси фільтрують за напрямком, а не ховають inbound у середнє outbound. STOP/HELP — рядок compliance і теж може дебетувати. Життя номера прив’язане до inbox: звільнення має чисто зупинити вхід, інакше наступного місяця з’являться «привиди». Світовий середній не повинен ховати дорогий inbound-коридор.

Петля авто-відповіді спустошує гаманець

Авто-відповідь без стелі перетворює одне MO на ланцюжок MT, доки баланс не нуль. Бот проти бота, HELP що цитує оригінал, неідемпотентні retry webhook — усе палить prepaid. Стеля відповідей на тред і STOP як миттєве глушіння. Див. цикли inbound auto-reply. Коли політика каже стоп, гаманець зупиняється, навіть якщо продукт хоче «ще раз підтвердити».

Inbox як доказ, не чат

Inbox — evidence. Кожна вхідна подія показує номер, час і безпечно скорочене тіло, і лінкує до outbound, якщо є тред. Ops потрібна черга dead-letter, яку можна програти знову, а не звалище чужого payload на агентів. Без кореляції фінанси не пояснять MO-дебет, продукт не доведе, що «двосторонність працює». Власник inbox знає, коли закінчується оренда. Агенти не бачать сирий іноземний текст помилки.

Червоні прапорці

  • Модель фінансів лише з тарифом MT
  • Експорт не вміє відрізнити напрямок
  • Авто-відповідь без стелі на тред
  • STOP як балачка, без глушіння
  • Агенти бачать сирий upstream payload
  • Номер звільнено, а inbound-дебети живі
  • Каталог in setup продано як двосторонню production

Старт з IOSOR

Надішліть один вхідний MO і один вихідний MT на одному орендованому DID. Експортуйте обидва рядки гаманця і доведіть різні коди причини. Поставте стелю auto-reply, щоб вхідне не карбувало безмежний MT. Це чесність двосторонніх prepaid-рядків, не звіт суміші на тижні рахунку і не стеля зберігання медіа.

Підсумок IOSOR

MO і MT ділять гаманець, не рядок.

Робіть: мітьте вхідний debit окремо від вихідного. Не робіть: неттити MO в MT або ховати вхідні рядки до кінця місяця.

Чи був матеріал корисним?

Пов’язані гіди