Kronixon PI вече включва пълна система за сервизни и IT заявки, активна от 31 август 2026 г. Заявките могат да се създават чрез глас, текст или снимка, анализират се от AI при приемане и се проследяват от клиентите през собствен портал. Системата управлява хронология, прикачени файлове, контролни списъци, месечни отчети и номерация.

Когато клиент се обади за счупен лаптоп или софтуерна повреда, заявката попада където е вдигнат телефонът — в бележник, в таблица, в паметта. Докато техникът пристигне, половината контекст липсва. Клиентът не знае на какъв етап е случаят, мениджърът не знае какво е отворено, а един и същ проблем се докладва два пъти, защото никой не е проверил.
Сервизната работа изисква структура от момента, в който заявката пристигне. Не след като някой намери време да я впише и не само за случаите, които изглеждат важни.
Модулът за заявки улавя всяка заявка на едно място, с хронология, която започва в момента на създаването ѝ. Клиент може да отвори заявка чрез гласова бележка, като въведе текст в портала или като изпрати снимки от телефона си чрез QR код. Платформата транскрибира гласовата бележка, анализира я с AI и извлича фирмата, служителя и проблема. Когато разпознаването е сигурно, заявката се създава автоматично. Когато не е, бележката изчаква преглед.
Клиентският портал работи на адрес support.ioncomputers.bg и дава на всяка клиентска фирма собствен вход. Служител там може да види собствените си заявки, да добави последващи бележки или снимки и да проследява статуса без телефонно обаждане. Порталът адаптира цветовата си схема според фирмата.
Вътре в платформата всяка заявка носи хронология на събитията, прикачени файлове, контролни списъци и документи. Техник може да диктува констатации на място и системата ще ги обработи. Месечните отчети групират заявките по клиент, с номерация, която се нулира всеки месец, и протоколи, които могат да се фактурират ръчно.
Когато пристигне гласова бележка, платформата я транскрибира и изпраща текста към AI със структуриран prompt. От AI се иска да извлече името на клиента, името на служителя, актива, за който се докладва, и кратко описание на проблема. Отговаря в JSON.
Ако и четирите полета се върнат с висока увереност, заявката се създава и клиентът се уведомява. Ако някое поле е несигурно, бележката отива в опашка за преглед. Човек чете транскрипцията, попълва липсващото и одобрява. Заявката след това се появява в системата, сякаш е била сигурна от самото начало.
Същият процес на приемане важи за текст, въведен в портала. Снимките отиват направо в заявката като прикачени файлове, без анализ.
Порталът е отделен интерфейс, не основната платформа. Администраторът на клиентската фирма получава линк за вход по имейл. След това този администратор може да покани служители от същата фирма. Всеки служител вижда само собствените си заявки.
Когато служител създаде заявка, може да въведе описание, да запише гласова бележка или да сканира QR код, за да превърне телефона си в камера. QR кодът генерира еднократен token за качване. Телефонът отваря страница, където камерата работи, снимката се изпраща и token-ът изтича. Заявката се появява в основната платформа незабавно.
Порталът не позволява редактиране на затворени заявки, но могат да се добавят последващи бележки към отворените. Промените в статуса са видими в реално време.
В края на всеки месец платформата генерира отчет за всеки клиент. Отчетът изброява всяка заявка, отворена през месеца, групирана по статус. Всяка заявка носи номер, който се нулира на първо число — така че августовските заявки тръгват от 001 нагоре, а септември започва отново от 001.
Отчетът може да се отпечата или експортира. Фактурирането е ръчно: мениджърът преглежда отчета, избира кои заявки да фактурира и създава фактурата извън платформата. Системата за заявки не генерира фактури самостоятелно.
AI получава транскрипцията и prompt, който дефинира четирите полета. Не вижда предишни заявки, няма достъп до клиентската база данни и не решава приоритет. Извлича, не предполага.
Когато AI е несигурен, го казва в JSON отговора. Опашката за преглед показва транскрипцията, опитаното извличане и формуляр за коригиране. Човекът, който прави прегледа, е този, който решава дали предположението е било близо или грешно.
Заявките се свързват с клиентския запис, така че известието „кой се обажда” може да покаже отворени случаи. Дневникът на обажданията може да прикачи запис на разговор към заявка. Системата за задачи може да създаде последващи задачи от събитие в заявка.
Модулът за заявки все още не се свързва с поръчки към доставчици или оферти. Това е отделен поток, изграден за сервиз и поддръжка, не за продажби.
Настоящата версия обработва приемане, хронология, достъп до портала и месечни отчети. Следващата стъпка е автоматично създаване на задачи от събития в заявки — така че когато заявка бъде маркирана „изчаква части”, задача за поръчка на частта се създава без ръчно въвеждане. След това интеграцията с телефонната система ще позволи заявка да се отваря директно от известие при обаждане.
Може ли клиент да създаде заявка без портала?
Да, по телефона. Човекът, който приема обаждането, може да диктува гласова бележка или да въведе заявката директно в платформата. Порталът е по избор.
Какво се случва, ако AI сгреши името на клиента?
Заявката отива в опашката за преглед. Човек чете транскрипцията, коригира името и одобрява. След това заявката се създава с правилния клиент.
Могат ли двама клиенти да имат един и същ номер на заявка?
Да. Номерата на заявките се нулират всеки месец и са обхванати по клиент. Заявка 015 на клиент А през септември е отделна от заявка 015 на клиент Б през същия месец.
Съхранява ли платформата записи на разговори вътре в заявките?
Не. Записът остава в телефонната система. Заявката съхранява линк към записа и транскрипцията, но не и самия аудио файл.
Разкажете ни какво изяжда деня на екипа ви. Ще ви покажем — върху собствената ни работеща система — колко от него може просто да изчезне.