1. Какая методика посуточной тарификации лучше?

[rdc]

На данный момент я применяю первый вариант - но выглядит это несколько некрасиво. Например, при тарифе 500 рублей в месяц, если в текущем месяце 31 день, каждый день снимается 16 рублей 12 копеек, и за месяц будет снято 499 рублей 72 копейки.

А какой вариант считаете правильным вы?

[xpertiza]

используем LanBilling, снимает деньги посуточно равными долями в зависимости от дней в месяце, т.е. например в этом месяце (июнь, 30 дней) по тарифу за 400р снимаем в день 13.3р. Минус только в том, что испытываем батхерт в феврале, когда 28 дней, т.е. абон проплатил 5 января и ждет, что у него проработает до 5 февраля, а в феврале получается, что в сутки снимается не 13.3, а 14.28, и инет отключается 3его, например. В остальном это удобно и гибко.

[disappointed]

Тот вариант правильный, который не даст клиенту кинуть полтинник, попользовать пару дней и забить на неделю на инет.

[rdc]

Это от варианта не зависит, порог включения в размере абонентки решает проблему.

[disappointed]

"Порог включения" - это минимальный положительный остаток для работающей услуги?

Ну тогда это по логике почти тоже самое, что и у нас, 30-суточная подписка.

Тоже самое, только все ежедневные вычеты агрегированны в один. Который пролонгирует услугу на 30 суток.

[kapa]

Это от варианта не зависит, порог включения в размере абонентки решает проблему.

если проблемой считать получение от абонента денег, то да - частично решает :)

[rdc]

"Порог включения" - это минимальный положительный остаток для работающей услуги?

Речь про минимальный положительной остаток для разблокировки.

30-суточная подписка неудобна тем, что процедура смены тарифа или "заморозки" счёта до окончания 30 суток требует нетривиальных перерасчётов.

Изменено 11 июня, 2014 пользователем rdc

[pppoetest]

используем LanBilling, снимает деньги посуточно равными долями в зависимости от дней в месяце, т.е. например в этом месяце (июнь, 30 дней) по тарифу за 400р снимаем в день 13.3р. Минус только в том, что испытываем батхерт в феврале, когда 28 дней, т.е. абон проплатил 5 января и ждет, что у него проработает до 5 февраля, а в феврале получается, что в сутки снимается не 13.3, а 14.28, и инет отключается 3его, например. В остальном это удобно и гибко.

Аналогично, только биллинг свой.

[ChargeSet]

посуточный тариф = месячный тариф/28. Иначе какой смысл? Мне кажется, с ростом единовременно проплачиваемоего периода стоимость одного дня должна падать, т.е. напр. при линейке "посуточно", "понедельно", "помесячно", "поквартально", и "по полгода" удельная стоимость одного дня должна падать. У прова, к которому я подключен, как раз примерно так. Разлет в ценах: 70р/день, 1350р/месяц и 4000р/четыре месяца. Мне это кажется нормальным. Метод оплаты авансовый

[kosmich7]

каждый день снимается 16 рублей 12 копеек,

А какой вариант считаете правильным вы?

Не считаю правильным посуточную абонплату, считаю правильным резервировать сумму абонплаты на счету абонента и списывать ее в конце месяца.

Людей много, мнений тоже, вот есть и такие примеры тарификации.

Например тариф 16 рублей/сутки, не привязан к календарному месяцу, есть деньги на счету - есть инет :)

Нет 16 рублей на счету - нет инета :)

[YuryD]

Например тариф 16 рублей/сутки, не привязан к календарному месяцу, есть деньги на счету - есть инет :)

Нет 16 рублей на счету - нет инета :)

 

Как сутки-то считать ? Работал-не работал ? А если не работал - списывать абонплату или нет ? Этак и до посекундной тарификации докатиться можно :)

[vop]

Почему-то никто не применяет соверешнно нормальный способ блокировки при начислении оплаты работы. В течении месяца клиент получает услуги, примерная стоимость которых блокируется на счет абонента. А в конце месяца происходит просто тарифное начисление. Это избавляет от необходимости приводит миллионтысячные доли стоимости одного дня, и дает точно начисление по итогам месяца.

 

Как сутки-то считать ? Работал-не работал ? А если не работал - списывать абонплату или нет ? Этак и до посекундной тарификации докатиться можно :)

 

Вроде вопрос стоял о суточном начислении помесячных тарифов, а не суточных. С суточными вообще просто: подключился - пользовался - начисляем. Не подключился - не начисляем. Другого смысла в посуточном тарифе нет, кроме, как экономии за счет неработы.

 

30-суточная подписка неудобна тем, что процедура смены тарифа или "заморозки" счёта до окончания 30 суток требует нетривиальных перерасчётов.

 

А зачем тогда железка компьютерная? Пусть считает и перерасчитывает. :)

[terrible]

Мы сначала снимаем за неделю, потом, если у абонента есть бабло на счету - посекундно (с момента появления активности), до наступления окончания списания, т.е. 3 дня подряд отсутствия активности. Далее, если он опять проявляет сетевую активность - списываем неделю и по новой. Абонентам очень нравятся расчёты до копеек и секунд :)

[rdc]

А зачем тогда железка компьютерная? Пусть считает и перерасчитывает. :)

Дело не в железке. Потом КРАЙНЕ трудно объяснить абоненту, что там понаперерассчитано.

А что делает абонент, который не понимает, как работает биллинг? Правильно, идёт строчить в интернетах о том, что провайдер ворует!

Одно из главных требований к методике тарификации - она должна быть предельно прозрачна для абонента.

В течении месяца клиент получает услуги, примерная стоимость которых блокируется на счет абонента. А в конце месяца происходит просто тарифное начисление.

А зачем такая двухходовка? Начислять сразу не?

[kapa]

Мы сначала снимаем за неделю, потом, если у абонента есть бабло на счету - посекундно (с момента появления активности), до наступления окончания списания, т.е. 3 дня подряд отсутствия активности. Далее, если он опять проявляет сетевую активность - списываем неделю и по новой. Абонентам очень нравятся расчёты до копеек и секунд :)

У абонентов мозг не взрывается?

[disappointed]

Дело не в железке. Потом КРАЙНЕ трудно объяснить абоненту, что там понаперерассчитано.

А что делает абонент, который не понимает, как работает биллинг? Правильно, идёт строчить в интернетах о том, что провайдер ворует!

Одно из главных требований к методике тарификации - она должна быть предельно прозрачна для абонента.

 

В том и фишка, что оно предельно прозрачно получается.

Проблем вообще нет, в отличии от конкурентов с их непонятно какой логикой.

 

К примеру, в любой момент клиент может прийти и расторгнутся, при этом на его счет возвращается сумма за невыработанный период времени,

расчитанная одним кликом менеджера.

Немедленная смена тарифа в офисе идёт точно по такой же схеме, т.е. возврат за невыработанный период по старому тарифу, смена на новый тариф и попытка продлиться по нему, если хватит средств.

Отложенная смена делается самостоятельно из ЛК, если операция производится в фазе блокировки то смена происходит сразу,

если же внутри уже идущего 30 сут. периода, то откладывается на дату его окончания, о чём в понятной форме клиенту показывается сообщение,

отменить эту запланированную смену можно также в любое время до момента её исполнения.

Когда день-час-минута Х наступает, клиент получает смс с уведомлением, что его запрос выполнен и тариф изменён.

[YuryD]

Просто вспоминаю идиллию в расчетах диалап. Сумма на счету трансформировалась в секунды и выдавалась атрибутом session timeout. И всё - в долг не залезешь. По стопу сессии - корректировка суммы на счету. И никаких привязок к расчётному периоду. И всё прозрачно и ненапряженно для биллинга.

[dk_]

Как разработчик биллинга имел дело с десятками операторов и повидал всякое. Делюсь опытом.

 

Если исходить из выгоды для оператора (а из чего еще?), то, конечно, лучше вообще не использовать посуточную тарификацию, а требовать полную предоплату за целый расчетный период. При этом желательно требовать с абонента оплату за тот период, в течение которого он был заблокирован за неуплату. (Не уверен, что это полностью законно, но несколько наших клиентов так делают и чувствуют себя прекрасно.)

 

Если конкурентная ситуация не позволяет такую схему, то оптимальный вариант «В последний день месяца снимать чуть бОльшую сумму, чтобы за месяц набежала ровно заявленная». При этом заключительный «хвостик» можно сделать и чуть меньше — для этого сумма ежедневного списания округляется не вниз, а вверх.

 

Вариант с раскидыванием недостающих/лишних копеек по дням имеет право на жизнь, но сложнее в программировании (читай «больше багов»), и в понимании при разборе конфликтных ситуаций.

 

Вариант с прощением абоненту копеек выглядит для него же нелогичным и нервирует его — если человек подписался платить 500 рублей в месяц, то почему у него все время какой-то цирк на лицевом счете творится: то 499,70, то 499,92, то вообще 500,03. Это прямой путь к потере абонента. Самое ужасное, если программисты оказались криворукими и сумма списания превышает заявленную, пусть и всего на несколько копеек.

 

Вести баланс в долях копейки — верный путь к провалу. Обычно разработчики, выбирающие такой вариант, к тому же ничего не понимают ни в финансовых расчетах, ни в устройстве ЭВМ, и используют для хранения и обработки денежных величин стандартные двоичные типы данных с плавающей точкой. В результате накапливаются ошибки округления, которые при определенном стечении обстоятельств приводят к массовому недоверию и оттоку абонентов.

 

Снимать деньги с лицевого счета непрерывно — создает большую нагрузку на биллинг и непонятно, как абоненту показывать детализацию по платежам и списаниям. Каждую копейку отдельно отражать? Или агрегировать посуточно? Если агрегировать, то зачем тогда вообще эту схему городить? Аргумент об упрощении перерасчетов несостоятелен — ничто не мешает выполнять корректировку баланса и истории прямо в момент перерасчета. А про то, что абоненту удобнее в любой момент прийти и расторгнуть договор — просто смешно: неужели у вас основная идея при разработке биллинга — дать абоненту удобно от вас отключиться?

 

Если делаете такую схему, нужно иметь в виду:

— Ежесуточное списание при реализации «в лоб» приводит к снижению ARPU на 3-7% из-за того, что абонент забывает вовремя заплатить и его отключает за неуплату, а пока он донесет свое тело до терминала, может пройти несколько дней. Поэтому мы своим клиентам при переходе на ежесуточное списание рекомендуем настроить SMS-уведомление абонента, которое начинает бомбить его напоминалками за несколько дней для отключения.

— Можно поставить расчетный период 30 дней, тогда абонент дополнительно заплатит за 5 дней в году, но у него будет постоянно меняться расчетный день.

 

Кроме того, мы делали (и операторы ими активно пользуются) следующие механизмы возврата ARPU на нормальный уровень:

— Требование оплатить целый месяц после блокировки за неуплату.

— При наличии на лицевом счете полной суммы за месяц снимать ее целиком, и только если на полное списание денег не хватает, то списывать по дням.

[kapa]

Если делаете такую схему, нужно иметь в виду:

— Ежесуточное списание при реализации «в лоб» приводит к снижению ARPU на 3-7% из-за того, что абонент забывает вовремя заплатить и его отключает за неуплату, а пока он донесет свое тело до терминала, может пройти несколько дней. Поэтому мы своим клиентам при переходе на ежесуточное списание рекомендуем настроить SMS-уведомление абонента, которое начинает бомбить его напоминалками за несколько дней для отключения.

— Можно поставить расчетный период 30 дней, тогда абонент дополнительно заплатит за 5 дней в году, но у него будет постоянно меняться расчетный день.

Кому нужен "расчётный день" при посуточном списании? У вас когда расчётный день на мобилке?

 

Кроме того, мы делали (и операторы ими активно пользуются) следующие механизмы возврата ARPU на нормальный уровень:

— Требование оплатить целый месяц после блокировки за неуплату.

Шикарная тема!

Тем, у кого сейчас сразу 500р нет, 100р не принимать - ждать пока накопит. Сильно ARPU повысили?

[YuryD]

Я предложил идею поминутной тарификации безлимита своим начальникам. Они повертели пальцем у виска - типа впал в маразм и вспомнил золотое детство диалапа.. А идея-то проста, как яйцо. 1 минута безлимита со скоростью NMbit стоит одну копейку, или две, или три. Абонплаты нет, есть деньги на счету - работай, нету - беги закинуть на счёт еще рубликов 50, и никаких пересчётов и первых чисел. В чём подвох - ну посчитайте сами :) Качальщики сразу поймут, что такая штука выйдет им гораздо дороже, и попробовав - вернутся на помесячную. Зато какой маркетинговый ход, народ летнедачный сразу потянется к "ясновидимой" экономии :) Идею столблю за собой, "поминутная оплата безлимита без абонентской платы". А чтобы хитрые пользователи не могли точно просчитать, в чем же их обманывают - скорости безлимита не должны соответствовать скоростям "поминутного безлимита". ARPU я думаю упадёт несильно, а клиенты - да запросто...

[vop]

А зачем тогда железка компьютерная? Пусть считает и перерасчитывает. :)

Дело не в железке. Потом КРАЙНЕ трудно объяснить абоненту, что там понаперерассчитано.

А что делает абонент, который не понимает, как работает биллинг? Правильно, идёт строчить в интернетах о том, что провайдер ворует!

Одно из главных требований к методике тарификации - она должна быть предельно прозрачна для абонента.

 

Это уже, наверно, вопрос к оформлению отчета. Типа:

5 дней по тарифу No 5 - 50 рублей.

15 дней по тарифу No 7 - 90 рублей.

10 дней по тарифу No 2 - 150 рулей.

 

Ну или как-то так.

 

В течении месяца клиент получает услуги, примерная стоимость которых блокируется на счет абонента. А в конце месяца происходит просто тарифное начисление.

А зачем такая двухходовка? Начислять сразу не?

 

Текущее начисление требует определения ежедневной точной и окончательной суммы начисления. Начисление в виде 16.2495342 руб. в платежной истории выглядит очень коряво и бестолково. Ну и в итоге, приводит к неточному итогу в конце месяца, когда по тарифу 150 рублей, а в платежной истории получается 150.763424. И вопрос не в деньгах, а в том, что "биллинг даже простые числа неправильно считает" (т.е. кпитальная потеря доверия к такой системе).

 

В случае с блокировкиой получается, что блокируется "примерная" сумма. Пограшность примерности равна пол копейки. В результате с одной стороны мы имеем кошелёк с ежемесячными начислениями и платежами с его балансом, а с другой стороны набор услуг с текущими затратами, округленными до одной копейки. Примерно, 1-го числа абонент видит: "абонплата за 1 день - 15.12", а 10-го числа он видит: "абонплата за 10 дней - 151.24". А в конце месяца ему начислется совершенно точненько 450 рубчиков, как и прописано в тарифе.

 

Ну а решение по работе принимаем не по остатку на текущем счету, а по сумме этого остатка и текущей блокировки.

Изменено 17 июня, 2014 пользователем vop

[vop]

Как разработчик биллинга имел дело с десятками операторов и повидал всякое. Делюсь опытом.

 

Приходилось реализовывать даже совершенно нелогичные и странные ребования заказчика. :) О багах предупреждаешь заранее - не верят. Через пол года намаявшись, приходят к нормальному решению.

 

Вести баланс в долях копейки — верный путь к провалу. Обычно разработчики, выбирающие такой вариант, к тому же ничего не понимают ни в финансовых расчетах, ни в устройстве ЭВМ, и используют для хранения и обработки денежных величин стандартные двоичные типы данных с плавающей точкой. В результате накапливаются ошибки округления, которые при определенном стечении обстоятельств приводят к массовому недоверию и оттоку абонентов.

 

Тоже всегда удивляла фишка в некоторых биллингах считать целочисленные величины (которыми являются и копейки, и байты и секунды) плавающей арифметикой. :)

 

Кроме того, мы делали (и операторы ими активно пользуются) следующие механизмы возврата ARPU на нормальный уровень:

— Требование оплатить целый месяц после блокировки за неуплату.

— При наличии на лицевом счете полной суммы за месяц снимать ее целиком, и только если на полное списание денег не хватает, то списывать по дням.

 

Есть два варианта ограничения работы должников - с прекращением взимания абонплаты, и с обычным начислеием полной (или частичной) абонеплаты. Если у заблокированного абонента оплата продолжает начисляться - тогда разблокируем по положительному балансу (забежал к терминалу, добавил 20 рублей - работаем еще день). Если во время блокировки абонплата не начисляется (часто это называют "заморозкой"), то разблокировку разумнее делать по внесению полной месячной оплаты.

Изменено 17 июня, 2014 пользователем vop

[Andrei]

используем LanBilling, снимает деньги посуточно равными долями в зависимости от дней в месяце, т.е. например в этом месяце (июнь, 30 дней) по тарифу за 400р снимаем в день 13.3р. Минус только в том, что испытываем батхерт в феврале, когда 28 дней, т.е. абон проплатил 5 января и ждет, что у него проработает до 5 февраля, а в феврале получается, что в сутки снимается не 13.3, а 14.28, и инет отключается 3его, например. В остальном это удобно и гибко.

+1. Тоже используем ЛБ с такой же логикой.

В дополнение - обещанный платеж со сроком погашения 3 дня и возможность оплатить Visa, YandexMoney, SMS с любого оператора. Чтобы не сильно ронять ARPU установили минимальный платеж 100 руб. Все довольны, жалоб/оттока абонентов по этим причинам нет, прозрачность расчетов (все платежи и списания видно в личном кабинете).

[20512]

SMS с любого оператора

А это как?

В двух словах, если можно.

 

Тоже смотрю в сторону Ланбилинга, ибо УТМ уже задрал...

[Andrei]

SMS с любого оператора

А это как?

В двух словах, если можно.

 

Тоже смотрю в сторону Ланбилинга, ибо УТМ уже задрал...

Используем для этого сервиса neoline.biz

Для абонента это выглядит как ввод данных в форму на сайте (вводится логин учетки из ЛБ, сумма и номер сотового телефона), потом абоненту приходит СМС, в ответ на которое надо отправить подтверждение, после чего деньги списываются с сотового и зачисляются на лицевой счет абонента в ЛБ.

Комиссию правда они подняли в последнее время

Есть еще unionplat.ru - там и СМС-ками, и visa, и YM.