Приложение №1 Техническо задание /спецификация на софтуерния продукт/ Въведение



Дата24.06.2017
Размер215.28 Kb.

Приложение №1


Техническо задание /спецификация на софтуерния продукт/

1.Въведение

1.1Цел


Целта на този документ е да опише пълно функционалността на необходимата софтуерна система, както и взаимоотношенията и с други системи. Описаните по-долу функционалности следват принципа на работа описана в документите: „Обща методика за събиране на просрочени вземания и методиките за работа на отделите Телефонен център и Посещение на адрес.

1.2Обхват


Под Система в документа се разбира съвкупността от следните компоненти, които доставчика трябва да предостави:

  • Уеб базирано приложение

  • База данни

Не се поставят специфични изисквания за използваната софтуерна технология, типа на базата данни, необходимия хардуер и операционна система, въпреки че тяхната цена ще се вземе под внимание при оценяването на предлаганите продукти.

1.3Определения, съкращения и абревиатури

Система – общо название на софтуерния продукт.

DB – база данни.

SIP - Session Initiation Protocol (http://en.wikipedia.org/wiki/Session_Initiation_Protocol).

АТЦ – автоматична телефонна централа, поддържаща SIP протокол.

ТЦ – телефонен център (екип за връзка с длъжниците чрез обаждане по телефон).

ПА – посещение на адрес (екип за връзка с длъжниците чрез посещение на адрес).

2.Пълно описание

2.1Сравнително описание на продукта


Системата е предназначена за автоматизация на работния процес по събиране на вземания чрез обаждания по телефон и посещения на адрес. По тази причина Системата може да се разглежда като суперсет от различни модули отговарящи за функционално обособени части от софтуерните изисквания.



2.1.1Потребителски интерфейси


Основно изискване е Системата да бъде Web базирана и да се достъпва посредством браузер. Не трябва да се налага инсталация на терминалните машини. Графичният интерфейс трябва да е пригоден за правилна визуализация на различни разделителни способности като минимално поддържаната е 1024х780. Поддръжката на мобилни устройства с ниска разделителна способност не се предвижда за момента.

2.1.2Хардуерни интерфейси


Като входни устройства в графичния интерфейс ще се използват клавиатура и мишка. Изходни устройства ще са монитор и принтер. В системата ще се записват вече сканирани изображения. Не се изисква връзка и със скенер.

2.1.3Софтуерни интерфейси


Системата трябва да може да зарежда информация от MS Excel файлове. Това е предпочитаният начин за импортиране на големи масиви от данни, затова терминът, който ще използваме в изложението, е „наливане на данни”.

Системата трябва да може да чете и да показва съдържанието на различни типове документи (.doc; .docx; .rtf; .txt; .pdf; .xps; .odt; .html; .xml; .jpg; .gif; .bmp; .png) като част от страницата.

Системата трябва да е способна да направи mail-merge на .doc и .docx файл, като използва за източник на данни собствената си база данни.

За работа с Microsoft Office документи или Adobe Acrobat документи не трябва да се изисква допълнителен софтуер инсталиран на терминалните машини. Ако се изисква подобен софтуер да се инсталира на сървърната машина, доставчика трябва да го посочи изрично и да добави цената на лиценза в офертата си.


2.1.4Комуникационни интерфейси


Системата ще се достъпва изключително и само по https протокол.

3.Специфични изисквания

3.1Функции


В тази секция се описва пълния набор от функционални изисквания, без да се дават указания, какъв точно потребителски интерфейс ще ги реализира. Функционалните изисквания са обособени в групи според работните процеси описани в методиката.

3.1.1Управление на задължения по партиди

3.1.1.1Досие на партида


В досието на партида се пазят данните за договора:

  • партиден номер,

  • адрес на партидата,

  • име на клиента,

  • ЕГН на клиента,

  • контакти на клиента – други адреси и телефони,

  • номер на договора,

  • сканирано досие – съдържа документите приложени към досието в сканиран вид. Възможно е всички документи да са събрани в един файл, но ще е плюс ако Системата позволява качване на множество различни документи.

  • Фаза на работния процес (обяснено по-долу).

  • Текущи оператори по партидата (както и кой от тях е активен).

В досието на партидата се показва също Данни на длъжника, Текущото дължимо, Действия по партидата, както и Историята на активността.

3.1.1.2Партиди на един длъжник


Често един длъжник има няколко партиди от различни имоти. Понякога той спира да плаща повече от една партида и те попадат в Системата. В досието на партидата трябва да се показва ясно, че има и друга партида на същия длъжник, за да може с един разговор колекторът да опита да получи обещание за плащане по всяка от партидите.

3.1.1.3Текущо дължимо


Текущото дължимо по партидата се формира на база на неплатени фактури. Системата трябва да показва за всяка фактура следната информация:

  • Текуща резолюция: За работа, Погасено.

  • Сума на текуща главница

  • Сума на текуща лихва

  • Допълнителни такси, ако има такива – за всяка такса се показват сума и описание.

  • Общо платено по фактурата

  • Първоначална главница

  • Дата на фактурата

  • Падеж на фактурата

  • Номер на фактурата

Ако по партидата има повече от една фактури Системата трябва да показва данните само на една. Тази фактура ще наричаме текуща. Всички действия ще се правят по текущата фактура. Останалите фактури трябва да са лесно достъпни и всяка една от тях (дори платените) трябва да може да стане текуща.

Ако резолюцията по една фактура е Погасено, тя не трябва да се взима в предвид при изчисляването на общия дълг по партидата, независимо какво е дължимото по нея. Също така ясно трябва да се показва, че е погасено, за да не се бъркат колекторите.


3.1.1.4Данни на длъжника


За длъжника по партидата трябва да се показват следните данни:

  • Име;

  • ЕГН ако е налично;

  • Телефонни номера;

  • Адреси;

  • Свързани лица;
3.1.1.4.1Лист с телефонни номера

Всеки длъжник може да има повече от един телефонен номер. Част от номерата се подават още при въвеждане на партидата, защото са записани в договора с длъжника. Други може да бъдат добавени в последствие от колекторите. Всички номера требва да се показват в лист, като за всеки номер трябва да има и икона за статус, бутон за набиране, бутон за редакция и коментар към номера. Статусите на един номер може да бъдат:

  • Неизвестен;

  • Коректен;

  • Некоректен.

При всеки успешен разговор листът требва да се пресортира, като номерът, на който е разговаряно, трябва да мине на първо място.

Важна характеристика за длъжника е статуса му на достъпност по телефон. Длъжника може да бъде: Откриваем, Неоткриваем и Неизвестно. Статусът е Откриваем, ако поне един от телефонните номера на длъжника е коректен. Статусът е Неоткриваем, ако всички телефонни номера на длъжника са некоректни. В противен случай статусът е Неизвестен. Статусите на отделните телефонни номера може да се променят експлицитно от оператор или автоматично от самата Система, когато след разговор на този номер, колекторът заяви, че номерът е на лице не свързано с длъжника или пък че номерът е грешен или непълен.


3.1.1.4.2Лист с адреси

Всеки длъжник може да има повече от един адрес. Част от адресите се подават още при въвеждане на партидата, защото са записани в договора с длъжника. Други може да бъдат добавени в последствие от колекторите. Всички адреси требва да се показват в лист, като за всеки адрес трябва да има и икона за статус, бутон за насрочване на посещение, бутон за редакция и коментар към номера. Статусите на един адрес може да бъдат:

  • Неизвестен;

  • Коректен;

  • Некоректен.

При всеки успешен разговор листът требва да се пресортира, като номерът, на който е разговаряно, трябва да мине на първо място.

За всеки адрес трябва да може да се добавят GPS координати. Предимство ще е, ако Системата предоставя възможност при посещение на адрес колектора да укаже точните координати автоматично, ако работи с устройство и имащо GPS функция.



Забележка: Адресът по партида трябва да се вижда и в досието на партидата извън листа с адреси на длъжника, тъй като е важна характеристика на партидата.

Важна характеристика за длъжника е статуса му на достъпност по адрес. Длъжника може да бъде: Откриваем, Неоткриваем и Неизвестно. Статусът е Откриваем, ако поне един от адресите на длъжника е коректен. Статусът е Неоткриваем, ако всички адреси на длъжника са некоректни. В противен случай статусът е Неизвестен. Статусите на отделните адреси може да се променят експлицитно от оператор или автоматично от самата Система, когато след посещение на този адрес, колекторът заяви, че адресът е на лице не свързано с длъжника или пък че адресът е несъществуващ.



Длъжникът трябва да има и текущ адрес за посещения – един от адресите избран от ръководителя на екипите за посещения. На него се насрочват посещенията от екипите.

3.1.1.5История на активността


В историята на активността трябва да влизат всички действия извършени по досието на партидата подредени в обратен хронологичен ред. За всяко действие трябва да се показва, от кого е извършено, както и допълнителна специфична информация по действието. Ако действието е извършено от екип, се показва името на екипа и името на колектора въвел самото действие в системата (например: „Екип 1 – И.Петров“) Необходимо е да има филтри, които да скриват част от активността, тъй като се очаква по една партида да има десетки действия. Желателно е тези филтри да са настройващи се, но като цяло е задължително да има следните:

  • Всички – показва всички активности

  • Текуща фактура – скрива активностите нямащи връзка с текущата фактура;

  • Плащания – скрива активностите несвързани с плащания и промяна на задължението;

  • Превъзлагания – показва само активностите по превъзлагане на партидата на различни колектори, както и смяна на фазата на работня процес;

  • Раговори по телефон;

  • Посещения на адрес;

  • Срещи в офиса;

3.1.1.6Действия по партидата и фактурите


Възможните действия по една партида се делят на следните основни групи:

  • Администриране – включва превъзлагане на партидата за работа от определен колектор.

  • Промяна на дължимото – включва добавяне или премахване на такси и лихви, промяна на главницата, сконтиране, плащане, погасяване на задължението.

  • Оперативни – включва обещание за плащане, напомняне за работа, прехвърляне от ТЦ към ПА и обратно, смяна на работната фаза.

  • Промяна данни на длъжник – промяна на статус на телефон или адрес, добавяне на телефон или адрес, добавяне на свързани лица.

  • Коментари – свободен текст.

3.1.1.7Резултат от контакт с длъжник


Според методологията при контакт с длъжника колекторите са длъжни да съберат определена информация. Системата трябва да изисква въвеждане на тази информация.

  • Валиден ли е телефонният номер (при контакт по телефон) или адреса (при контакт на адрес);

  • Определяне на статусите на всички налични телефони и адреси;

  • Добавяне на нови телефони и адреси, ако има такива;

  • Определяне на кого е номера или адреса телефонният номер (при контакт по телефон) или адреса (при контакт на адрес). Ако това не е длъжника, се определя дали има връзка с него и каква.

  • Въвежда се, с кого е проведен разговора. Това може да не е собственика на адреса или телефонния номер.

  • Въвежда се резултата от преговорите: обещание за плащане (от дата до дата), насрочване на нов контакт или непроведени преговори.

Резултатът от контакт трябва да бъде ясно обособен в историята на активността.

Според методиката, при определен резултат от контакт Системата трябва да добавя автоматично напомняне за колектора след зададен брой дни. Например, при обещание за плащане автоматичното напомняне трябва да излезе 2 дена след крайната дата на обещанието.

Ако длъжникът има повече от една партида с просрочени плащания, Системата трябва да изиска поставяне на резултат след контакт по всяка една от партидите.

3.1.1.8Отговорници по партида


В зависимост от фазата на работата по партидата, тя може да има един или двама отговорника. Ако се работи основно от телефонен център, тогава има един отговорник – служител от телефонния център. Ако е на фаза посещение на адрес, отговорниците са двама – един от телефонен център и един от екипите за посещение на адрес. В методиката процесът на определяне на тези отговорници се нарича превъзлагане. То е в правомощията само на ръководителите на телефония център и раководителите на екипи. Системата трябва да позволява превъзлагане както на една единствена партида, така и на лист от партиди. Отделните фактури се считат за неразделна част от партидата и се работят заедно, т.е. само от един отговорник.

Не е задължително една партида да е превъзложена за работа от когото и да е. Допустимо е да има само отговорник от телефонен център (валидно за всички партиди от фаза Телефонно събиране), само отговорник от Посещение на адрес и дори дори да няма нито един отговорник.

В даден момент партидата има само един активен отговорник. От него се очаква следващото действие по случая. Например ако има насрочено посещение на адреса, активният отговорник е екипът за посещение на адрес. Ако има обещание за плащане на каса или по електронен път, активният отговорник е служителят в телефонен център. Подробно описание на критериите за определяне на активен оператор са описани по-долу.

3.1.1.9Прехвърляне на текуща отговорност по партидата


Активен отговорник може да бъде само един от двамата отговорници, на които е превъзложена партидата – служител от телефонен център или екип за посещение на адрес. Прехвърлянето на текуща отговорност трябва да се показва в историята на активността като „За работа от Телефонен център“ и „За работа от Посещение на адрес“, а не като „За работа от Иван Илиев“ например.

Възможен е сценарий, в който партида се прехвъля за работа например от екип за посещение на адрес, но партидата не е превъзложена на нито един екип, т.е. има само отговорник от телефонен център. В този случай активният оператор си остава телефонистът, но ако в последствие партидата се превъзложи за работа на някой екип, Системата автоматично трябва да го направи и активен отговорник.



Задаването на активен отговорник трябва да става по два начина: автоматично и експлицитно.
3.1.1.9.1Автоматично задаване на активен отговорник

Системата трябва да определя сама активния отговорник следейки състоянието на партидата. Методиката указва следните правила:

  • Във фаза Събиране по телефон не се променя активния отговорник. Той винаги е служителят от телефонен център.

  • При влизане във фаза Събиране чрез посещение на адрес активният отговорник се променя на екипа за посещения на адрес.

  • При обещание за плащане на каса или по електронен път активният отговорник става телефонистът.

  • При обещание за плащане на адрес активният отговорник става екипът.

  • След посещение на адрес системата трябва да избере на кого да възложи следващото действие. Ако екипът успее да вземе обещание за плащане се процедира според горните правила. Ако е говорено с длъжника, но е постигната само уговорка за допълнителен разговор, се поставя напомняне и се партидата се прехвърля към телефонния център. Ако не е постигната никаква уговорка, или не е говорено с длъжника, или адресът е некоректен, партидата остава за работа от екипа.

  • При две последователни не спазени обещания за плащане от страна на длъжника, партидата се връща за работа от екипа.

  • Ако телефонистът не успее да се свърже с длъжника 10 последователни пъти, партидата се връща за работа от екипа.

  • Ако всички телефони минат в статус Некоректен, активният оператор не може да е телефонистът. В случай че според форните критерии партидата трябва да се работи от телефонен център, но длъжникът е неоткриваем по телефон, Системата не трябва да променя активния оператор. Въпреки това, ако в последствие се добави нов коректен номер, Системата трябва да реагира и да прехвърли партидата за работа от телефониста. По същия начин трябва да се процедира и в случай, че всички адреси са некоректни.
3.1.1.9.2Експлицитно задаване на активен отговорник

Експлицитното задаване на активен помощник е алтернатива на автоматичното, която позволява на ръководителите да заобиколят методиката за работа, ако по дадена причина тя не е приложима при работата по текущата партида. При експлицитно задаване на активен отговорник Системата не трябва да проверява дали длъжника е откриваем по адрес или телефон. Трябва да може да се прави както за един така и за група от партиди.

3.1.1.10Обещания за плащане и напомняния


От голяма важност за колекторите е да могат лесно да намират кои случай са с изтекли обещания за плащане и за кои е поставено напомняне. Системата трябва да показва на видно място лист с обещанията за плащане по случаите работени от колектора (или екипа). В този лист трябва да влизат обещания с изтекла крайна дата, но все още необработени от колектора. Колекторът трябва да може да маркира обещанието като обработено (т.е. да покаже, че е работил по случая) и тогава обещанието трябва да изчезне от списъка. Обещанията трябва да са подредени по крайна дата във възходящ ред.

Също така на видно място трябва да са показани и всички напомняния по партидите на колектора в обратно хронологичен ред. Също както и при обещанията за плащане напомнянията трябва да се маркират като обработени за да изчезнат от листа.

При поставяне на обещание за плащане Системата трябва да добавя и автоматично напомняне:


  • За 1 ден преди крайния срок за плащане (при плащане на адрес);

  • За 2 дена след крайния срок за плащане (при плащане на каса или по електронен път).

3.1.1.11Импорт на партиди


Информацията за партидите ще бъде въведена в Системата чрез импорт от .xls файл. Данните за една партида ще се подават в един ред от таблицата. Системата трябва да позволява настройване на импорта, т.е. коя колона какви данни съдържа и как да бъде импортирана.

Някой параметри на партидите ще трябва да могат да се променят отново чрез импорт от файл. Например по този начин ще се нанасят корекции по текущото дължимо и лихва.


3.1.1.12Плащания


При нанасяне на плащанията в Системата трябва да се променя текущото дължимо по фактурите. Редът на погасяване е следния:

  • Допълнителни такси (ако има такива);

  • Лихва (ако има такава);

  • Главница;

Плащанията се правят по текущата фактура, а не по цялата партида. Ако обаче сумата на плащането надвиши общото дължимо по фактурата, се погасява и част от най-ранната неплатена фактура. За всяко плащане в историята на активността трябва да се вижда колко и по кои фактури е платено, разбито на такси, лихва, главница.

Системата трябва да позволява и анулиране на плащания.

Дължимото по фактурите може да се променя чрез импорт. След подобен импорт всички плащания направени преди това се считат за чисто информативни и не трябва да може да се анулират.

3.1.1.13Лихви


Системата трябва да може да изчислява законова мораторна лихва върху главницата от зададена дата. Фактурата първоначално се олихвява от датата на падежа и. Но при всяко плащане, погасяващо и главница, лихвата се стартира от начало от датата на плащането.

Ако дължимото по фактурата се промени чрез импорт, не се изисква повече да се изчислява лихвата.

Тъй като законовата лихва е обвързана с основния лихвен процент на БНБ, Системата или трябва да получава обновени данни за ОЛП от външен доставчик или да поддържа собствена база и да позволява обновяването и от оператор.

3.1.1.14Типови бланки


В процеса на работа по партидите се налага разпращането на редица темплетни документи, като уведомления, искания и други. Тези документи трябва да могат да бъдат съставяни директно от Системата. Шаблоните на тези документи ще бъдат във Microsoft Word файл формат и ще използват технологията Mail Merge. Системата трябва да може да попълни един такъв шаблон с данни от партидата и фактурата.

За някой типове бланки е важно да се запазват попълнените документи в системата и при последващо изискване да не се създават наново, а да се ползват вече създадените.


3.1.1.15Насрочване на посещение на адрес


Ръководителите на екипи за посещение на адрес определят маршрутите на отделните екипи ден за ден. Това става чрез насрочване на посещение на определени длъжници, съобразявайки се с приоритета на случая и близостта му до останалите от маршрута. При насрочване на посещение се задават:

  • Длъжник;

  • Адрес (един от всичките адреси на длъжника);

  • Дата;

  • Партиди, за които да се говори с длъжника;

  • Тип посещение – стандартно, за получаване на пари и др.

Трябва да може да се насрочи посещение за лист от партиди. В този случай всички партиди от списъка ще влязат в маршрута на определен екип за определен ден.

Маршрутът на даден екип трябва да може да се редактира от ръководителя на екипа. Той може да добавя нови адреси, да премахва вече избрани такива, както и да указва за всеки адрес, кои дългове по кои партиди трбява да се обсъдят с длъжника (в случай че длъжника дължи пари по повече от една партида.)

Ситемата трябва да дава предложения за близки адреси на тези, които вече са в маршрута. Трябва да може да се видят всички адреси от маршрута на карта, заедно с допълнителните предложения. Така ръководителите ще съставят по-оптимизирани маршрути.

3.1.1.16Насрочване на обаждане по телефон


Обаждания по телефон се насрочват при итериране на партидите (виж по-долу) или в случаите за повторно търсене описани в методиката (например след зает сигнал автоматично се насрочва обаждане за след 10 минути, при свободен сигнал и неприето обаждане автоматично се насрочва обаждане за след 3 часа и т.н.).

При насрочване на обаждане се задават:



  • Длъжник;

  • телефон (един от всичките телефони на длъжника);

  • Дата (и час);

  • Партиди, за които да се говори с длъжника;

  • Тип посещение – стандартно, за проверка на плащане и т.н.

3.1.1.17Таргетиране


Всеки колектор или екип от телефоне център и посещение на адрес има индивидуално разпределени партиди за работа. Тези партиди формират неговата таргет група. Върху тази таргет група се определя и таргетната сума, за която колекторът трябва да допренесе в рамките на един месец.

Според правила описани детайлно в методиката за всяко плащане може да се определят един или двама бенефициенти. За всеки от бенифициентите плащането се отразява към неговата таргет сума. Всеки колектор трябва да може да провери, каква е натрупаната му до момента таргет сума, както и ръководителите трябва да могат да получат обща справка.


3.1.1.18Итератори


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

Необходими са два типа итератори различаващи се по начина, по който изчисляват следващия случай:



  • Линейни: следват стриктно реда на подадените партиди, без да се съобразяват с никакви техни параметри;

  • Нелинейни: променят реда на подадените партиди, като пропускат напълно погасени задължения, и не показват задължения за работа от друг колектор. Например: нека имаме итератор съдържащ всичките случаи възложени на служител от телефонния отдел. Част от тези случаи може да са вече погасени, или погасени след създаване на итератора. Тези случаи не трябва да се показват като следваща партида. В даден момент част от партидите може да са за действие от екип за посещение на адрес. Тези случаи също не трябва да се показват, но ако до края на итератора някой от тях се върне за работа от телефонен център, трябва да се появи и като следващ случаи от итератора.


3.1.2Статистика и търсене

3.1.2.1Бързо търсене


Необходимо е да има лесно достъпен начин за търсене, при който се въвежда само един шаблон за търсене и се показват всички партиди, които имат:

  • Длъжник с име, сходно с търсения текст (при въведено „Петър Иванов“ трябва да се връщат както Петър Иванов Димитров, така и Петър Петров Иванов);

  • ЕГН започващи с търсения текст;

  • Партиден номер започваш с търсения текст;

3.1.2.2Разширено търсене


Системата трябва да позволява търсене на следните обекти:

  • Фактури и партиди;

  • Длъжници;

  • Действия;

За всеки от тези обекти са в сила различни критерии за търсене.

Трябва да може да се експортнат резултатите от търсенето в Microsoft Excel формат. Също така адресът на страницата с резултатите трябва да е достатъчно описателен, за да може да бъде изпращан по мейл или букмаркнат и в последствие да се отворят отновосъщите данни (т.е. да се приложи същия филтър; при промяна на данните в системата показаните данни може и да не са същите.)


3.1.2.2.1Търсене по фактури

Филтри:

  • По данни на длъжника: име, егн, досъпен по адрес, достъпен по телефон.

  • По данни на партидата: по партиден номер, по номер фактура, по състояние на партидата („за работа“, „погасена“), с или без чакащи обещания за плащане, с и без плащания.

  • По данни на отговорника: по текущ отговорник, по определен отговорник от телефонен център, по определен отговорник от посещение на адрес.

Резултатите трябва да се представят в табличен вид, като за всяка фактура трябва да се показват минимум следните полета:

  • Номер на фактурата;

  • Номер на партидата;

  • Егн на длъжника;

  • Име на длъжника;

  • Адрес на партидата;

  • Текущ адрес за посещения на длъжника;

  • Статус на достъпност по адрес

  • Текущ телефон на длъжника;

  • Статус на достъпност по телефон;

  • Дата на фактурата;

  • Дължимо по фактурата;

  • Платено по фактурата;

  • Текущ отговорник;

  • Последно действие: дата и тип;
3.1.2.2.2Търсене по длъжници

Филтри:

  • Име;

  • ЕГН/ЕИК;

Резултатите трябва да се представят в табличен вид, като за всяка фактура трябва да се показват минимум следните полета:

  • Номер на длъжника в системата;

  • Име;

  • ЕГН/ЕИК;

  • Текущ адрес за посещения на длъжника;

  • Статус на достъпност по адрес

  • Текущ телефон на длъжника;

  • Статус на достъпност по телефон;
3.1.2.2.3Търсене по действия

Филтри:

  • Дата;

  • Тип на действието;

  • По данни на отговорника: по текущ отговорник, по определен отговорник от телефонен център, по определен отговорник от посещение на адрес.

  • По отговорник извършил действието;

Резултатите трябва да се представят в табличен вид, като за всяка фактура трябва да се показват минимум следните полета:

  • Дата;

  • Тип на действието;

  • Направено от;

  • Име на отговорника по партидата;

  • Длъжник;

  • ЕГН/ЕИК на длъжник;

  • Коментар по действието;

3.1.2.3Действия по няколко фактури


Върху резултатите от разширено търсене по фактури трябва да могат да бъдат приложени определени действия, като превъзлагане за работа от друг отговорник, задаване за посещение на определен екип на определена дата, коментар и др.

3.1.2.4Статистики


Системата трябва да може да изготвя статистики върху определен сет от партиди, например партидите работени от даден екип за посещение на адрес. Според критерии описани детайлно в методиката всяка партида трябва да се постави в определена категория, като след това да е възможно да се селектират само случаите от определено населено място и категория. Категориите са „Чакащо обещание за плащане“, „Пропуснато обещание за плащане“, „Неоткриваем по телефон“, „Неоткриваем по адрес“, „Друго“ и т.н.

3.1.2.5Избор от карта


Системата трябва да може да представи такива категоризирани случаи и на карта, за да може ръководителят на екипа да се ориентира по-лесно за разстоянието между адресите в един маршрут. От маркерите по картата трябва да може да се насрочи посещение. Предимство ще е, ако може да се селектират адреси за посещение чрез заграждане с мишката по картата.

Маркерите на адресите по картата трябва да съответстват на категорията, в която попада партидата.

Важно: не трябва да се изисква допълнителни такси или абонамент за ползването на картата.

3.1.3Управление на телефонна централа


Системата трябва да може да набира телефони на длъжници чрез бутон или хиперлинк. Системата трябва да може да работи с Астериск централа, като при входящи разговори, трябва да може да идентифицира телефона, ако е наличен в базата данни и да показва на телефона на служителя името и ЕГН на длъжника. Допълнително удобство ще е ако при ползването на софтуерен SIP телефон може да се кликне на линк и да се отвори досието на обаждащия се длъжник.

Системата трябва да прихваща момента на завършване на разговор и да задължава колектора да въведе резултат от този разговор, ако разговорът е бил с някой длъжник. Системата трябва да може да получи и статуса на разговора: свободно, заето, отказано, проведен разговор и т.н. за да може да улесни колектора, като попълни част от резултата сама.

Системата трябва да предоставя статистика за разговори: дата и част, продължителност, вътрешен номер (име на колектор), външен номер (име и егн на длъжник), резултат.

3.1.4Администрация на системата


Администрацията на системата е най-общо добавянето и премахването на потребители и екипи, като и задаването на различни роли за всеки потребител. Всеки потребител трябва да може да промени своята парола, както и администратор трябва да може да я промени. При триенето на потребители е важно да се отбележи, че потребителя може да е правил действия по партидите. В този случай действията в историята на активността нетрябва да се променят по никакъв начин. Единственото, което трябва да се премахне е възможността на съответния потребител да влиза в системата.

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


3.1.4.1Типове потребители


Съществуват следните типове потребители:

  • Колектор телефонен център

  • Ръководител телефонен център

  • Колектор посещение на адрес

  • Ръководител посещение на адрес

  • Анализатор

3.2Изисквания за производителността


  • Системата трябва да работи нормално без забавяне при 100 едновременни сесии.

  • Всяка страница трябва да се отваря за по-малко от 1 секунда.

  • Зареждането на данните в справките може да отнемат повече от 30 секунди. Тези данни ще се зареждат динамично след зареждането на самата страница.

  • Сесиите не трябва да прекъсват при изтичане на таймаут. Веднъж отворена страницата поддържа активен статус. Сесията се затваря до 5 сек. след затваряне на браузъра.

Заявител: ……………...............



/Златко Стамов/





Page














База данных защищена авторским правом ©obuch.info 2016
отнасят до администрацията

    Начална страница