HelpDesk

Terminoloji
HelpDesk projelerinin yapısına karar verin
Posta kutusunu Kolay Redmine'ye bağlama
Proje yapılandırması nasıl kurulur
Proje yapılandırması nasıl kurulur - ayrıntılar
Bilet işleme ile nasıl çalışılır
Posta şablonları nasıl yapılandırılır
Genel ayarlar nasıl yapılandırılır
"Reaksiyona ihtiyaç" filtresini filtreleyin
Yardım Masası kullanıcıları
köşe durumları

Bu talimatlar, Yardım Masası'nı kullanıcı arayüzünden yapılandırmak için tüm adımlardan geçecektir. Proje ayarları aracılığıyla posta kutularını bağlamaktan Easy Redmine'e, panolarda ince ayar yapmaya kadar. Bu, cron'u (veya sunucu tarafında zamanlanmış görevleri) yapılandırmak için teknik bir kılavuz değildir. HelpDesk'in çalışması için Cron'un önceden yapılandırılmış olması gerekir. Cron ayarlamak için talimatlar okuyun.

 

0 Terminoloji

İlk önce aşağıdaki kılavuzda kullanılan terimler sözlüğü ile başlayalım.

posta kutusu - Alınan e-postaların ilgili HelpDesk projelerinde çağrılara işlendiği, Easy Redmine'e bağlı bir e-posta adresi
Bilet - bir posta kutusunda alınan bir e-postadan oluşturulan görev veya bir HelpDesk projesinde müşteriler tarafından dahili olarak oluşturulan bir görev
Yardım Masası projesi – biletlerin oluşturulabileceği HelpDesk'e bağlı bir proje
Alan adı - bir e-posta adresinin ikinci kısmı. Örneğin, worker.Joe@client.com alan adındaki e-posta adresinden etki alanı yalnızca client.com
Anahtar kelime – kelime veya içinde bulunan bir sözcük dizisi posta konusu
SLA - hizmet seviyesi anlaşması. Kolay Redmine'da kullanılan basitleştirilmiş anlamıyla, müşteri tarafından gönderilen biletlere şirket tarafından tepki vermek için zaman sözleşmesi yapıldı. Saat cinsinden hesaplandı
Orijinal e-posta – Biletin oluşturulduğu HelpDesk posta kutusuna gönderilen e-posta
Şebeke - bu şartlar biletlerle çalışan destek görevlisi için kullanılacaktır.

 

1 HelpDesk projelerinin yapısına karar verin

Tüm biletler için tek bir projeye sahip olmak veya HelpDesk posta kutularını farklılaştırmak, hatta farklı müşteriler için özel projeler yapmak isteyip istemediğinize bağlı olarak, herhangi bir konfigürasyon başlamadan önce projelerin yapısına karar vermeniz gerekir. Bu karar, bu kılavuzda listelenen bazı diğer adımları etkileyecektir.

İşte olasılıklar şunlardır:

1.1 Tüm biletler için tek proje

E-postaları tek bir posta kutusundan toplayan tek bir projeniz olacaksa, karar vermeniz gerekmez >> Posta kutusuna gönderilen tüm e-postalar aynı projede bilet yaratır.

Örnek E-posta: Tüm müşterileriniz support@mycompany.com adresine destek isteği gönderiyor

Bu projenin hangi seviyede olduğu önemli değil, temelde proje yapınızın herhangi bir bölümünde kendi hayatını yaşıyor. Ancak tek bir proje ile başlayıp daha sonra HelpDesk'i genişletmeye devam etmeyi planlıyorsanız aşağıdaki seçenekleri görmelisiniz.

1.2 Bir posta kutusu, daha fazla HelpDesk projesi

Örnek E-posta: Support@mycompany.com posta kutusunu kullanıyorsunuz. Alınan tüm e-postalar genel bir projeye gider. Ancak özel bir projeye ve özel koşullara sahip bir müşteriniz var> client.com etki alanından gelen e-postalar özel projede işlenir.

Elbette, bu şekilde ayrılmış daha fazla müşteriniz olabilir. Bu durumda, proje yapısı şöyle görünebilir:

Diğer bir seçenek ise ilk seviyede Default HelpDesk projesinin ve onun altında özel projelerin bulunmasıdır.

Bazen kullanılabilecek farklı bir yol ise bir yapıdır:

> Müşteri1
>> Ticaret için proje
>> Uygulama projesi
>>Yardım Masası Projesi

> Müşteri2
>> Ticaret için proje
>> Uygulama projesi
>>Yardım Masası Projesi

Ancak, çeşitli sorunlardan bazı toplu listeler, istatistikler veya özetlere bilet toplamayı planlıyorsanız bu önerilmez.

1.3 Daha fazla posta kutusu, özel müşteri projesi yok

Örnek E-posta: Support@mycompany.com, info@mycompany.com, it@mycompany.com posta kutularını kullanıyorsunuz ve e-postalar yalnızca posta kutusuna göre sıralanıyor, değil gönderene göre.

Bu durumda, 3 projelerini aynı seviyede ve muhtemelen hepsini kapsayan ana bir projenin altında alabilirsiniz.

Bu projeler tamamen ilişkisiz olabilir ve kuruluşunuzun bölümlerine ayrılabilir, farklı proje ağaçlarında olabilir (farklı üst projeler altında).

1.4 Özel müşteri projeleri ile daha fazla posta kutusu

Mevcut Easy Redmine HelpDesk işlevi, istemcileri gönderen ve alıcı posta kutusu kombinasyonu ile değil, yalnızca gönderen tarafından ayırmaya izin verir.

Örnek: Support@mycompany.com, info@mycompany.com, it@mycompany.com posta kutularını kullanıyorsunuz. Domain client.com adresinden destek isteği gönderen özel bir müşteriniz var

Önerilen yapı şudur:

Genel olarak proje yapısına döndüğümüzde, yapılması gereken başka şeyler var. HelpDesk işlemeyi kuruluşunuzun farklı bir departmanıyla (örneğin geliştirme) entegre etmeyi hedefliyorsanız, HelpDesk projelerini proje yapısında biraz daha derinleştirmeyi düşünebilirsiniz.

Doğru proje yapısı, işletmenizin daha fazla aşamasında çeşitli raporlar, listeler ve istatistikler oluşturmanıza olanak sağlar.

 

2 Posta kutusunu Easy Redmine'e bağlama

Artık HelpDesk bileşenlerinin gerçek kurulumuyla başlayabiliriz. Easy Redmine işlem posta kutularına sahip olmak için aşağıdaki şekilde bağlanmaları gerekir.

2.1 Yönetim >> Yardım Masası >> Tüm Posta Kutuları >> Posta Kutusu Ekle

2.2 Posta kutunuzun geçerli kimlik bilgilerini girin – Test Et'i tıklayın Kolay Redmin'in posta kutusuna ulaşabilmesini sağlamak için

Ayar notları:

• Aktif - posta kutusu, yeni okunmamış mesajlar için Easy Redmine tarafından düzenli olarak taranır. Devre dışı bırakılırsa, Easy Redmine posta kutusunu kontrol etmez. Ancak posta kutusunu ileride kullanmak üzere Easy Redmine'de tutabilirsiniz.
• Farklı gönderen kullan - posta sunucusundaki kullanıcı posta kutusuyla aynı olmadığında (örneğin, HelpDesk-mail-user). Kullanıcı tarafından temsil edilen geçerli malibox'ı buraya girin.
• SSL - posta sunucunuzda bir SSL sertifikası kullanıyorsanız
• OAuth'u etkinleştir – OAuth 2.0 protokolü, yüzlerce tanınmış hizmet tarafından alternatif bir kimlik doğrulama yöntemi olarak kullanılmaktadır. HelpDesk'in posta kutusuna gelince, şu anda desteklenen harici bir uygulama kullanarak gönderenin kimlik bilgilerini doğrulamak için kullanılabilir. Google Çalışma Alanı (eski adıyla G Suite) ve microsoft Değişim hesaplar. Her alana tam olarak ne gireceğinizi bilmek için diğer uygulamanın OAuth 2.0 belgelerini okumanız gerekir. Elbette, site URL'si, istemci kimliği, istemci sırrı, yetkilendirme URL'si, belirteç URL'si, kapsam vb. gibi gerekli bilgileri bulmak için diğer uygulamaya yönetici erişiminizin olması gerekir.
  
• Dosya - Easy Redmine'ın okunmamış e-postalar için yalnızca belirli klasörleri kontrol etmesini istiyorsanız.
• Başarıyla hareket – bir e-posta Easy Redmine tarafından doğru bir şekilde işlenirse (bilet oluşturuldu), oraya taşınır
• Başarısızlıkta hareket – bir e-posta yanlış işlenirse (bilet oluşturulmamışsa), oraya taşınır

Bağlantıyı test ettikten sonra Kaydet'e tıklayın.

2.2.1 Microsoft ve Google hesapları için OAuth 2.0 kimlik bilgilerini nerede bulabilirim?

Easy Redmine'i OAuth 2.0 protokolünü kullanarak bir Google Workspace hesabına bağlamak için, şu adreste bir hesap oluşturmanız gerekir: Google Bulut Platformu, orada verilen gerekli kimlik bilgilerini alın ve bunları uygulamamızdaki posta kutusu ayarlarına kopyalayın. Bazı yararlı talimatlar bulunabilir okuyun.

Easy Redmine'i OAuth 2.0 protokolünü kullanarak bir Microsoft Exchange hesabına bağlamak için, şu adreste bir hesap oluşturmanız gerekir: Microsoft Azure portal, orada verilen gerekli kimlik bilgilerini alın ve bunları uygulamamızdaki posta kutusu ayarlarına kopyalayın. Bazı yararlı talimatlar bulunabilir okuyun.

Erişim belirteçlerinin sınırlı bir ömrü vardır (maksimum 6 ay), sınırsız sayıda oluşturamazsınız. Bu sürenin sonunda posta kutusu çalışmayı durduracak ve yeni bir belirteç oluşturularak uygulamaya yeniden girilmesi gerekecektir.

" biçiminde bir OAuth 2.0 erişim URL'si/kuruluşlar/oauth2/v2.0/yetkilendirme" yalnızca kuruluş içinde uygulamaya erişim etkinleştirildiyse geçerlidir. Aksi takdirde, erişim URL'si şu şekilde olmalıdır: "/[TENANT_ID]/organizasyonlar/oauth2/v2.0/authorize". Doğru ayarlar Bitiş Noktaları bölümünde bulunabilir.

Microsoft Azure'da iki faktörlü kimlik doğrulama (2FA) ayarlandığında, bağlı tüm posta kutularının yenilenmesi gerekir.

2.2.1.1 Hata "Kullanıcı doğrulandı ancak bağlanmadı"

Bunun nedeni, posta kutusunun kaydedildiği seçili Azure kullanıcısının posta kutusuna erişim izni olmamasıdır. Bu durumda, Office 365'i kullanmak için lisanslanması gerektiğinden kullanıcının yönetici olması yeterli değildir. ), Azure'da uygun kapsam iznini alması ve aynı zamanda bu seçeneği devre dışı bırakması gerekiyor.

Çözüm:

• Kullanıcı, erişmekte olduğu posta kutusunun doğrudan sahibi olmalıdır (böylece bunu yapmak için gerekli izinlere sahip olmalıdır).
• Alternatif olarak, o posta kutusuna erişim izni verilen başka bir (lisanslı) kullanıcı da olabilir.

Bir diğer olası sorun da hesabın IMAP yerine POP3 olarak oluşturulmuş olmasıdır. POP3 sistemde OAUTH'u desteklemiyor.

Çözüm:

• Hesabın hem azure hem de Easy Redmine'de IMAP olarak ayarlandığından emin olun.

2.2.1.2 Hata: Microsoft Yardım Masası başarıyla bağlanıyor ancak bir süre sonra çalışmayı durduruyor

Çevrimdışı erişim hakkını etkinleştirmeyi unuttunuz.

2.2.1.3 Kullanım örneği: Birçok posta kutusu, bir süper Yardım Masası kullanıcısı

Microsoft Exchange içinde ayarlanmış birden çok Yardım Masası posta kutunuz varsa ve bu posta kutularının tümüne erişim haklarını tek bir kullanıcıya devretmek istiyorsanız, bunu Microsoft 365 yönetim merkezi » Yönetim merkezleri » Exchange.

Exchange yönetici merkezi bölümüne yönlendirileceksiniz. Burada, Alıcılar » Posta Kutuları sekmesine tıklayın ve erişim hakkını devretmek istediğiniz posta kutusunu seçin. Sağ açılır bir kenar çubuğu açılır ve Delegasyon'u tıklar.

Aşağıda, üzerine tıklanacak bir Düzenle düğmesi bulunan Oku ve yönet (Tam Erişim) işaretine dikkat edin.

Ardından, posta kutusu sahibiyle aynı haklara sahip olan bu posta kutusunun üyesi olan kullanıcıları arayabilir ve ekleyebilirsiniz.

Seçtiğiniz kullanıcı Easy Redmine tarafında Help Desk yönetici haklarına sahip olmalıdır.

2.2.2 Azure Active Directory ile OAuth 2.0 Kimlik Doğrulamasını Etkinleştirme

OAuth 2.0 kimlik doğrulamasını kullandığınızda, bir istemci uygulamasından bir web hizmetine erişim elde edersiniz. Bunu yapma şekliniz, kullandığınız hibeye bağlıdır. Bu eğitimde, Azure Active Directory'deki uygulamalar için istemci kimlik bilgileri verme türünü nasıl yapılandıracağınızı öğreneceksiniz.

2.3 Posta kutusu tarama sıklığını yapılandırın

Posta kutusuna sağ tıklayın ve Ayarlar'ı seçin.

Artık posta kutusu ayarlarına geri döndünüz, ancak ek bir ayar ile. Varsayılan olarak, Her 5 dakika olarak ayarlanmıştır. Ancak bu ayarın her 10 dakikada yaklaşık yapılması önerilir. Easy Redmine'a bağlı çok sayıda posta kutunuz varsa, bu otomatik tarama görevi daha uzun sürebilir ve sunucunuzu aşırı sık taramalarla aşırı yükleyebilir ve bu da tüm uygulamayı yavaşlatır.

Düğme notları:

• Yürüt – posta kutusu taramasını manuel olarak başlatın
• Geçmiş – geçmiş posta kutusu taramalarını görüntüleyin
• Sil – posta kutusunu Easy Redmine taranmış posta kutularından kaldırın
• Devre dışı bırak – otomatik posta kutusu taramasını devre dışı bırak

2.4 Otomatik devre dışı bırakma

Posta kutusunu düzenli aralıklarla işlemek, özellikle birden çok posta kutunuz varsa, sunucu kaynaklarını kullanır. Bu nedenle, posta kutusunun işlenmesini otomatik olarak devre dışı bırakan bir mekanizma uyguladık. 3 kez e-postaların kimliğini doğrulayamadı ve indiremedi. Devre dışı bırak, alanın Aktif kapalı olacaktır. Yine de ayarları doğrulayabilecek, test edebilecek ve etkinleştirebileceksiniz.

Neden? Kaynaklarınızı kurtarmak için. Sunucu neden işlevsiz bir posta kutusuna ping göndermeye devam etsin?

 

3 Proje yapılandırması

Posta kutusu Easy Redmine tarafından bağlandı ve tarandı, ancak şimdiye kadar biletlerin nerede oluşturulacağını belirlemedik. Bir proje HelpDesk'e bağlanmadan önce bilet oluşturulamaz çünkü genel olarak her görev bir proje gerektirir.

Her bölümün amacına göre bu bölüm farklı senaryolara bölünecek.

3.1 Posta kutusu için varsayılan proje

Geçtiğimiz bölüm örneklerinde, projeler bu olurdu Varsayılan Yardım Masası, BİLGİ – genel, BT – genel, DESTEK – genel, yani, gönderenin belirli bir alanı ile sınırlı değildir.

1. Aynı mağazadan satın almak üzere başka bir ürün eklemek için "Yardım Masasına Ekle"Seçili projenin Proje genel bakış sayfasındaki" seçeneği.
   
2. Projenin varsayılan olacağı posta kutusunu seçin.
   
3. Aşağı kaydırın ve İndirim

Tüm HelpDesk proje ayarlarının tam açıklaması bu bölümün devamında yer alacaktır.

3.2 Özel müşteri projesi

Bölüm 1'teki örneklerden, projeler bunlar olacaktır: Bohemia Sun, Trains Francais, Client 123, Client ABC, Client XYZ, Client 1>>Project for HelpDesk, Client 2>>Project for HelpDesk

1. Proje seç
2. Aşağıda vurgulanan alanları doldurun. Ayar notları ekran görüntüsünün altında
   
3. Aşağı kaydırın ve Kaydedin.

Ayar notları:

• Posta kutusu için varsayılan - YAPMAYIN Bu projeyi özel bir müşteri projesi olarak ayarlamak isterseniz herhangi bir posta kutusunu seçin.
• Bu projeye işlenen postalar, etki alanları, anahtar kelimeler - bu bölümdeki tüm ayarlar OR operatör, bunun anlamı en az bir şartın yerine getirilmesi durumunda, bu projede bilet oluşturulur
• E-postayı kimden doldur - Bu seçenek seçildiğinde, yazarın e-postası otomatik olarak yeni bilette doldurulacaktır. Bu seçenek, biletlerin gelen e-postaları işlemek yerine gerçek kullanıcılar tarafından oluşturulduğu projeleriniz olduğunda kullanışlıdır.
• Anahtar Kelime – Bu örnekte, bir e-posta alındığında HERHANGİ HelpDesk posta kutusu tüm dizeyi içerir Müşteri ABC firmasından geliyorum. Bu projeye bilet sıralanacaktır. Aynı anahtar kelime dizesini daha fazla proje için kullanmayın, yalnızca dizedeki veritabanındaki ilk kayıt belirtilen anahtar kelime dizesini kullanır
• Posta veya etki alanı – gelen e-postalar, e-postanın KİMDEN alanında bu değerler için taranır. Bu örnekte, gönderen, mail kutusu clientABC.com ile biten herhangi biri olabilir veya farklı bir e-postaya sahip belirli bir kişi de olabilir, ancak bu projede biletlerinin sıralanmasını istiyoruz.

Tüm HelpDesk proje ayarlarının tam açıklaması bir sonraki bölümde devam edecektir.

ÖNEMLİ: Her iki projenin de yapılması en iyi uygulama değildir. Posta kutusu için varsayılan VE belirli bir posta veya etki alanı için belirtilen. Herhangi bir gönderen bu projede biletlerini yarattığından, bunları belirtmeniz gerekmez. Bu tür bir ayar karışıklığa neden olabilir.

3.2.1 Özel müşteri projesini kapatma ve arşivleme

Böyle bir proje kapatıldığında (aslında salt okunur hale geldiğinde), içinde bilet oluşturmak mümkün olmayacaktır. Dolayısıyla bu proje özel bir müşteri projesi olmaktan çıkacak ve HelpDesk ayarlarında ayarlanan etki alanlarından gelen e-postalar bilinmeyen olarak işlenecek ve genel bir HelpDesk projesine dahil olacaktır.

Aynısı arşivlenmiş projelere de gidiyor.

 

4 Proje konfigürasyonu – ayrıntılar

Artık HelpDesk'te kullanılabilecek proje türlerini farklılaştırdığımıza göre, diğer proje ayarlarını açıklamaya devam edebiliriz. Bir proje HelpDesk'e bağlandıktan sonra, proje HelpDesk konfigürasyon sayfasına girmenin iki yolu vardır.

• Yönetim >> Yardım Masası >> Tüm Yardım Masası projeleri >> Düzenle
  
• Proje ayarları >> Yardım Masası
  

4.1 Temel ayarlar

Ayar notları:

• Tracker – bu projede bu tracker ile yeni biletler oluşturulacak
• Atanan – bu projedeki yeni biletler bu kullanıcıya atanacak
• İş Arkadaşı – bu projedeki yeni biletler bu iş arkadaşlarına sahip olacak (çoklu seçim mümkündür)
• Otomatik bilet güncelleme – iş akışınıza bağlı olarak, açık tutulan, gerçeklere göre çözülmüş bazı biletler olabilir. Bu gibi durumlar için güncelleme yapılmama durumuna ve süresine göre otomatik kapanmayı ayarlayabilirsiniz. Bileti kapatmaya ek olarak, göndericiye biletinin kapatıldığını bildirmek veya ona bilet çözümünden memnun olup olmadığını sormak amacıyla şablondan bir takip e-postası otomatik olarak gönderilebilir.
• Aylık sözleşme saatleri – bu ayar yalnızca müşterilerin aylık belirli sayıda destek saatini önceden ödediği özel müşteri projeleri için kullanılmalıdır.
• Toplu saatler – müşteriyle yapılan sözleşmede, kullanılmayan saatleri önceki aydan sonrakine aktarma seçeneği olabilir. Müşterinin ön ödemeli 10 saati varsa, ancak Mayıs ayında yalnızca 7'sini kullanmışsa, 3 saat Haziran'a aktarılacaktır.
• Kalan saatler – ne kadar kaldı. Kalem düğmesi, kalan saatlerin manuel olarak silinmesine izin verir - 0'a ayarlayın
• Toplu başlangıç ​​tarihi – ön ödemeli dönemin başladığı tarih; tüm takvim ayları için ortak olan bir gün seçilmelidir, yani 1-28. gün
• Toplu dönem – orijinal Sözleşme saatlerine sıfırlanmadan önce saatlerin hangi süre için toplandığı. Çeyrek sonuna kadar hala 13 saat kalmışsa (çeyrek sonu Toplu başlangıç ​​tarihi ile belirlenir), yeni çeyreğe aktarılmazlar. Saatler 10'a sıfırlanacak

Eldeki saatler, projeye zaman girişleri için harcanır. Hangi kesin girişler bu kılavuzda daha fazla açıklanacaktır.

4.2 HDS

Bu, herhangi bir Yardım Masası projesinin önemli bir ölçüsüdür, ancak özellikle SLA ihlalinin cezalandırılabileceği özel müşteri projeleri için. Daha önce bahsedildiği gibi, bir HelpDesk projesine özel olarak kısıtlı erişimi olan müşteriler tarafından e-posta yoluyla veya doğrudan sistem içinden biletler oluşturulabilir. Her iki durumda da SLA ayarında hafif bir nüans vardır.

4.2.1 E-postayla oluşturulan biletler için SLA

Ayar notları:

• Ad – SLA'nın Başlığı (Yardım Masası projesinde daha iyi SLA yönetimi için)
• Anahtar Kelime - e-postayla oluşturulan biletler için SLA ayarlanıyorsa doldurulmalıdır. Bu durumda, e-postanın konusuna dahil edilmişse, SLA'nın özelliklerine bilet verilecek (saat, öncelik, izci) olan belirli bir anahtar kelime vardır.
• Yanıt için saatler – biletin ilk durum değişikliğinin gerçekleşmesi gereken son tarih. Durum değişikliği, biletin onaylandığını ve müşteriye bu konuda bilgi verildiğini gösterir.
• Çözülecek saatler – bileti kapatmak için son tarih >> onu kapalı duruma getirin
• Öncelik – anahtar kelimeyi içeren e-postadan gelen yeni bilet bu önceliğe sahip olacaktır
• İzleyici – anahtar kelimeyi içeren e-postadan yeni bilet bu izleyiciye sahip olacaktır. Bu, örneğin müşteri üründe bir kusur bulduğunda ve bunu standart bir destek talebi olarak değil, doğrudan bir kusur olarak bildirmek istiyorsa yararlıdır. Müşteri bu nedenle örneğin konu ile yazardı kusur – ve biletin HelpDesk yöneticisi tarafından sınıflandırılması gerekmeyecek.
• SLA'yı çalışma zamanına göre sayın - SLA son tarihleri, çalışma dışı günler veya günün saatleri için ayarlanmaz. Bazı SLA'lar yalnızca çalışma saatleriyle sınırlı olabilir, ancak diğerleri 24/7 olarak ayarlanabilir
• SLA çalışma saatleri – SLA için zaman çerçevesi
• Çalışma günleri - hafta sonları, tatiller ve diğer çalışma dışı günlerin kayıtlı olduğu çalışma takvimi

4.2.2 SLA'ların Sıralanması

Daha fazla seviye, anahtar kelime ve anahtar kelime dizileri ile sırayı doğru tutmak önemlidir. Mail konuları, HelpDesk ayarlarındaki sıraya göre anahtar kelimeler için kontrol edilir.

Örnek: "Kritik" ve "Kritik hata" için anahtar kelimeleri tanımladınız, her birinde farklı bir SLA var. E-postalar işlendiğinde iki konunun farklı olacağından emin olmanız gerekir.

Bu durumda SLA'yı "Kritik Hata" nın "Kritik" in üzerine koymanız gerekir. MailBject işlemenin mekanizması basittir:

1. Posta konusundaki "Kritik hata" kelimesini aratın.
2. Yukarıdaki dize konuya dahil değilse, bir sonraki birini arayın, bizim durumumuzda "Kritik"
3. Yukarıdaki dize konuya dahil değilse, başka anahtar kelimeler aramaya devam edin
4. Son SLA, tüm konular için * işaretini kullanan genel (belirtilmemiş seviye için) anahtar kelime olmalıdır

"Kritik hata" dan önce "Kritik" koyarsanız, "Kritik Hata" içeren e-postaların, "Kritik" SLA kapsamına gireceği için yanlış işleneceği anlamına gelir.

---

Genel olarak, daha belirgin anahtar kelime dizgisi, konumu ne kadar yüksek olmalıdır.

Bir müşteri biletindeki SLA ihlal edildi. Bunu kontrol altına aldığınızdan emin olmak için ne yaparsınız? Bu durumda, projelere gidin Ayarlar >> Yardım Masası a tamamen aşağı kaydırın

4.2.3 Kapalı biletler için SLA'yı sıfırlama

Ayrıca SLA bölümünün en üstünde bir ayar göreceksiniz.

Etkinleştirildiğinde, bir zamanlar kapatılan ve müşteriden gelen başka bir yanıtla yeniden açılan biletler, SLA'ları yeniymiş gibi sayılacaktır - müşterinin bileti yeniden açan yanıtı zamanından itibaren.
Örnek: 1234 numaralı Bilet Pazartesi günü 16: 00'da açıldı. SLA 48 saattir => çözümleme süresi Çarşamba 16: 00'ya kadardır. Bilet Salı günü saat 10: 00'da bir operatör tarafından kapatıldı. Müşteri Salı günü saat 14: 00'te daha fazla bilgiye ihtiyacı olduğunu tekrar söyledi. 1234 numaralı bilet artık Perşembe 14:00 için yeni SLA ayarlarına sahip.

Devre dışı bırakıldığında, SLA her zaman biletin oluşturulduğu zamandan itibaren sayılır.
Örnek: İlk senaryodan senaryoda. Müşterinin Salı günü 14: 00 adresindeki cevabından sonra, SLA sıfırlanmayacak ve Çarşamba günü 16: 00 üzerinde kalacaktı. Aynı şey müşteri perşembe günü bileti tekrar açtığında da geçerlidir. Bilet artık gecikmiş olarak vurgulanacak.

Son nottan, bu ayarın yalnızca biletlerin basit olduğu ve çözümlemenin kesin olarak tanımlanabileceği projelerde devre dışı bırakılması gerektiği açıktır, bu nedenle müşterinin tarafındaki biletleri yeniden açmak için hiçbir neden yoktur.

4.2.4 Dahili olarak oluşturulan biletler için SLA

Daha önce de belirtildiği gibi, biletler yalnızca e-postalardan oluşturulamaz. Easy Redmine, müşterilerinize sisteme kısıtlı izinlerle doğrudan erişim olanağı sağlayan (bilet oluşturmak, bilet düzenlemek, haber okumak, ...) gelişmiş bir erişim seviyesi kontrolüne sahiptir.

Giriş yapmış kullanıcılar tarafından standart görevler gibi oluşturulan biletlerin SLA'yı belirlemenin biraz farklı bir yolu vardır. İşlenen e-posta adresi olmadığından, SLA'yı anahtar kelimelere göre belirleyemezsiniz. Aşağıdaki görüntüyü açıklayalım.

Dahili olarak oluşturulan biletler için SLA oluştururken Anahtar Kelimeyi boş bırakın. SLA daha sonra Priority ve Tracker kombinasyonuyla belirlenecektir. Ayarları kaydettiğinizde, Anahtar Kelime kaybolur ve bu SLA'nın dahili olarak oluşturulan biletler için kullanıldığını gösterir. Tracker'ı boş bırakırsanız, yalnızca anahtar kelimeler dikkate alınacaktır.

İş akışını etkin bir şekilde yapılandırarak, proje daha fazlasını içerse bile, istemcilerin yalnızca belirli izleyicilerde bilet oluşturmasını kısıtlayabilirsiniz. Örneğin, istemcilerin yalnızca izleyici HelpDesk Ticket ve Bug'ı kullanmasına izin verebilirsiniz, böylece yalnızca bu izleyiciler için SLA ayarlayabilirsiniz. Diğer tüm izleyiciler, istemciler tarafından gönderilmeyecekleri ve bu nedenle HelpDesk biletleri olarak kabul edilmeyecekleri için SLA ayarı gerektirmez.

4.2.5 SLA Olayları ve Raporları

SLA Raporları, bireysel SLA Olaylarına dayanır. Bu olaylar her bir Yardım Masası bileti başına görüntülenebilir, herhangi bir Yardım Masası biletinin alt menüsündeki SLA Olaylarına göz atmanız yeterlidir. Bir destek talebi yanıtlandığında/çözüldüğünde, diğer bilgilerin yanı sıra, ilk yanıtın gerçekleşmesine kadar gerçekte ne kadar süre (saat olarak) geçtiğini söyleyen SLA etkinliğini buradan kontrol edebilirsiniz ve değeri ile doğrudan karşılaştırabilirsiniz. SLA yanıtının karşılanması (yani ilk yanıt için gereken süre) ve SLA çözümünün yerine getirilmesi (yani çağrı çözümü için gereken süre), söz konusu Yardım Masası projesindeki SLA ayarlarınıza göre. Ayrıca biletin kime ve ne zaman cevaplandığını/çözümlendiğini ve bu biletin hangi projeye ait olduğunu anında görebilirsiniz. Zaman kayıtları pozitif veya negatif bir sembolle (+/-) gösterilir, yani. SLA'nın derlenip derlenmediğini vurgulamak için yeşil/kırmızı renkte.

SLA etkinliği, daha önce değil, müşteriye bir e-posta gönderilerek bir destek bileti gerçekten yanıtlandığında oluşturulur. Bir bilete yorum eklemek, SLA etkinliğinin oluşturulmasına yol açmaz, çünkü böyle bir yorumun yalnızca dahili bir mesaj mı yoksa müşterinin isteğine mi bir yanıt olduğu açık değildir.

Bir destek bileti bir projeden diğerine taşındığında, SLA olayı yeniden hesaplanmaz. Biletin SLA'sı, böyle bir biletin yaratıldığı orijinal projeden kalır. SLA yeniden hesaplaması, yalnızca izleyici veya öncelik değişikliğiyle tetiklenir.

Tüm SLA Olaylarının listesini (genel bakış) görmek için /easy_sla_events adresine gidin veya ana HelpDesk panosunun (/easy_helpdesk) kenar çubuğu menüsünde SLA Raporları menü öğesini tıklayın.

SLA olayları, çeşitli SLA, özel alanlar veya diğer ölçütlere göre kolayca filtrelenebilir.

Genel SLA istatistiklerinde özetlenen tüm SLA Olayları, SLA raporları panosunda bulunabilir. Varsayılan olarak bu pano, ana HelpDesk panosunun üst menüsünde bulunur. Panoyu kullanarak, başarısız SLA yanıtının, başarısız SLA çözümünün ve ortalama ilk kez yanıtın toplam yüzdesini anında görürsünüz. Pano, diğerleri gibi standart bir kişiselleştirilmiş sayfa olduğundan, panoda gösterilen tüm modülleri ihtiyaçlarınıza daha iyi uyacak şekilde özelleştirebilirsiniz.

4.2.6 Bilet SLA raporları

Yukarıdakilere ek olarak, biletlerin üzerinde SLA raporları da yapmak mümkündür.

11plus.2.0 sürümünden itibaren, biletlerin iki yeni alanı vardır:

• İlk SLA yanıtının karşılanması - biletteki ilk SLA etkinliğinden alınır
  
• Son SLA çözümünün yerine getirilmesi - biletteki son SLA etkinliğinden alınmıştır

Nasıl çalışır

Bilet oluşturulur -> Yardım masası operatörü yanıt verir-> SLA olayı oluşturulur -> bu SLA olayından alınan değerler, biletin yukarıda belirtilen özniteliklerine kopyalanır -> müşteri geri yanıt verir -> operatör müşteriye yanıt verir -> yeni SLA olayı oluşturulur - > SLA'nın değeri, bilet özniteliğine kopyaladığı yerine getirmeyi döndürür.

değer nerede

Biletin kendisi en önemli SLA raporlama verilerini içerdiğinden, SLA memnuniyetine ilişkin raporları doğrudan biletlerin üzerinde yapabilirsiniz.
Bazı örnekler:

• Bilet çözümleme başarı oranı
• Zamanında başarısız SLA yanıtı/çözümlü çağrıların mutlak sayısının çizgi grafiği

4.3 Özel üst bilgi ve alt bilgi

Bu ayar, HelpDesk e-posta iletişimiyle, yani e-postayla oluşturulan biletlerdeki iletişimle ilgilidir. Farklı HelpDesk projelerinden gelen e-postaları kurumsal kimlik kullanımı için, şartlar spesifikasyonları ve hatta gizlilik feragatnameleri için özelleştirebilirsiniz.

4.4 Uyarıları

SLA'nın ihlal edilmesini önlemek için, ilgili personele gecikmeli bilet şeklinde tezgâhlanma problemlerini bildiren otomatik uyarıları kullanma olasılığı vardır.

Başka bir Uyarı türü, müşterilerin belirli bir miktarda destek ücreti önceden ödediği projelerde harcanan zamanı izler (4.1 bölümünde açıklandığı gibi).

Ayar notları:

• Destek biletlerinin son tarihini izleyin – daha kesin olmak gerekirse Zamanı SLA'ya göre. Etkinleştirilirse, SLA son tarihi yaklaşırken uyarılar oluşturulur. Aşağıda açıklanan diğer ayarlar
• Zamanında harcanan destek biletlerini izleyin - belirli ön ödemeli aylık saatlere sahip projelerde harcanan zamanın izlenmesi
• Bir alıcının ayarlanması gereken uyarıların listesi – bunlar, yalnızca bir e-posta adresi girilmesi gereken ve bildirimlerin gönderilmesi gereken önceden yapılandırılmış uyarılardır.
• Yapılandırılan uyarıların listesi – eksik parametresi olmayan uyarılar
• Her uyarıyı tıkladığınızda, önceden yapılandırılmış parametreleri düzenleme olanağını göreceksiniz
• Uyarı / Uyarı: bildirimin ciddiyeti
• Destek biletleri bitiş zamanı - uyarı saatleri SLA'nın son teslim tarihini çözmesi (bilet kapanışı)
• Destek biletleri yanıt saatlerine kadar - uyarı, SLA yanıt son tarihini izler (ilk durum değişikliği)
• Destek biletleri ön ödemeli saatler – projede ön ödemeli aylık saatlerin harcandığını uyarı saatleri

Son uyarıda izlenen saatler, proje HelpDesk ayarlarında belirtilen izleyicilerde bulunan biletlerde oturum açmış olanlardır.

Örnek: Proje için varsayılan izleyici HelpDesk Ticket'tır. İzleyici Hatası için bazı SLA'lar yapılandırılmıştır. Proje, biletlerde kullanılmayan diğer izleyicileri (Görev, Özellik geliştirme) içerir. Bu durumda ön ödemeli saatler sadece HelpDesk Ticket ve Bug için geçerlidir. Bu uyarı için diğer izleyicilerde harcanan zaman dikkate alınmaz.

4.5 Güncelleme/silme

Güncelle – projenin HelpDesk ayarlarında yapılan değişiklikleri kaydedin
Sil – projeyi HelpDesk'ten kaldırın. Bu, projenin bir bütün olarak silinmesi anlamına gelmez, yalnızca projenin HelpDesk ile bağlantısını kaldırın.

 

5 Bilet işleme

Şimdiye kadar açıklanan çok sayıda ayardan sonra, başka bir ayar grubuyla geri dönmeden önce bazı pratik sonuçlara bakmanın zamanı geldi. Biletlerin nasıl çalıştığını göstermek ve bazı özellikleri atlamak için basit bir kullanım durumuyla başlayacağız. Daha sonra açıklanacaklar.

5.1 E-postayla oluşturulan biletler

E-posta ile oluşturulan biletlerin doğru kullanımı için, o standart alanları kontrol etmeniz gerekir "e-posta" ve "e-posta cc"aktif. Kontrol edebilirsiniz. Daha fazla » Yönetim » İzleyiciler » HelpDesk bileti » Standart alanlar. Bu standart alanlar eksikse, yönetici tarafından devre dışı bırakılmış olmalıdır.

5.1.1 E-posta Easy Redmine tarafından işlenir ve belirlenen projede bilet oluşturulur

Notlar:

• e-posta adresi: Biletin oluşturulduğu e-postanın göndericisi
• Görevin oluşturulduğu posta kutusunun belirtilmesi
• SLA değerleri – ihlal edilirse kırmızı renkle vurgulanır
• Ayrıştırılmış e-posta – Bu, e-postanın metin içeriğidir. Performans optimizasyonu nedeniyle resimler doğrudan bu görünümde gösterilmez (özellikle bilette çok sayıda yanıt varsa ve her biri şirket logolu bir imza içeriyorsa, her birinin boyutunun artması nedeniyle biletin yüklenmesi çok uzun sürebilir) sonraki cevap)
• Tam e-posta ek olarak mevcuttur - orijinal e-posta resimler içeriyorsa, doğrudan Easy Redmine'de görüntüleyebilirsiniz.
  

5.1.2 Bir yanıt yazın ve bileti güncelleyin

SLA yanıtını karşılamak için, durumu değiştirmeli ve müşteriye ilk kez yanıt vermeliyiz. Aşağıdaki örnekler için, bilet iletişimi hakkında açık fikirli olun, sadece iletişimin teknik olarak nasıl çalıştığını göstermek içindir.

Yönetici müşteriye bileti alma konusunda bir cevap yazdı, bir operatöre atadı ve durumu değiştirdi. Yanıt, kutuyu işaretlediğinizde müşteriye (e-posta ile) gönderilir.

Şablondan müşteriye hızlı e-posta gönder

İstemciye bir e-posta göndermek için iki seçeneğiniz vardır. Bir HelpDesk biletini güncellerken, bileti gönderen için yanıtınızın e-posta şablonunu seçmenize olanak tanıyan "Şablondan müşteriye hızlı e-posta gönder" seçeneği vardır. Bir şablon seçildiğinde, e-posta anında gönderilir ve böylece başka bir işlem yapılması gerekmez. Hiçbir şablon seçilmediğinde, yine de şablonu seçme ve bir sonraki adımda e-posta göndermeyi onaylama seçeneğiniz vardır (alt kısımdaki "Müşteriye e-posta gönder (önizlemeli) onay kutusunu işaretleyin ve kaydedin). Bunun amacı özelliği, esas olarak müşterilere e-posta gönderirken zamandan tasarruf etmektir.

5.1.3 Harici e-postaya bir güncelleme gönderin (e-posta adresi)

Kaydet seçeneğine basarak, bilette yapılan güncellemeleri kaydedecek ve cevabı müşteriye gönderme diyalogu alacaksınız.

Notlar:

• Posta şablonu – yapılandırılmış e-posta şablonlarınız varsa, birini seçebilirsiniz. Veya duruma göre bir şablon önceden ayarlanacaktır. Bu özellik daha sonraki bölümlerde açıklanacaktır.
• Posta gönderen – bu, istemciye FROM olarak gösterilecektir. Bu alanın popülasyonunun ayarı daha sonraki bölümlerde açıklanacaktır.
• Posta konusu – posta şablonuna göre özel veya önceden ayarlanmış. Varsayılan olarak, bilet Konusu tarafından doldurulur.
• Posta alıcısı – orijinal e-postanın göndericisi. CC veya TO'da orijinal e-postanın başka alıcıları varsa, onlar da bu alana eklenecektir.
• Posta yanıtı – bu her zaman orijinal e-postanın gönderildiği HelpDesk posta kutusudur
• Posta kopyası – başka alıcılar ekleyebilirsiniz
• Posta gövdesi – bir şablon seçilmediyse, biletle ilgili son yorumdan ve orijinal e-posta metninden oluşacaktır. İçerik düzenlenebilir.
• Ekler – e-posta ile gönderilecek ekleri seçebilirsiniz. Bileti güncellerken yüklediğiniz daha yeni e-postalar veya yeni dosyalar olabilir.
• Posta gönder – e-posta tüm alıcılara gönderilir
• Posta göndermeyin – biletin ayrıntılarına geri döneceksiniz

Bilet detaylarına baktığımızda, SLA yanıtının kaybolduğunu görüyoruz, çünkü yapıldı.

5.1.4 Müşteri yanıt verir – e-postaların bir biletle nasıl eşleştirildiği

Müşteri cevabınızı aldı ve cevap verdi. Cevap, isimsiz bir kullanıcının (sisteme kayıtlı olmayan bir kullanıcı) yorumu olarak eklenecektir.

Müşterinin cevabının doğru bilet yolunu nasıl bulduğunu burada açıklayalım.

Önceki adımda, yönetici müşteriye harici posta gönderdiğinde, e-posta (tüm e-postaların yaptığı gibi) biletin kimliğiyle birlikte gizli bir başlık içeriyordu. E-postayı yanıtlayarak, bu başlık müşterinin yanıtında da yer aldı ve bu nedenle HelpDesk bunu tanımladı ve yanıtı aynı kimlikle bilete ekledi.

İşte alınan tüm e-postaların sistemdeki biletlerle eşleştirilmesi.

1. Görev kimliğinin kaydedildiği gizli e-posta başlığı
2. E-postanın konusu, "#" ve görev kimliğinin bir arada aranması
3. Bu bulunmazsa, konu yalnızca bir numara için aranır

Buna göre, müşteri bir HelpDesk posta kutusuna yeni bir e-posta yazsa ve konuya bilet numarasını (görev kimliği) eklese bile, yine de eşleştirilecektir. Aşağıdaki örnekte olduğu gibi.

HelpDesk posta kutusuna yeni e-posta:

Biletteki sonraki not:

5.1.5 Son yanıt – bilet kapatılır

Operatörden, biletin kapatıldığı son bir cevap. Bilet kapatıldıktan sonra, çözüm için SLA da bilet detayından kaybolacaktır.

Müşteri tekrar cevap verirse, bilet tanımlanmış bir duruma yeniden açılacaktır (bu ayar daha ayrıntılı olarak açıklanacaktır).

5.1.6 Bilet sahibi alanı

Bilet sahibi alanı, HelpDesk biletleriyle kullanılması amaçlanan isteğe bağlı standart bir alandır. Açılır listesi ile önceden oluşturulmuş tüm dahili kullanıcılardan bir kullanıcı seçmenize olanak tanır ve bu kullanıcı biletin sahibi olarak kabul edilir. Alan, sahip olmanız gerekebilecek herhangi bir izleyici için etkinleştirilebilir veya devre dışı bırakılabilir (Yönetim » İzleyiciler » Yardım Masası biletine gidin » alanı işaretleyin ve kaydedin). Varsayılan olarak, Bilet sahibi alanı devre dışıdır, bu nedenle Yardım Masası yöneticileri, belirli bir izleyici için bunu etkinleştirmek üzere Yönetim'e gitmelidir. HelpDesk biletlerinde bu alandan yola çıkarak HelpDesk yöneticileri, bilet sahibine göre ne kadar biletin alındığını, kapatıldığını/çözüldüğünü veya güncellendiğini kolayca görebilir. Dolayısıyla bu, HelpDesk içgörülerini (panolar, istatistikler) ve tanımlanmış bir süre için raporları önemli ölçüde iyileştirebilir/basitleştirebilir. İş akışı ayarları ve Eylem düğmeleri, tıpkı diğer standart veya özel alanlar gibi Bilet sahibi alanına da uygulanabilir.

5.1.7 E-posta adresi, çeşitli veri kaynaklarından bilgi seçimi

Alanlarda e-posta için ve e-posta cc veri kaynaklarından e-postaları arama yeteneği eklendi:

• Kişisel kişiler (CRM)
  
• Paydaşlar
  
• Hesaplar (CRM)
  
• Yardım Masası kullanıcıları (Yardım masası)
  

Bu özellik varsayılan olarak devredışı bırakılmıştır. Etkinleştirmek için Yönetim >> Eklentiler >> seçeneğine gidin. E-posta alanı otomatik tamamlama - Özelliği düzenleyin ve etkinleştirin E-posta alanı otomatik tamamlama ve veri kaynaklarına ihtiyaç vardı.

Bu özellik, veri kaynaklarından herhangi birini etkinleştirmeden kullanıcılar arasında yerel olarak arama yapar.

Nasıl çalışır

Etkinleştirilirse, E-posta adresi ve cc görev alanları otomatik tamamlama görevi görür.

5.2 Dahili olarak oluşturulan biletler

İstemci, çağrıları doğrudan sisteminizden gönderirse, iş akışı, başka herhangi bir görevle çalışıyormuşsunuz gibi tanımlanabilir. İstemcinin HelpDesk Ticket veya Bug oluşturmasına izin vereceksiniz. Başlangıçta varsayılan durumda olacaklar (çoğu zaman basitçe Yeni olarak adlandırılırlar). Ardından, müşteri ve operatör arasındaki iletişim, bir dizi bilet güncellemesi ve asistanı değiştirmekiletişimde tüm kullanıcıları aktif tutmak için gereklidir. SLA'lar, e-posta ile oluşturulan bilette olduğu gibi izlenir. Yanıt: Durum değişikliği; Çöz: Biletin kapatılması.

5.3 REST API aracılığıyla oluşturulan biletler

REST API aracılığıyla (örneğin bir web formundan) oluşturulan görevlerin/biletlerin e-postadan oluşturulan HelpDesk biletleri gibi görünme olasılığı vardır. sadece gönder"easy_helpdesk_mailbox_username"parametresi, örneğin: sayı [easy_helpdesk_mailbox_username] = 'support@company.com ". Bu, yeni oluşturulan görevin verilen e-posta adresinden bir HelpDesk bileti gibi görünmesine neden olacak, SLA ayarları buna göre uygulanacak ve göndericiye bir teşekkür mesajı gönderilecektir.

 

6 Posta şablonu

Son bölümde zaten önceden tahmin edilmişti, ancak işlemenin uygun bir açıklaması olmadan, anlaşılması şimdi olduğu kadar kolay olmazdı. Tanıtmadığımız son HelpDesk menü öğesi.

E-posta şablonları, şirketinizi profesyonelce işleyen biri olarak tanıdıkları müşterilerle iletişimin belirli bir düzeyde otomatikleştirilmesini ve resmi hale getirilmesini sağlar.

Mail şablonlarının önemli bir özelliği Posta kutusu başına yapılandırılmış support@mycompany.com adresine gönderilen e-postalar için IT@mycompany.com posta kutusundan bir şablon kullanamazsınız.

6.1 Bir posta şablonu oluşturma

Etkili iki tür posta şablonu vardır: otomatik ve standart şablon. Farklı yapılandırılmadıkları için her iki vakayı bir kerede açıklayacağız.

6.1.1 Yeni şablon ekle

6.1.2 Temel nitelikler

Ayar notları:

• Posta kutusu için kullan – bu şablon hangi posta kutusunda kullanılabilir
• Görev durumu – bu duruma göre, yanıt harici bir postaya gönderilirken şablon diyalogda önceden doldurulacaktır (bkz. bölüm 5.1.3.)
  • Şablonu e-postadan yeni oluşturulan biletlere otomatik olarak kullanmak için, durumu varsayılan olana ayarlayın ( yönetim >> görev durumları). Aslında, bir e-postadan bir bilet oluşturulduğunda, bu şablona göre otomatik olarak derhal gönderilecektir. Müşteriye, biletin yaratıldığını ve sonraki adımların ne olacağını onaylamak için kullanılabilir.
  • Durumu boş bırakabilirsiniz, bu durumda posta gönderme iletişim kutusunda hiçbir zaman otomatik olarak önceden doldurulmaz, ancak kullanıcılar manuel olarak seçebilir
• Konu – konu ne içerecek
• Otomatik yanıta görev kimliğini eklemeniz önerilir – aynı müşteriyle birden fazla biletiniz varsa, müşteriyle konuşurken bunları daha iyi ayırt edebilirsiniz.
• Müşterinin orijinal e-postasını kullanılan asıl konuyu da kullanabilirsiniz.

6.1.3 Dinamik belirteçler ve posta gövdesi

Müşteriye özel bilet bilgileri sağlamak için dinamik belirteçler kullanılabilir. Bir şablonda, aşağıdakilerden biri olarak girilir ve müşteriye gönderilen e-postada, biletin gerçek değeri ile değiştirilir.

Otomatik bir basit örnek.

6.1.4 Önemli dinamik belirteçler

Posta şablonlarını etkin bir şekilde kullanacaksanız, simgeyi eklemek gerekir. % Task_note% şablona. Bilene en son eklediğiniz yorumu kullanacak ve şablondaki diğer metinlerle çevreleyecektir.

Giden e-postalara şirket imzası eklemek için belirteci kullanın. % User_signature%. Kullanıcının profilinde ayarlanabilecek mevcut kullanıcının (imzayı güncelleyen) HTML imzasını kullanacaktır.

Örnek: Destek operatörünün yorumlarını, biletin üzerinde harcanan toplam süreyi ve kullanıcının şirket imzasını içeren basit bir şablon hazırlayalım.

Şablon böyle gözüküyor.

Bu şekilde operatör yorum bilet güncellemesini yazar.

Ve bu şablona göre gönderilen e-posta olacaktır.

Not: E-posta şablonlarını belirli bir projede özel başlık ve altlıklarla birlikte kullanırken (Bölüm 4.3.), Proje başlığı ve altbilgisi yalnızca e-posta şablonuna değil, yalnızca e-posta şablonunun eklediği kısmı müşteriye gönderir. son yorum.

6.2 Varsayılan e-posta şablonu

Bir HelpDesk e-posta şablonunu şu şekilde seçmek mümkündür: Varsayılan. Bu, bir müşteriye yorum gönderirken, bir şablonun önceden seçilme olasılığının daha yüksek olduğu anlamına gelir (destek operatörü için daha az manuel iş bırakır).

Davranış aşağıdaki gibidir:

Önkoşullar

• bir e-posta şablonu varsayılan olarak ayarlanabilir
• her e-posta şablonunun bağlantılı bir posta kutusu olmalıdır
• sisteminizde daha fazla posta kutunuz olabilir
• e-posta şablonu belirli bir duruma bağlı olabilir (ancak gerekli değildir)

durumlar

• bir bilet manuel olarak oluşturulur (e-postadan değil) - durumuna göre şablon seçilidir; bulunamadıysa, varsayılan şablon önceden seçilidir
• varsayılan e-posta şablonunun kullanıldığı posta kutusundan farklı bir posta kutusundan bir bilet oluşturulur - bu posta kutusuna sahip şablon duruma göre önceden seçilir (şu anda olduğu gibi) => şablon atanmamış bir durum kullanılırsa, hiçbir şablon otomatik olarak seçilmez
• varsayılan şablonun kullanıldığı posta kutusundan bir bilet oluşturulur – şablon duruma göre önceden seçilir – böyle bir şablon bulunamazsa, varsayılan şablon önceden seçilir

SLA verilerini gizle

Seçilen kullanıcı türleri için SLA yanıtı ve görev detayındaki çözme süresi hakkındaki bilgiler gizlenebilir (Yönetim >> Kullanıcı türleri >> Düzenle).

SLA ayrıca belirli kullanıcılar için gizlenebilir (Yönetim >> Kullanıcılar >> Düzenle).

Kullanıcı veya kullanıcı türüyle ilgili ayarlardan en az biri etkinleştirilmişse, kullanıcı SLA'ları görmez.

HelpDesk e-postalarının üstbilgisi ve altbilgisi

E-posta bildirimlerinin (Yönetim >> Ayarlar >> E-posta bildirimleri) global olarak ayarlanmış üstbilgisi ve altbilgisi artık HelpDesk'ten gönderilen e-postaların bir parçası olmayacak.

HelpDesk e-postalarına üstbilgi ve altbilgi eklemek için belirli bir projenin HelpDesk ayarlarına gidin (Proje >> Ayarlar >> HelpDesk).

Veritabanı yapılandırmasını doğrulayın

Yükseltme testleri, daha önce doğru şekilde işbirliği yapan iki yapılandırmada bir uyumsuzluk ortaya çıkardı.

Hem veritabanı sunucusunun hem de config / database.yml öğesinin aynı (önerilen) utf8mb4 ayarına sahip olduğundan emin olun.

1) etc / my.cnf

character_set_server = utf8mb4
collation_server = utf8mb4_unicode_ci

2) config / database.yml

Üretim:
  bağdaştırıcı: mysql2
  veritabanı: kolay
  ana bilgisayar: 127.0.0.1
  kullanıcı adı: kolay
  şifre: "EASY_STRONG_PASSWORD"
  kodlama: utf8mb4

Bunlar hizalanmazsa, otomatik tamamlama alanını kullanamazsınız, örneğin Projeye atla, Atama seçimi, Filtreler, vb.

Son olarak, tüm tabloları kodlamayı doğru ayarlamak için bu komutu çalıştırmanız gerekir.

YOUR_DB_NAME içindeki DB için; yap
  mysql -e dizinindeki TABLO için $ {DB}; tabloları göster; --batch --kip-sütun-isimleri | xargs`; yap
    echo "$ {DB}. $ {TABLE}" dönüştürme
    mysql -e "tabloyu değiştiriniz $ {DB}. $ {TABLE} Karakter setine dönüştür: utf8mb4 harmanla utf8mb4_unicode_ci;"
  yapılmış
yapılmış

YOUR_DB_NAME yerine, veritabanınızın adını girin.

not: Doğru veritabanı yapılandırması, herhangi bir web uygulamasını kusursuz çalıştırmak için genel bir gereksinimdir. Bu sadece Easy Redmine'ın bu yeni sürümünün belirli bir şartı değildir.

Özel tasarım sonları (CSS yok)

Özel markanız (logo, renkler, arka plan) varsa ve yükseltmeden sonra bozulduysa – tüm stiller eksikse, site bozuk görünüyorsa, kolayca düzeltebilirsiniz.

/ Easy_theme_desings sayfasına gidin >> tasarımınızı bulun >> yeniden derleyin >> tekrar yükleyin. Tasarımı onaracak ve stilleri yükleyecektir.

 

7 Genel ayarlar

Artık tüm kullanılabilirliği gözden geçirdiğimize göre, açıklanacak kalan ayarların kalanını bitirebiliriz.

Ayar notları:

• Gönderen – istemciye verilen bilet yanıtlarında FROM olarak listelenen e-posta (Bölüm 5.1.3 ile ilgili olarak)
  • Mevcut oturum açmış kullanıcı – bileti güncelleyen kullanıcı
  • Posta bildiriminden varsayılan – sistemden kullanıcılara standart bildirimler göndermek için kullanılan e-posta. Yerleştir Yönetim >> ayarlar >> e-posta bildirimleri
  • Posta kutusu adresi - istemciden orijinal postayı alan e-posta
  • Bu ayar, son onay kutusuna gevşek bir şekilde bağlıdır Özel gönderene izin ver - etkinleştirilirse, proje Yardım Masası ayarlarında gönderen olarak özel bir e-posta ayarlayabilirsiniz. Bir projenin ayarda doldurulmuş bir e-postası varsa, Gönderen ayarını geçersiz kılar
• Görev özniteliklerini güncellemeyi etkinleştir – etkinleştirilirse, biletteki belirli öznitelikleri e-posta ile değiştirmek mümkündür. Örneğin, yazarak öncelik: Yüksek Posta gövdesinde önceliği buna göre değiştirirsiniz. Bu oldukça gelişmiş bir işlevdir ve istemcilerle birlikte kullanılması önerilmez.
• Otomatik oluşturulmuş postaları kabul edin – örneğin haber bültenleri
• Alınan e-postaların CC'sini yoksay - etkinleştirilirse, CC'deki e-postalar işlenmez ve alanda kullanılmaz "e-postaBiletin "(Bölüm 5.1.3. Posta alıcısı hakkında not)
• Müşteri yanıtından sonra durumu değiştir - bir müşteri bileti güncelleyen bir yanıt yazdığı her zaman, durum buna göre değişecektir. Bu, operatör tarafından bir yanıt gönderildikten sonra biletler kapalı duruma getirildiğinde özellikle yararlıdır. Müşteri ek bir soruyla yanıt vermedikçe, bilet kapalı kalacak ve aktif listelerden gizlenecektir. İstemci yanıt verdiğinde, bilet yeniden açılacak ve etkin açık biletlerin sırasına geri dönecektir.
• Durum olduğunda bilet için SLA'yı askıya al - bunlar, SLA son tarihinin belirlenmediği durumlardır, çünkü bilet müşteriden girdi bekler ve bu olmadan operatörün destek sağlama şansı yoktur
• Durum şu olduğunda bilet için SLA'yı sayın - SLA normal olarak ölçüldüğünde. Bu işlevlerle bilet döngüsünü güzel bir şekilde ayarlayabilirsiniz. Örneğin, operatör müşteriden daha fazla bilgi ister, durumu pasif ve SLA duraklatıldı. Müşteri cevap verdikten sonra durum olarak değiştirilir. danışma SLA, kalan süreye göre, SLA teslim tarihine, yeniden

12. sürümde, Yardım masası başka bir ilginç ölçüm aldı - Biletler destek tarafından çözüldü. Destek ekibinden hiç ayrılmamış toplam bilet sayısını veya oranını bildirebileceksiniz.

Nasıl çalışır

1. Öncelikle Yardım masası >> Yardım masası ayarlarında hangi kullanıcıların destek üyesi olduğunu tanımlamanız gerekir - Destek tarafından çözüldü ayarlar
   
   
   
2. Alt görevler/ilgili görevler için ayarlar, destek tarafından çözülen biletlerin alt görevleri veya ilgili görevleri içerip içeremeyeceğini belirleyecektir.
3. Şimdi yardım masası menüsündeki düğmeye basmanızı öneririz - Yeniden hesapla
   
   Bu, son 90 güne ait biletleri değerlendirecek
4. Son olarak, görev listesine gidin ve filtreyi bulun Destek tarafından çözüldü
   
   

Bu filtre, yalnızca destek üyelerine atanmış biletleri gösterecektir (1. maddedeki ayara göre). 2. maddedeki ayarlara bağlı olarak, alt görevler veya ilgili görevler içeren çağrılar destek tarafından çözülmüş olarak sayılabilir veya sayılmayabilir.

 

8 Filtre "Reaksiyon gerekli"

"İhtiyaç tepkisi", HelpDesk biletlerinin ve CRM vakalarının bir özelliğidir. Varsayılan olarak, bu özellik "Hayır" olarak ayarlanmıştır. Cevap veren kişiye bir bilet / dava tahsis edildiğinde "Evet" olarak değişecektir. bir e-posta mesajı göndererek geri gönderene geri göndermek yerine Müşteri bölgesi veya Kolay Redmine. Böyle bir durumda, bilet / servisin alıcısı değişmeden kalır ve bu nedenle amaçlanan alıcı güncellemenin yapıldığını fark etmeyebilir. Bunu önlemek için, alıcı “Evet” olarak ayarlanmış “Reaksiyona ihtiyaç” özelliğine sahip tüm öğeleri düzenli olarak kontrol etmelidir, böylece kendisine atanmamış olsa bile kontrol etmesi veya cevaplaması gereken yeni bir şey olduğunu kolayca öğrenir. Ya da ihtiyacınız olduğunda kullanabilirsiniz Yanıtladığınız bazı müşteri biletlerini "işaretlemek" için ancak üzerinde hala bazı çalışmalar var ve daha sonra tekrar müşteri bilgilendirmeniz gerekir. Kullanma "filtreden Görevler" modülü ile ana sayfanızda, CRM'ye genel bakış veya HelpDesk'e genel bakış üzerinde aşağıdaki gibi bir kutu oluşturabilirsiniz.

 

9 HelpDesk kullanıcısı (sürüm 11+)

Son yıllarda HelpDesk'e yapılan en büyük eklemeler arasında sözde HelpDesk kullanıcıları var. Amaçları, Easy Redmine'nize Müşteri erişiminin yönetimini basitleştirmektir. Ayrıca, Müşterilerin kendilerinin bilet göndermesini ve operatörlerinizle doğrudan uygulamada iletişim kurmasını çok daha kolay hale getirir.

9.1 Ön koşullar

HelpDesk kullanıcılarının yönetimi izinler altında HelpDesk kullanıcılarını görüntüle/yönet Yönetim >> Roller ve izinler bölümündeki HelpDesk bölümü altında.

HelpDesk kullanıcıları oluşturmaya başlamadan önce kontrol etmeniz gereken diğer bir ayar Yönetim >> Sayfa özelleştirme >> HelpDesk kullanıcıları >> Şablonlara genel bakış'tır. Temel bir "başlangıç" yapılandırmasında mevcut bir sayfa şablonu olmalıdır. olarak ayarlanmış bir şablonun olması önemlidir. varsayılan – bu şablon yeni HelpDesk kullanıcılarına otomatik olarak uygulanacaktır. Aksi takdirde HelpDesk kullanıcılarınız giriş yaptıktan sonra boş bir sayfa ile karşılaşacaktır.

HelpDesk kullanıcı sayfası 3 tip modül içerir:

• Yeni bilet formu – Herhangi bir ayarı yoktur, Müşterilerinizin en üst düzeyde rahatlığı için yerleştirmeniz yeterlidir.
• HelpDesk biletleri – HelpDesk kullanıcısı tarafından oluşturulan biletlerin listesi. Her kullanıcı yalnızca kendi oluşturduğu biletleri görebilir. Bu modül, uygulamadaki diğer tüm "liste" modülleri gibi yapılandırılabilir. Biletlerde HelpDesk kullanıcıları için görünen alanları içerir. HelpDesk kullanıcıları için hem açık hem de kapalı biletleri göstermeyi düşünüyorsanız, bunları ayrı modüller halinde göstermenizi öneririz.
• Duyuru Panosu – Müşterilerle bazı özel bilgileri paylaşmak istemeniz durumunda.

9.2 HelpDesk kullanıcı yönetimi

HelpDesk kullanıcılarının listesi, HelpDesk panosundaki kontrol düğmelerinde ayrı bir öğe olarak mevcuttur.

Tüm nitelikler gereklidir:

• İsim
• Soyisim
• E-posta = Giriş
• Dil
• Proje – bu kullanıcının biletlerinin oluşturulacağı projedir. Burada sadece HelpDesk'e bağlı açık projeler seçilebilir.
• Şifre – kullanıcı oluşturma sırasında, kullanıcının e-postadaki bağlantı aracılığıyla kendi şifresini ayarlayabilmesi için şifre belirteci oluşturma seçeneği içeren bir şifre girmeniz gerekir. Kullanıcı düzenlemesi sırasında şifre değişikliğine kesinlikle gerek yoktur.

Ek izinler:

Her kullanıcıya tüm görevleri görüntülemesi ve yönetmesi için ek izinler verilebilir

Tüm görevleri görüntüle = Yardım masası kullanıcısının aynı proje kapsamında oluşturulan tüm destek taleplerini görmesine olanak tanır

Tüm görevleri yönet = Yardım masası kullanıcısının önceden oluşturulmuş bildirimlerdeki belirli alanları düzenlemesine (Başlık, Açıklama ve ayrıca yeni bir ek eklemesine; ancak eskisini düzenlemesine) olanak tanır.

Kullanım örneği

Bir müşterinin Yardım masanızda biletleri için özel bir projesi var. Yardım masası portalına giriş yapan ve bu müşteri adına destek bildirimi gönderen daha fazla kullanıcı var. Bu kullanıcılardan birinin gönderilen tüm destek taleplerini görmesi gerekiyor çünkü onun rolü sunduğunuz hizmeti değerlendirmeyi gerektiriyor.

9.2.1 CSV içe aktarma

11plus.2.0 sürümünden itibaren, yardım masası kullanıcılarını CSV aracılığıyla içe aktarmak mümkündür. Lütfen bu seçenek hakkında danışmanınızla iletişime geçin.

9.3 HelpDesk kullanıcısı olarak oturum açma

HelpDesk kullanıcıları, normal kullanıcılardan farklı bir giriş noktası üzerinden oturum açar. Oturum açma düğmesinin altındaki oturum açma ekranında bir anahtar bulabilirsiniz. Müşterilerinizi HelpDesk girişine yönlendirmek için URL'yi kullanın /yardım masası/giriş. Yukarıda belirtildiği gibi, giriş adı olarak e-posta kullanılır.

ÖNEMLİ: HelpDesk kullanıcıları teknik olarak normal kullanıcılardan bağımsızdır. Bir normal kullanıcı ve bir HelpDesk kullanıcısı için aynı e-postayı kullanabilirsiniz.
Her ne kadar uygulama bunun böyle olmaması gerektiğini gösteriyor. Ya bir HelpDesk kullanıcı hesabı kurarsınız ya da kullanıcının tam bir hesaba ihtiyacı olduğuna karar verirsiniz. Bir kişiye ait her iki hesap türü de yalnızca test amacıyla kullanılmalıdır.

Giriş yaptıktan sonra, portalın kendisi bir yönetici tarafından yapılandırılan, ancak HelpDesk kullanıcısı tarafından yapılandırılamayan ana sayfadan oluşur. Sağ üst köşede, düzenleme modu da dahil olmak üzere profile erişilebilir. Yanında, oturumu kapat düğmesi. Mevcut bir bilete tıklayarak veya yeni bir bilet oluşturarak, kullanıcı yorum veya ek ekleyebileceği bilet detayına yönlendirilecektir. Ana sayfaya dönmek için sol üst köşedeki logoya tıklamanız yeterlidir.

HelpDesk kullanıcısının rolü ve izin ayarı yoktur ve onlara belirli alanlara ek erişim sağlayamazsınız. Yukarıdaki liste, erişebilecekleri tek şeydir. Onlara uygulamanızdaki öğelere herhangi bir bağlantı göndermemelisiniz. sadece yol açacaktır erişim reddedildi mesaj.

9.3.1 HelpDesk kullanıcıları için LDAP kimlik doğrulaması

11plus.2.0 sürümünden itibaren, yardım masası kullanıcılarının kimlikleri LDAP aracılığıyla doğrulanabilir.

Yapılandırma Yönetici >> Eklentiler >> Yardım masası kullanıcıları >> Düzenle - Yeni kimlik doğrulama modundadır.

Form normal LDAP yapılandırmasıyla aynıdır, tek fark yardım masası kullanıcıları için geçerli olmasıdır => sayfa /yardım masası/oturum açma

9.4 Biletlerle çalışma

Müşterinin bakış açısından

HelpDesk kullanıcısı, ana sayfasındaki Yeni bilet formu aracılığıyla bir bilet oluşturur. Kullanılabilir öznitelikler yalnızca Konu, Açıklama ve eklerdir. Felsefe, Müşterilerin müşteri hizmetlerinizden yardıma ihtiyaç duyduklarında kurumsal konular hakkında endişelenmemeleri gerektiğidir. Sadece sorunlarını dile getiriyorlar ve bir çözüm bekliyorlar. Proje seçimi yok, kategori yok, özel alan yok, öncelik seçimi yok – bunların hepsi destek ekibinizin sorumluluğundadır.

Bilet, doğrudan HelpDesk kullanıcısında ayarlanan bir projede oluşturulacaktır. Alan Için e-posta Bilette, HelpDesk kullanıcısının e-postası ile doldurulur. Bu kullanıcı ayrıca şu şekilde ayarlanacaktır: Yardım Masası yazarı gizli bir özellik olan biletin ( YazarEasy Project'teki tüm görevlerin genel bir özelliğidir). Bu, bileti başka bir yere taşısanız bile her zaman bileti görmelerini sağlar.

köşe durumları

• Bir görev atanan kişinin projenin bir üyesi olmadığı durum aşağıdaki durumlarda ortaya çıkabilir:
  • devralan projeden çıkarıldı, ancak görevler kendisine atanmış durumda kaldı,
  • HelpDesk modülünde, bazı çağrıların otomatik olarak eski bir proje üyesine atanması için otomatik bir çağrı güncelleme işlemi ayarlanır.
• SLA Yanıtı hakkında bilgi, görev ayrıntısında yalnızca görev, ilgili izleyicide tanımlanan varsayılan durumda olduğunda görüntülenir.
• Bilet SLA'yı askıya aldığında biletin önceliğini değiştirmemenizi şiddetle tavsiye ederiz, çünkü böyle bir eylem o bilet üzerindeki SLA'nın doğru hesaplanmasını olumsuz etkiler.