Добрый день, уважаемые. Мы набросали небольшое техзадание по указанным в заголовке проблемам, хотелось бы услышать ваше мнение. Предложения и пожелания приветствуются.
Акции и скидки в UTM5
Функционал акций, скидок и бонусов постоянно обсуждается клиентами компании и реализуется посредством костылей, не всегда корректных с точки зрения биллинга. Необходимо проработать штатные механизмы, которые устроили бы большинство операторов.
Акции
Акция предполагает особые условия оказания услуг абонентам в течение ограниченного периода времени. В рамках бизнес-логики UTM5 наиболее удобным видится реализация акции в виде специального тарифного плана, действующего в течение заданного периода времени, с последующей сменой на "обычный" тарифный план.
Функциональные изменения
* добавить вкладку "Акция" в свойствах тарифного плана
* добавить кнопку копирования тарифных планов в интерфейсе администратора (аналогично для услуг)
* добавить статистику количества подключений тарифного плана в его свойствах (аналогично для услуг)
На вкладке "Акция" в свойствах тарифного плана необходимо добавить возможность указать следующие свойства:
* срок действия акции в сутках с момента подключения, либо в расчетных периодах (включая период, в котором произошло подключение тарифного плана-акции)
* тарифный план, который будет подключен после тарифного плана-акции
Указанные выше свойства не могут быть указаны по отдельности
Скидки
Скидки позволяют изменить (в сторону уменьшения либо увеличения) количество средств, списываемых по сервисным связкам периодических услуг. В настоящее время функционал реализован в виде коэффициента, указываемого в свойствах сервисной связки, однако фактически этот коэффициент действует на момент последнего списания средств в расчетном периоде.
Функциональные изменения
* реализовать учет времени действия коэффициента списаний по периодическим сервисным связкам
* реализовать ведение истории изменения коэффициента списаний в виде кнопки в свойствах сервисной связки
Пример: коэффициент 1/2 действовал в течение 1/3 расчетного периода, прочие перерасчеты абонентской платы отсутствовали, сумма списаний по сервисной связке должна составить 1/2 * 1/3 * cost + (1 - 1/3) * cost = (1/6 + 2/3) * cost = 5*cost/6
Бонусы
Бонус предполагает разовое увеличение баланса абонента, отображаемое в отдельной колонке общего отчета, не влияющее на бухгалтерскую отчетность (бонус не должен являться платежом, по возможности не влиять на счета и прочие документы) Бонус должен иметь опциональную возможность указания даты его сгорания (списания средств в объеме, не превышающем текущий баланс абонента на момент сгорания бонуса)
Функциональные изменения
* добавить новый тип списания "Бонус", отображаемый в отдельной колонке общего отчета
* добавить таблицу базы данных, содержащую описание бонуса, дату сгорания, ID системного пользователя, внесшего бонус (список будет уточнен в процессе реализации)
* реализовать отчет по таблице бонусов
* реализовать ведение в системе набора условий автоматического внесения бонусов
* реализовать возможность ручного внесения бонуса на лицевой счет абонента
Условия автоматического внесения бонусов
* сумма платежа превышает N - фиксированный бонус в размере В
* сумма платежа превышает N - бонус в размере В = N*coef
* подключение тарифного плана - бонус в размере B
Предварительно, озвученный функционал должен быть представлен в версии 5.3-004-beta к 01.01.2016
Скидки, акции, бонусы в UTM5
Начнем с самого простого, с бонусов.Бонусы
Бонус предполагает разовое увеличение баланса абонента, отображаемое в отдельной колонке общего отчета, не влияющее на бухгалтерскую отчетность (бонус не должен являться платежом, по возможности не влиять на счета и прочие документы) Бонус должен иметь опциональную возможность указания даты его сгорания (списания средств в объеме, не превышающем текущий баланс абонента на момент сгорания бонуса)
Функциональные изменения
* добавить новый тип списания "Бонус", отображаемый в отдельной колонке общего отчета
* добавить таблицу базы данных, содержащую описание бонуса, дату сгорания, ID системного пользователя, внесшего бонус (список будет уточнен в процессе реализации)
* реализовать отчет по таблице бонусов
* реализовать ведение в системе набора условий автоматического внесения бонусов
* реализовать возможность ручного внесения бонуса на лицевой счет абонента
Условия автоматического внесения бонусов
* сумма платежа превышает N - фиксированный бонус в размере В
* сумма платежа превышает N - бонус в размере В = N*coef
* подключение тарифного плана - бонус в размере B
Если рассматривать бонусы как метод корректировки баланса, то получается что мы искусственно увеличиваем кредиторскую задолженность, предлагаю бонусы изначально учитывать как некие баллы, которыми пользователь в определенное время может рассчитаться за услуги, т.е. в момент исполнения какого либо события абоненту на бонусный счет начисляются баллы, в дальнейшем в любой момент времени абонент может перевести их к себе на счет, при этом необходимо иметь у сотрудников возможность ручного погашения бонусов.
Бонусный счет - это не счетчик баллов, это таблица транзакций, у каждой транзакции указано время активации и время сгорания, первоначальная сумма, и оставшаяся сумма транзакции, и при оплате бонусами гасить транзакции начиная с самой старой которые уже наступили но еще целиком не выбраны и еще не сгорели.
Условия расчета бонуса и времени его окончания я предлагаю оставить на совести администратора, а событие отрабатывать через RFW, это будет самый гибкий вариант. Для этого нам требуется доработать RFW - добавить реакции на:
- появление записи в user_log,
- подключение/отключение услуги
- закрытие расчетного периода у пользователя.
- изменение ТП у пользователя
Ручное внесение бонуса - вносим бонус с указанием времени сгорания, если не указано то бессрочно.
Может еще стоит рассмотреть возможность внесения бонусов (в том числе и ручное) с будущей датой, тогда бонус начнет учитываться допустим через год, пригодится для таких акций как: "Вернем через год стоимость подключения"
Все вышеописанное позволит:
- Вносить бонусы в ручном режиме с указанием даты активации бонуса и даты сгорания.
- Учитывать бонусы не как число , а как сумму остатков на уже наступивших, не отмененных, и не сгоревших бонусных транзакций, из которых состоит сумма сонусного счета.
- Начислять бонусы автоматически и гибко рассчитывать сумму бонуса, в зависимости от неограниченного количества условий (группы пользователя, его ТП, признака Ю/Л, текущего баланса, факта изменения например учетной записи пользователя (например акция "Актуализируй контакты и получи бонус"), наличие блокировки, суммы платежа, типа платежа, исполнителя платежа, текущий кредит, придумать свои события внося в юзерлог собственные события, итп, т.е. по если добавить указанные события RFW администратор сможет описать абсолютно все и навешать на любые события в биллинге.
Теперь о скидках:Скидки
Скидки позволяют изменить (в сторону уменьшения либо увеличения) количество средств, списываемых по сервисным связкам периодических услуг. В настоящее время функционал реализован в виде коэффициента, указываемого в свойствах сервисной связки, однако фактически этот коэффициент действует на момент последнего списания средств в расчетном периоде.
Функциональные изменения
* реализовать учет времени действия коэффициента списаний по периодическим сервисным связкам
* реализовать ведение истории изменения коэффициента списаний в виде кнопки в свойствах сервисной связки
Пример: коэффициент 1/2 действовал в течение 1/3 расчетного периода, прочие перерасчеты абонентской платы отсутствовали, сумма списаний по сервисной связке должна составить 1/2 * 1/3 * cost + (1 - 1/3) * cost = (1/6 + 2/3) * cost = 5*cost/6
Когда костылил скидки на основе коэффициентов в текущей реализации столкнулся с некоторыми проблемами:
- Отстутствие учета времени действия коэффициента
- Невозможно задать время начала и окончания действия коэффициента, это очень необходимо когда дается скидка с начала следующего расчетного периода.
В случае горячей смены ТП у услуг входящих в него меняется ID сервисной связки, так как я веду учет в отдельной таблице, то терял ID сервисной связки к которой привязана скидка и ее размер, выкрутился с помошью техпараметров, так как в момент горячей смены ТП они перепривязываются к новому ID сервисной связки. Поэтому большая просьба добавить в таблицу сервисных связкой идентификатор связки на которую перешла завершенная связка в момент смены ТП.
Так как не на все услуги разрешено ставить скидки, необходим признак того что на эту услугу можно ставить скидку.
Скидка может быть не только в процентном отношении, но и в виде фиксированной стоимости услуги, и в виде фиксированной суммы скидки.
Очень не хватает поле комментария в свойствах сервисной связки для того чтобы описать причину скидки.
Очень не хватает скидки на услуг телефонии, т.е. я не могу для конкретных абонентов сделать какое нибудь направление дешевле чем задано в свойствах ТП, приходится плодить ТП.
Re: Скидки, акции, бонусы в UTM5
По акциям, вышеописанный подход не устраивает абсолютно, так как не учитывает дополнительную бизнес логику оператора. У меня сейчас так и делается, под каждую акцию создаю ТП, указываю у него срок окончания (конкретная дата или дни), на какой ТП перейти по завершению (предыдущий или конкретный), указываю можно ли его менять пользователю самостоятельно, потом в куче урфа скриптах прописываю логику для этого тарифа, так как еще есть понятие пакетные тп, прописываю логику в скрипте который контролирует что и на что менять если пользователь отказался от одной из услуг. Вообщем у меня сейчас 300 акционных ТП, из них мне требуется не больше десятка. На создание очередного акционного предложения из пары тройки ТП, я трачу целый день, удалить ТП я в большинстве случаев не могу, так как на них остаются абоненты подключенные не вовремя.serjk писал(а):Акции
Акция предполагает особые условия оказания услуг абонентам в течение ограниченного периода времени. В рамках бизнес-логики UTM5 наиболее удобным видится реализация акции в виде специального тарифного плана, действующего в течение заданного периода времени, с последующей сменой на "обычный" тарифный план.
Функциональные изменения
* добавить вкладку "Акция" в свойствах тарифного плана
* добавить кнопку копирования тарифных планов в интерфейсе администратора (аналогично для услуг)
* добавить статистику количества подключений тарифного плана в его свойствах (аналогично для услуг)
На вкладке "Акция" в свойствах тарифного плана необходимо добавить возможность указать следующие свойства:
* срок действия акции в сутках с момента подключения, либо в расчетных периодах (включая период, в котором произошло подключение тарифного плана-акции)
* тарифный план, который будет подключен после тарифного плана-акции
Указанные выше свойства не могут быть указаны по отдельности
Вариант который костылим мы (Вкратце все построено на идентификаторах родительских услуг):
Создается таблица акций, в которых описаны акции в объеме:
- название акции,
- дата начала (когда акция становится доступной к выбору),
- дата окончания (когда акция становится недоступной к выбору),
- с какого момента учитывать (с момента навешивания, с конкретной даты, с нового расчетного периода),
- продолжительность (либо в днях, либо до конкретной указанной даты),
- для каких групп пользователей может применяться (так как у нас группами закодированы услуги и города у пользователей, то мы используем условие "И"),
- стоимость подключения акции (нужно для таких случаем как "оплати абонентку за год")
- количество доступных использований акции абонентом
Создается связанная таблица стоимостей услуг входящих в акцию:
- стоимость услуг которые могут входит в ТП относительно родительских (например для любой услуги входящей в ТП, у которой родительская равна 123, стоимость будет = ХХХ), при этом стоимость рассчитывается или в % от стоимости периодической услуги в составе ТП, или в размере суммы скидки, или указывается конкретное значение стоимости.
Теперь нюанс: так как в составе ТП может быть несколько услуг с одинаковой родительской, то дополнительно описываем при необходимости стоимость для второй встреченной услуги, для третьей, итп. При этом если описаны три услуги, а найдена например четвертая, то стоимость четвертой берется по последней (т.е. третьей)
(Это требуется для случаев когда необходимо предоставить скидку например на второй телевизор)
Создается связанная таблица радиус параметров для услуг входящих в акцию:
- радиус атрибуты которые должны перекрывать те которые входят в ТП. (нужно если акция влияет на скорость услуги по ТП)
И последняя таблица привязки акций к лицевым счетам в которую при привязке акции к абоненту вносится:
дата привязки,
рассчитанная дата начала,
рассчитанная дата окончания,
статус (действующая, не наступившая, завершенная)
ЗЫ:
При этом при наличии скидки на услугу она имеет больший приоритет чем акция.
Одновременно не может быть две и более акций подключено к абоненту
Вот это да. я даже опешил когда увидел автора топика.
В принципе меня устроят любые варианты - лишь бы без глюков работали. Может Магнуму виднее т.к. у него функционал уже реализован через скрипты (может он поделится с разработчиками и они положат их на логику биллинга).
Что меня интересует по скидкам(бонусам)
1. Интересуют долгосрочные пользователи т.е. скидки бонусы на удержание.
Например после 1-2-3 лет переводить на другой тариф, делать скидки на услуги.
2. У многих безлимиты, но у нас в РБ больше позиционируются псевдо безлимит. т.е. снижение скорости после 100-200-500ГБ в месяц.
Соответственно интересует индивидуальные бонусы в виде добавления трафика для динашейпера, а также его(трафика) покупка через личный кабинет.
В принципе меня устроят любые варианты - лишь бы без глюков работали. Может Магнуму виднее т.к. у него функционал уже реализован через скрипты (может он поделится с разработчиками и они положат их на логику биллинга).
Что меня интересует по скидкам(бонусам)
1. Интересуют долгосрочные пользователи т.е. скидки бонусы на удержание.
Например после 1-2-3 лет переводить на другой тариф, делать скидки на услуги.
2. У многих безлимиты, но у нас в РБ больше позиционируются псевдо безлимит. т.е. снижение скорости после 100-200-500ГБ в месяц.
Соответственно интересует индивидуальные бонусы в виде добавления трафика для динашейпера, а также его(трафика) покупка через личный кабинет.
Последний раз редактировалось banec Вт сен 01, 2015 11:35, всего редактировалось 1 раз.
По 1 пункту это именно бонусами делается: ежемесячно начисляется бонусные баллы в зависимости от стажа, суммы потребленных услуг, своевременности оплаты.banec писал(а):Вот это да. я даже опешил когда увидел автора топика.
В принципе меня устроят любые варианты - лишь бы без глюков работали. Может Магнуму виднее т.к. у него функционал уже реализован через скрипты (может он поделится с разработчиками и они положат их на логику биллинга).
Что меня интересует по скидкам(бонусам)
1. Интересуют долгосрочные пользователи т.е. сидки бонусы на удержание.
Например после 1-2-3 лет переводить на другой тариф, делать скидки на услуги.. У многих безлимиты, но у нас в РБ больше позиционируются псевдо безлимит. т.е. снижение скорости после 100-200-500ГБ в месяц.
Соответственно интересует индивидуальные бонусы в виде добавления трафика для динашейпера, а также его(трафика) покупка через личный кабинет.
Re: Скидки, акции, бонусы в UTM5
когда увидим бету?serjk писал(а): Предварительно, озвученный функционал должен быть представлен в версии 5.3-004-beta к 01.01.2016
Мне как разработчику ПО, греет душу предложенные схемы запутанных тарифных планов и услуг, их феерической взаимосвязи и изменений параметров. Но возможно стоит взглянуть на проблему глазами клиента?
А клиента интересуют три вещи: наличие интернета, его скорость и баланс лицевого счета. 90% клиентов не интересуют заковыристые временные тарифы. У них нет времени разбираться, подключил и забыл. Мизерная часть из них заходит в Личный кабинет дабы узнать о текущих возможностях сэкономить.
Удержать клиента можно только приятно удивив его балансом лицевого счета и запугав потерей регулярного начисления денежных бонусов при отказе от ваших услуг
С точки зрения оператора связи сейчас я могу подпускать к билингу только высокооплачиваемый персонал в двумя высшими образованиями, справкой из психдиспансера о вменяемости и медсовидетельствованием об отсутствии алкоголя в крови. И даже они умудряются регулярно выдавать такие косяки что диву даешься. И я прямо вижу стекленеющие глаза этих сотрудников, когда скажу им - внедрите и используйте "учет времени действия коэффициента списаний по периодическим сервисным связкам" и не забудьте внятно объяснить клиентам их безмерное счастье от этой штуки.
Теперь по существу: как оператор связи хочу иметь возможность изменять баланс клиента периодически или разово, со стороны оператора билинга, со стороны клиента в Личном кабинете или автоматически, в зависимости от двух десятков критериев (выслуги лет, регулярности платежей и их величины, наличие и количества системных блокировок, стоимости периодических услуг, стоимости разовых услуг, стоимости услуг потребленных за период времени и так далее). Причем в автоматическом режиме хочу выбирать когда: перед завершением расчетного периода, после наступления расчетного периода (до или после списаний стоимости услуг), после поступления платежа от клиента, перед началом празднования хануки или на старый новый год. А как будет называться увеличение баланса лицевого счета клиента - Акции, Бонусы или Скидки, пусть решает самый трезвый маркетолог компании.
Вот, выговорился. Это моё личное мнение, никого не хотел задеть, особенно многоуважаемого мной Магнума и уважаемых разработчиков билинга
Мои утверждения строятся на 15-ти летнем опыте работы в этой сфере в условиях жесткой конкуренции с Ростелекомом (PON), ТТК, несколькими местными компаниями в отсутствии стороннего финансирования и государственных вливаний.
А клиента интересуют три вещи: наличие интернета, его скорость и баланс лицевого счета. 90% клиентов не интересуют заковыристые временные тарифы. У них нет времени разбираться, подключил и забыл. Мизерная часть из них заходит в Личный кабинет дабы узнать о текущих возможностях сэкономить.
Удержать клиента можно только приятно удивив его балансом лицевого счета и запугав потерей регулярного начисления денежных бонусов при отказе от ваших услуг
С точки зрения оператора связи сейчас я могу подпускать к билингу только высокооплачиваемый персонал в двумя высшими образованиями, справкой из психдиспансера о вменяемости и медсовидетельствованием об отсутствии алкоголя в крови. И даже они умудряются регулярно выдавать такие косяки что диву даешься. И я прямо вижу стекленеющие глаза этих сотрудников, когда скажу им - внедрите и используйте "учет времени действия коэффициента списаний по периодическим сервисным связкам" и не забудьте внятно объяснить клиентам их безмерное счастье от этой штуки.
Теперь по существу: как оператор связи хочу иметь возможность изменять баланс клиента периодически или разово, со стороны оператора билинга, со стороны клиента в Личном кабинете или автоматически, в зависимости от двух десятков критериев (выслуги лет, регулярности платежей и их величины, наличие и количества системных блокировок, стоимости периодических услуг, стоимости разовых услуг, стоимости услуг потребленных за период времени и так далее). Причем в автоматическом режиме хочу выбирать когда: перед завершением расчетного периода, после наступления расчетного периода (до или после списаний стоимости услуг), после поступления платежа от клиента, перед началом празднования хануки или на старый новый год. А как будет называться увеличение баланса лицевого счета клиента - Акции, Бонусы или Скидки, пусть решает самый трезвый маркетолог компании.
Вот, выговорился. Это моё личное мнение, никого не хотел задеть, особенно многоуважаемого мной Магнума и уважаемых разработчиков билинга
Мои утверждения строятся на 15-ти летнем опыте работы в этой сфере в условиях жесткой конкуренции с Ростелекомом (PON), ТТК, несколькими местными компаниями в отсутствии стороннего финансирования и государственных вливаний.
Поэтому написал вебморду к урфе для менеджеров с простейшей логикой далее-далее-далее.С точки зрения оператора связи сейчас я могу подпускать к билингу только высокооплачиваемый персонал в двумя высшими образованиями, справкой из психдиспансера о вменяемости и медсовидетельствованием об отсутствии алкоголя в крови. И даже они умудряются регулярно выдавать такие косяки что диву даешься. И я прямо вижу стекленеющие глаза этих сотрудников, когда скажу им - внедрите и используйте "учет времени действия коэффициента списаний по периодическим сервисным связкам" и не забудьте внятно объяснить клиентам их безмерное счастье от этой штуки.
UTM_Admin только для админов.