ПредисловиеЕсли у Атирры в один момент взять да и убрать фунционал учёта периодических услуг, то она тут же превратиться в ненужное приспособление к экселу или в крайнем случае ежедневнику. Давайте подумаем почему? Как по мне, то потому что не реализован на должном уровне фунционал приема заявок. Заявки (заказ-наряды) является фундаментом ко всем последующим движениям по программе и по части разовых услуг и по части материала а также, что не мало важно, управления общей работой компании по линии
ПОВЫШЕНИЯ КАЧЕСТВА обслуживания клиента. А в условиях сегодняшнего дня это особенно актуально, когда абонент имеет широкую возможность получать альтернативную услугу от конкурирующей компании.
Предлагаю в этой теме обсуждать всё, что касается заказ-нарядов по сути!
Учитывая тот факт, что у разработчика отсутствует справочный материал относительно функционала по заявкам, пытаемся понять его (разработчика) идеологию, положенную в основу заказ-нарядов.Заполнив и определив типы
и шаблоны заявок
Простестили на примере одного месяца и пришли к выводу, что этот фунционал ПО внедрён либо как статистический инструмент либо он НЕ воспринимается как ОСНОВНОЙ. Как работает подобный фунционал в альтернативных ПО можно посмотрев на схему ниже
Сейчас заканчиваю рисовать действующую и желаемую схемы в Атирре, которые выложу тутже чуть позже.
Однако, по ходу хотел уточнить такую возможность :а) работников организовывать в отделы (бригады);
б) назначать работникам (монтажникам) аттрибуты для ассоциации с выбранными районами или улицами;
в) определять инициатора заявки для возможности автоматического акцепта web и email
г) назначать в шаблоне заявки временную константу (время на исполнение - например подключение нового клиента 80 минут) без которой шаблон создать нельзя
д) после регистрации новой заявки - отправка его ассоциированным работникам (если пункт б) возможен и в аттрибутах возможно прописывать емайл работника)
