Водичи

Како да направите систем за helpdesk тикети: тикети, статуси, доделување и е-пошта

Helpdesk системот за тикети ги претвора расфрланите барања — е-пошта, пораки, „брзи прашања“ во ходникот — во тикети: по една евиденција за секој проблем, со сопственик, статус, приоритет и целосен разговор. За да изградите таков, ви требаат начин за создавање тикети, заедничка редица со филтри, доделување, низа што ги одвојува јавните одговори од внатрешните белешки и известувања за да никој не чека без одговор. Една AI алатка за градење апликации може за еден попладне да изгради солидна прва верзија за внатрешен IT, HR или desk за објекти. Поддршката за клиенти со нишки по е-пошта, цели за одговор и извештаи бара повеќе грижа — и тука добро производите за helpdesk ја оправдуваат својата цена.

Што му треба на системот

Податоци

ТабелаКлучни полиња
ТикетиБрој, предмет, барател, категорија, приоритет, статус, доделен, тим, време на создавање, време на прв одговор, време на решавање
ПоракиТикет, автор, текст, јавен одговор или внатрешна белешка, прилози, време на испраќање
БарателитеИме, е-пошта, организација или оддел
АгентиИме, е-пошта, тим, улога (агент, раководител, администратор)
КатегорииИме, стандарден тим, стандарден приоритет
Готови одговориНаслов, текст, категорија
Дневник на активностиТикет, кој, што се промени, кога

Чувајте ги временските ознаки за прв одговор и решавање од почеток. Тие се основа на секој извештај, а подоцна не можете да ги реконструирате.

Страници

  • Барател: формулар „поднеси барање“ со категорија и прилози, листа „моите барања“ и низата на секој тикет.
  • Агент: редицата (мои тикети, неназначени, сите отворени), филтри и пребарување, приказ на тикет со контроли за одговор, белешка, статус, приоритет и доделување.
  • Администратор: категории, тимови, агенти, готови одговори и едноставен извештај.

Дозволи

Барателите ги гледаат само своите тикети и само јавните одговори. Агентите ги гледаат тикетите на својот тим и внатрешните белешки. Раководителите и администраторите гледаат сè и управуваат со поставките. Класичната катастрофа во helpdesk е внатрешна белешка што ѝ се прикажува на клиентот, па ова мора да се спроведува на серверот, не само со скривање на картичка. Видете контрола на пристап по улоги.

Одлуки и компромиси

Формулар, е-пошта или двете

Веб-формуларот е наједноставен и ви дава чисти податоци: категорија, приоритет и задолжителни полиња. Прием по е-пошта — луѓето пишуваат на support@ и се појавува тикет — е она што клиентите го очекуваат, но бара давател на е-пошта што може да прима пораки и да ги објавува во вашата апликација, плус нишки за да одговорите да се поврзат со вистинскиот тикет (обично број на тикет во предметот или единствена адреса за одговор). Почнете со формуларот; додајте е-пошта откако ќе се докаже работниот тек. Испраќање е-пошта од апликацијата ја опфаќа излезната страна.

Доделување

Можности: агентите избираат од неназначената редица; тркалезно распределување во тим; или доделување по категорија. Избирањето од редицата функционира за мали тимови. Автоматското доделување помага штом тикетите остануваат без сопственик.

Приоритети и цели за одговор

Дефинирајте два или три приоритети со цел за прв одговор („итно: 1 час, нормално: 1 работен ден“). Прикажувањето на преостанатото време на секој тикет е покорисно од месечен извештај што никој не го чита. Работното време ја прави математиката потешка — одлучете рано дали целите ги броат ноќите и викендите.

Спојување и дупликати

Истиот проблем пријавен три пати е вообичаен. Дејството „спои во тикет #“ ги штеди агентите од одговарање на истото повторно и вреди да се направи рано.

Прва порака што функционира

Направи внатрешен IT helpdesk за компанија со 60 вработени. Вработените поднесуваат барања со формулар: предмет, категорија (хардвер, софтвер, пристап, мрежа, друго), приоритет (низок, нормален, итно), опис и прилози. Секој тикет добива број и статуси нов, отворен, чека на барателот, решен, затворен. IT агентите гледаат редица со табови за неназначени, мои и сите отворени, филтри по категорија, приоритет и статус, и пребарување. Страницата на тикетот го прикажува разговорот со јавни одговори и внатрешни белешки јасно одвоени; вработените никогаш не ги гледаат внатрешните белешки. Агентите можат да доделуваат, да менуваат статус и приоритет, да користат готови одговори и да спојуваат дупликати. Следете ги времињата на прв одговор и решавање и прикажете време од последното ажурирање на секој тикет. Вработените имаат страница „мои барања“. Улоги: вработен, агент, администратор. Сето складирајте во база на податоци. Едноставен, густ и брз интерфејс — брзина пред украс.

Чекори за градење

  1. Модел на тикет и формулар. Поднесете, наведете, отворете тикет, одговорете.
  2. Редица и филтри. Неназначени, мои, сите отворени; филтрирање и пребарување; подредување по приоритет и возраст.
  3. Улоги и најава. Барател, агент, администратор — со белешките скриени од барателите на серверот.
  4. Контроли за доделување, статус и приоритет, со дневник на активности за секоја промена.
  5. Известувања. Испратете е-пошта до барателот при јавни одговори и до агентот при нови доделувања, преку ваш давател на е-пошта.
  6. Готови одговори и спојување.
  7. Цели за одговор и основен извештај: отворени тикети по возраст, време на прв одговор, тикети по категорија.
  8. Прием по е-пошта, откако останатото ќе работи, со темелно тестирана нишка.
  9. Пилот со еден тим две недели пред да ги префрлите сите.

Чести грешки

  • Внатрешни белешки видливи за барателите затоа што биле скриени само во интерфејсот.
  • Премногу статуси и категории. Агентите го избираат првиот што изгледа блиску. Почнете со најмногу по пет од секое.
  • Нема временски ознаки за прв одговор и решавање. Ќе ги сакате бројките денот кога некој ќе праша „дали сме побрзи?“
  • Одговорите по е-пошта создаваат нови тикети наместо да се нишкаат. Тестирајте одговор од мобилна пошта, бидејќи често ги менува предметите.
  • Сите доделени, никој одговорен. Еден доделен по тикет; за сите други користете следачи.
  • Прилози со јавни URL-а. Снимките од порака за грешка често содржат приватни податоци. Чувајте ги датотеките приватни и послужувајте ги само на луѓето што можат да го видат тикетот.

Кога е подобар готов производ

За поддршка на клиенти преку е-пошта, разговор и социјални мрежи — со следење на цели за одговор, анкети за задоволство, макроа, извештаи и интеграции — посветен helpdesk производ речиси секогаш е подобра инвестиција. Тие производи години работеле на нишкање по е-пошта, спам, рутирање и извештаи, а тоа не е делот од вашето работење што ве прави различни. Нашиот водич за алтернативи на Zendesk ги споредува опциите.

Прилагодената изградба одговара на внатрешни столови (IT, HR, објекти, барања за финансии), на нишни работни текови каде тикетот е всушност работа со специфични чекори, и на тимови што сакаат барањата да се поврзани со други податоци што веќе ги чуваат. Исто така избегнува цена по агент кога многу луѓе повремено работат на тикети. Водичот за внатрешна алатка ја опфаќа таа категорија пошироко.

Градење со Mythex

Во Mythex го опишувате helpdesk-от во разговор, го прегледувате во жив преглед и го објавувате за вашиот тим. Тикетите живеат во Postgres база на податоци што агентот ја додава кога податоците треба да се зачуваат, а прилозите одат во датотечното складиште на проектот. Најавите за крајните корисници и барателите и сета е-пошта влезна и излезна користат ваши сопствени даватели — Mythex нема вграден производ за најава или е-пошта за крајни корисници; рецептот за испраќање е-пошта го покажува пристапот. Соработниците можат да помогнат во градењето преку заедничко работно место, без такси по место на самиот Mythex.

За почетна порака, пробајте ги шаблоните редица за internal барања или следач на грешки, и поврзете го helpdesk-от со база на знаења, за честите прашања да се одговараат сами.

Прашања

Кои се основните функции на систем за тикети?

Начин за создавање тикети (формулар или е-пошта), заедничка редица со статус и приоритет, доделување на агент, низа на разговор со јавни одговори и приватни белешки, и пребарување. Сè друго — цели за одговор, готови одговори, извештаи — се надградува врз тие основи.

Може ли прилагоден helpdesk да прима тикети по е-пошта?

Да, но потребен ви е давател на е-пошта што може да прима пошта и да ја препраќа секоја порака до вашата апликација како webhook. Одговорите мора да ја носат референцата на тикетот за да се поврзат со вистинскиот тикет наместо да создаваат нови.

Дали интерен IT или HR helpdesk треба да се гради или да се купи?

Внатрешните столови за барања се добар случај за прилагодена изградба: обемот е предвидлив, категориите се специфични за вашата компанија и вие контролирате кој што гледа. Поддршка за клиенти во голем обем обично оправдува посветен производ.

Какви статуси треба да имаат тикетите?

Одржете ги кратки: нов, отворен, чека на клиент, решен и затворен покриваат повеќето тимови. Додајте „на чекање“ само ако често чекате трета страна. Секој дополнителен статус е уште една работа што агентите ја поставуваат погрешно.

Mythex · Pricing · Градете што било со AI · Шаблони за веб-страници и апликации · Mythex во споредба · Речник за градење апликации со AI · Бесплатни алатки за градење апликации со AI · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)