Talep yönetimi

Yeni bir talebi sol çubuktaki “New Ticket” ile oluşturursunuz. Formun adı “Create new ticket” şeklindedir. Temsilci olarak başkalarının isteklerini de onunla kaydedersiniz; “User” alanı bunun içindir: işin kimin için olduğunu söyler, kimin yazdığını değil.

Yıldızlı olan her şey zorunludur: “Title”, “User”, “Main category” ve “Description”. Gözden kaçması kolay bir tane daha var: “Subcategory” yıldız taşımasa da form alt kategori olmadan kaydedilmez; bir ana ve bir alt kategori birbirine aittir ve her zaman birlikte ayarlanır.

Hangi alanların zorunlu olduğu “Settings → Ticket Settings” altında ayarlanır. “Admin / Agent Field Settings” kartında bunun için yalnızca “Field is mandatory” anahtarı vardır. “Customer Field Settings” kartında ayrıca “Is hidden for Customer” ve “Is not editable” bulunur. Bu yüzden bir müşteri sizinkinden daha kısa bir form görebilir, hem de kimsenin iki form bakımı yapması gerekmeden. “Title” ve “Description” her zaman zorunludur. Bu kapatılamaz.

Sonrasında neredeyse her şeyi değiştirebilirsiniz: talebin sağında talep eden, telefon, e-posta, konum, kategori ve referans numarasını içeren “Details” kartı durur; alanın kendisini değiştirir ve altındaki “Save” ile onaylarsınız. Durum, atama, öncelik, kanal ve gözlemciler bir kart yukarıda “Actions” altında durur. Durum ve atama hemen etkili olur. Öncelik, kanal ve gözlemciler ancak “Details” kartındaki “Save” ile kaydedilir.

Bunu yalnızca temsilciler ve yöneticiler değiştirebilir. Talep eden işi okuyabilir, yorum yapabilir ve dosya ekleyebilir, ama raporlamanızın üzerine kurulduğu sınıflandırmayı değiştiremez.

Bir kez bilmekte fayda olan bir yan etki: henüz kimseye ait olmayan bir talebi düzenlerseniz sonrasında o size ait olur. Sistem sizi temsilci olarak girer ve durumu “Open” konumundan “Assigned” konumuna taşır; ikisi de geçmişe girer. Bunu istemediyseniz talebi sonradan başkasına atayın.

Bu değişikliklerin her biri talebin geçmişine ad, zaman, eski değer ve yeni değerle düşer. Bunun için bir şey açmanız gerekmez.

Geriye taleplerden yeniden nasıl kurtulacağınız sorusu kalıyor. “Settings → Archive” altında bir tarih aralığı seçer, “Preview” ile kaç kapanmış talep içerdiğini görür ve “Create archive” ile bir ZIP dosyası oluşturursunuz: talepler, yorumlar, geçmiş, özel alanlar ve ekler, hepsi tek bir dosyada. Oluşturmak hiçbir şeyi kaldırmaz. Talepler canlı veritabanından ancak “Existing archives” listesindeki ayrı “Delete from live DB” adımıyla çıkar ve aynı dosyadan geri yüklenebilirler.

Açıklama ve yorumlar çıplak metin kutuları değildir. Her birinin üstünde bir araç çubuğu vardır ve düğmeler, üzerlerine geldiğinizde ne yaptıklarını söyler: “Bold”, “Italic”, “Underline”, “Strikethrough”, “Text color”, “Highlight color”, “Bullet list”, “Numbered list”, “Quote”, “Link” ve “Clear formatting”.

Bağlantı şöyle yapılır: metni seçin, “Link” düğmesine tıklayın, adresi küçük kutuya yazın. Boş bir giriş bağlantıyı yeniden kaldırır. Web ve posta adreslerine izin verilir (http, https, mailto); diğer her şey kaydederken atılır, böylece bir yorum kimsenin gözünden bir şey kaçıramaz.

Resimler panodan gelir: bir ekran görüntüsü alın ve Ctrl+V ile doğrudan düzenleyiciye yapıştırın. Metin başlangıçta yalnızca “[inline-image:1]” gibi bir işaretçi gösterir. Kaydettiğinizde sistem resmi yükler ve tam orada gösterir; resim ayrıca işin tüm dosyalarının durduğu “Attachments” sekmesine düşer. Resim yapıştırma, var olan bir talebin açıklamasında ve yeni bir yorumda çalışır. “Create new ticket” formunda ya da bir yorumu düzenlerken çalışmaz.

Ne görüyorsanız başkaları da onu görür: biçimlendirme, listeler ve bağlantılar talepte ve talep edene giden postada korunur. Yabancı biçimlendirme kodu, örneğin kopyalanmış bir web sayfasından ya da gelen bir e-postadan gelen, bu izin verilen kümeye budanır. Bu sırada metninizden hiçbir şey kaybolmaz, yalnızca ambalajı gider.

Bir yorum “Internal note (not visible to the customer)” ile dahili olarak işaretlenebilir. O zaman “Internal” rozetini taşır ve talep eden için görünmez olur; arama bile onu ortaya çıkarmaz.

Herkes kendi yorumlarını değiştirebilir ve silebilir. Bir müşterinin yazdıklarını yalnızca o müşteri ya da bir yönetici değiştirebilir veya silebilir. Bunlara müşterinin postaları da dahildir. Meslektaşların yorumlarını, talep üzerinde çalışabilen her temsilci değiştirebilir ve silebilir. Talebi daha önce elinde tutmuş bir ekip de buna dahildir.

Dosyalar tek bir yoruma değil, işe aittir. Talepte “Attachments” sekmesi listeye götürür: “Upload file” bir tane ekler, her satır dosyayı, boyutunu ve tarihini adlandırır. Talepte yer alan herkes, talep eden dahil, bir şey ekleyebilir; böylece kimsenin size ekran görüntüsünü postalaması gerekmez. Bir müşteri yalnızca kendi yüklediği ekleri silebilir. Bir alt talep kapatıldığında ekleri ana talebe kopyalanır ve orada “Internal” rozetini taşır. Temsilciler onları görür; müşteriler ne görür ne de indirebilir.

Ada tıklamak, dosyayı indirmeniz gerekmeden önizlemeyi açar. Resimlerde orada yakınlaştırabilir, uzaklaştırabilir ve döndürebilirsiniz; eğik çekilmiş bir ekran fotoğrafı için işe yarar. Bir PDF aynı pencerede, sayfa görünümü, yakınlaştırma ve yazdırma ile gösterilir. Metin dosyaları metin olarak gösterilir. “Open in new tab” ile dosyayı kendi penceresinde açarsınız.

Bir ek işe aittir ve onunla birlikte yolculuk eder: geçmişte görünür (“File uploaded: …”), başka bir ekibe devretmeye dayanır ve talep arşivlendiğinde arşiv dosyasının içine girer.

Talepteki “History” sekmesi her sonradan sorgulamanın ardındaki soruyu yanıtlar: kim neyi ne zaman değiştirdi? Her satır kişiyi, alanı, üzeri çizili eski değeri, arkasında yeni değeri ve saniyesine kadar zamanı adlandırır. En yeni girdi en üsttedir.

Girdiler siz bir şey yapmadan yazılır: durum değişikliklerinde, öncelikte, atamada, kategoride, konumda, gözlemcilerde, başlıkta ve açıklamada, ayrıca oluşturmada (“Ticket opened”), her yorumda ve yüklenen her dosyada. Sekmedeki sayı, işte ne kadar hareket olduğunu önceden söyler.

Geçmiş düzenlenemez ve kapatılamaz. Onu asıl yararlı kılan tam olarak budur: bir talebin tek tek silinememesinin nedeni odur ve talep arşivlendiğinde arşiv dosyasına yolculuk eder.

Bir yorum için geçmiş yalnızca yorumun eklendiğini, düzenlendiğini ya da silindiğini kaydeder. İfade “Comments” sekmesinde durur. Dahili bir yorum da geçmişte görünür, ama yalnızca temsilciler ve yöneticiler için.

Durum, bir talebin şu anda nerede durduğunu söyler. Sistemle birlikte on iki durum gelir: Open, Assigned, In Progress, Waiting for User Response, Resolved, Closed ve daha fazlası. Onları “Settings → General Settings” altında “Drop-down lists” bölümünde “Status” sekmesinin arkasında bulursunuz; “+ Add status” kendinize ait bir tane oluşturur, “Edit status” var olan birini açar.

Önemli olan, ad ile anlam arasındaki farktır. Bir durumun düzenleyicisinde, “Meaning of this status” altında üç anahtar vardır: “Counts as resolved”, “Counts as closed” ve “Waiting for the requester”. Sisteme bir durumu nasıl ele alacağını yalnızca bu anahtarlar söyler.

Sistemle birlikte gelenler dahil her durumu yeniden adlandırabilirsiniz: düzenleyicinin altında, “Translations” altında dil başına bir “Name” alanı vardır; oraya insanlarınızın okuması gerekeni yazın. Arkasındaki teknik ada dokunulmaz ve hiçbir şeyin bozulmamasının nedeni tam olarak budur: otomasyon, raporlama ve yukarıdaki anahtarlar sizin etiketinize değil, o ada asılıdır. Böylece “Resolved” durumu “Done” olabilir.

Silmek ise hepsinde işlemez. Sekiz durum listede “Mandatory” rozetini taşır: Open, Assigned, In Progress, Resolved, Closed, Reopened, Waiting for approval ve Rejected. Yeniden adlandırılabilir ve sıraları değiştirilebilir, ama kaldırılamazlar; denemek açık bir iletiyle biter. Bu sizi kızdırmak için değildir: onlara, yoksa tek kelime etmeden duracak süreçler asılıdır, örneğin başlangıç noktası olarak bir “resolved” durumuna gereksinim duyan otomatik kapatma.

İki durum sistemin kendisine aittir: “Waiting for approval” ve “Rejected” durumları “System only” rozetini taşır. Onlar bir onay sürecinden çıkar ve hiç karara sunulmamış bir şeyin reddedildiğini kimse elle ileri sürebilmemelidir.

Üçünün ne yaptığı: çözülmüş sayılan bir durum, talebi 24 saat sonra kendiliğinden kapatır. Kapanmış sayılan bir durum, talebin taşındığı son durumdur. Ve “Waiting for the requester” tam olarak şunu demektir: talep edeni bekliyoruz, başka bir ekibi ya da bir hizmet sağlayıcıyı değil. Böyle ayarladıysanız SLA saatinin durduğu işaret budur.

Onun altında “Allowed transitions to new status” durur. Burada bu durumdan hangi durumlara ulaşılabileceğini işaretlersiniz. Her şeyi boş bırakırsanız hiçbir şey kısıtlanmaz; bir şey işaretlerseniz diğer her yol kapanır. Atlanamayacak bir akışı böyle kurarsınız, örneğin: “Open” durumundan yalnızca “In Progress” ya da “Assigned” durumuna geçilebilir, doğrudan “Closed” durumuna geçilemez.

Düzenleyicideki kalan anahtarlar büyük etkisi olan küçük şeylerdir: liste için renk, sıra için “Sort order”, “Show status in new ticket form” (bu durum talep oluştururken hiç seçilebilir olmalı mı?), “Requires comment in dialog” (bir gerekçeyi zorunlu kılmak) ve yalnızca sistemin kendisinin ayarlayabileceği durumlar için “System only”.

En fazla dört durum, talepte “Change Status to:” altında düğme olarak görünür. Onları düzenleyicide “Set as primary status (max. 4)” anahtarıyla seçersiniz. Fabrika ayarında bunlar In Progress, Waiting for User Response, Waiting for Service Provider Response ve Resolved durumlarıdır. Diğer tüm durumlar “More statuses” altındadır.

Bir talepte açılır liste olarak görünen her şey size aittir. “Settings → General Settings” altında altı sekmeli “Drop-down lists” kartı durur: “Department”, “Position”, “Location”, “Role”, “Status” ve “Priority”. Kullanım listeden listeye değişir.

Tek tek: İngilizce adı boş alana yazın ve yanındaki düğmeye tıklayın; düğmenin adı listeye göre değişir, yani “+ Add location”, “+ Add department” ve benzeri. Altındaki satırlar var olan girdilerdir. “Department”, “Position” ve “Location” listelerinde bir adı orada değiştirir ve yanındaki “Save” ile onaylarsınız.

Aynı anda çok sayıda girdi için “Department”, “Position” ve “Location” ayrıca “Export JSON” ve “Import JSON” sunar. Yeni kurulmuş bir sistemde boş yapıyı “Export JSON” ile indirir, doldurur ve yeniden içe aktarırsınız. Bu, ad değiştirmenin yolu değildir; kartın kendisi bunu söyler.

Bazı girdiler “Mandatory” rozetini taşır. “Admin”, “Agent” ve “Customer” rolleri bunlar arasındadır, ayrıca sistemle gelen durumlardan sekizi ve Location, Position ve Department listelerinde birer yer tutucu (“None selected or available”). Hiçbiri silinemez: onlara, yoksa tek kelime etmeden duracak yetkiler ve süreçler asılıdır. Durumlar kendi düzenleyicilerinde yine de yeniden adlandırılabilir. Roller ve yer tutucular yeniden adlandırılamaz. Neye izin verildiği listeye bağlıdır. “Role” kilitlidir: bir rol ne eklenebilir ne de yeniden adlandırılabilir. “Priority” listesinde girdi ekler ve silersiniz, ama dosya da yoktur, yeniden adlandırma da. “Status” listesinin kendi düzenleyicisi vardır ve onun da dosyası yoktur.

Burada diğer dillere çeviri yapmazsınız, çeviri sayfasında tek seferde yaparsınız. Burada İngilizce ad yeter; sonradan çevirilerin tutunduğu çengel odur.

Durum, kendi düzenleyicisi olan tek girdidir, çünkü ona bir addan fazlası asılıdır; onun daha aşağıda kendi kartı vardır.

Kategoriler, talep eden ya da temsilcinin talep oluştururken seçtiği ve sonradan raporlarınızı kendisine göre grupladığınız şeydir. Her ekibin kendine ait kategorileri vardır: bir yardım masası bir ağ departmanından başka şeylere göre sıralar ve hiçbiri öbür ekibin listelerini görmez.

Onları “Settings” altında “<team name> Categories” girdisi olarak bulursunuz. Örnekte ekibin adı “Helpdesk” olduğu için girdi “Helpdesk Categories” şeklinde okunur.

Sayfada üç kart vardır: “Main categories”, “Subcategories” ve “Links”. En hızlı başlangıç: İngilizce adı “EN (required)” alanına yazın ve “+ New main category” ya da “+ New subcategory” düğmesine tıklayın. Her şeyi sonradan çeviri sayfasında tek seferde çevirirsiniz; bunun için burada hazırlanacak bir şey yoktur.

Önünüzde çok sayıda kategori varsa dosya yolunu seçin: “Export JSON” yapıyı indirir; yeni kurulmuş bir sistemde dosya boştur ve size yalnızca düzeni gösterir. Onu doldurur (elle ya da bir yapay zekânın yardımıyla), kaydeder ve “Import JSON” üzerinden yeniden yüklersiniz. Bu, ad değiştirmenin yolu değildir: bir adı o kategorinin alanında değiştirir ve yanındaki “Save” ile onaylarsınız; sayfa da bunu söyler.

Asıl iş üçüncü kartta, “Links” kartında olur. Üstte bir ana kategori seçin, altında ona ait alt kategorileri işaretleyin ve “Save links” ile kaydedin. İşin püf noktası: bir alt kategori birden çok ana kategoriye asılabilir. Böylece “Malfunction” girdisine yalnızca bir kez ihtiyacınız olur ve onu Printer, Network, Meeting-Room ve Notebook için yeniden kullanırsınız.

Bundan sonra kategoriler talepte kullanılabilir. Bir kategori hâlâ talepler tarafından kullanılıyorken silme başarısız olabilir; bu bilinçlidir, yoksa eski talepler sınıflandırmasını kaybederdi. Bir bağlantıyı kaldırırsanız o çifti kullanan talepler yine de kaydedilebilir. Bağlantılara karşı yalnızca yeni seçilen bir kategori denetlenir.

Bir talebi başka bir ekibe devrederseniz sınıflandırması kalır, yeni ekipte o kategoriler hiç olmasa bile. O zaman alanda kaynağıyla birlikte durur, örneğin “Meeting-Room · from Helpdesk”, ve soluk gösterilir: yeni ekip işin şimdiye kadar ne olarak yürüdüğünü görebilir, ama o girdiyi kendisi atayamaz. Yeniden sıralamak için kendi listenizden seçersiniz ve sistem o zaman bir ana ve bir alt kategoriyi birlikte ister.

Her talep bir kanal taşır. Kanal formda ve sonradan “Actions” kartında “How the request came in” altında durur ve raporlamada çabucak önemli olan bir soruyu yanıtlar: iş portal üzerinden mi yoksa telefonla mı geliyor?

Yalnızca bir insanın bildiği ve sistemin bilmediği şeyi seçebilirsiniz: “Phone” ve “Entered by an agent”. Diğer iki değeri sistem kendisi ayarlar: talebi talep eden portalda oluşturduysa “Self-service”, gelen bir postadan büyüdüyse “E-mail”. Bir temsilci talep oluşturduğunda form “Entered by an agent” ile başlar.

Sistemin atadığı bir kanalı sonradan kimse değiştiremez. Alanda o zaman “Recorded by the system. It cannot be changed.” yazar. Yoksa alan, var olma nedeni olan ifadeyi tam olarak kaybederdi. Tersine, telefonla kaydedilmiş bir talepte diğer her şeyi yine de değiştirebilirsiniz.

Kanalı yalnızca bir temsilci ya da bir yönetici ayarlayabilir. Talep eden için bu, kendi işi hakkında bir ifade olurdu ve raporlama herkesin dürüst olmasına bağlı kalırdı.

“E-mail” bağlı bir posta kutusu gerektirir ve o, Professional sürümünün parçasıdır. Diğer üç kanal iki sürümde de vardır.

Her talep listesinin üstünde “Search tickets…” alanı vardır. Yalnızca başlıklarda değil, işin tamamında arar: başlık, açıklama, talep edenin adı, e-posta adresi ve telefon numarası, konum, referans talep numarası, tüm yorumlar ve kendi özel alanlarınızın metin değerleri.

Örnek bunu gösterir: “coffee” hiçbir başlıkta geçmez, yalnızca bir talebin açıklamasında, ve yine de bulunur. Yani bir talebin nasıl başlıklandırıldığını hatırlamanız gerekmez; işten bir sözcük yeter.

Büyük ve küçük harf fark etmez. Arama her zaman o an içinde bulunduğunuz liste için geçerlidir ve yanındaki “Filter” ile birleştirilebilir; “Reset” aramayı ve süzgeçleri yeniden temizler. Liste süzgeçlerinizi her ekip listesi için ayrı ayrı hatırlar. Bir talepten geri döndüğünüzde, sayfayı yenilediğinizde ya da başka bir bilgisayarda oturum açtığınızda süzgeçler hâlâ ayarlıdır. Arama metnini ise hatırlamaz. Müşteriler için göremeyeceğiniz ama bilmeniz gereken bir sınır vardır: onlar dahili yorumlarda arama yapmaz, yoksa sonuç listesinden içeride nelerin konuşulduğunu çıkarabilirlerdi. Müşterilerden gizlenen özel alanlarda da arama yapmazlar.

Herkes kendi talep listesini oluşturur. Bunun için “Filter” düğmesinin yanında “Columns” düğmesi durur. Bu düğme “Choose columns” penceresini açar.

Pencerede görmek istediğiniz her sütunu işaretlersiniz. Yanındaki oklar sırayı belirler. “#” ve “Title” her zaman dahildir. Bir sütunun genişliğini listenin kendisinde, başlığının kenarını sürükleyerek değiştirirsiniz.

“Save” seçiminizi kullanıcı hesabınızda saklar. Bu nedenle her bilgisayarda geçerlidir ve oturumu kapattıktan sonra da kalır. “Default columns” listeyi fabrika ayarına döndürür.

Tüm sütunlara yetecek yer olmadığında önce en sağdakiler düşer. “#”, “Title” ve “Status” her zaman kalır. Bu yüzden sizin için en önemli olanı öne taşırsınız.

Professional ile özel alanlarınız da sunulur. Pencerede kendi adlarıyla görünürler, burada örneğin “Asset tag”.

Müşteriler listelerini aynı şekilde düzenleyebilir, ancak onlara daha az sütun sunulur. “Team”, “Created by”, “Last activity”, “Status changed at”, “Deadline”, “Follow-up” ve “Time” onlar için kullanılamaz. Müşterilerden gizlediğiniz alanlar da sütun olarak görünmez.

Akıllı telefonda düğme gösterilmez. Orada liste sığan sütunları gösterir.

Talep bunun için yan yana iki düğme sunar ve fark, altlarında küçük punto ile yazar. “Involve another team”: siz sorumlu kalırsınız, öbür ekip bağlı bir talepte sizin yanınızda çalışır. “Escalate to another team”: öbür ekip devralır.

Devrettiğinizde sorumluluk ikinci bir talep oluşmadan taşınır. Ekibiniz okuma erişimini korur ve yine yorum yapabilir, ama artık hiçbir şeyi değiştiremez; pencere zaten siz onaylamadan önce size tam olarak bunu söyler. Hedef ekibi orada seçer ve bir gerekçe ekleyebilirsiniz.

Bir ekibi işe kattığınızda talebiniz sizin elinizde kalır ve öbür ekipte bir alt talep alır. Sizinki “Waiting for other team” durumuna geçer; öbür ekip kendisininkini kapattığında sizinki “Back from other team” olarak geri gelir. Böylece orada bir şey olup olmadığını sormanız gerekmez. Alt talebin ekleri “Internal” rozetiyle talebinize kopyalanır ve müşteri onları görmez.

Sınıflandırmaya gelince: devreden ekibin kategorileri talepte kalır, yeni ekipte hiç olmasalar bile; orada kaynaklarıyla ve soluk gösterilirler. Böylece yeni ekip işin şimdiye kadar ne olarak yürüdüğünü görebilir ve gerekirse kendi listesine göre yeniden sıralayabilir.

Bir talebi yalnızca o an sorumlu olan devredebilir. Önceki bir durak işi hâlâ görür ama onu ikinci kez devredemez. Yorum yazabilir, ama talebi kendine geri alamaz.

Ekibinizin listesinde talep, öbür ekip üzerinde çalıştığı sürece “Waiting for other team” gösterir. “Also show tickets this team handed over” işareti fabrika ayarında açıktır ve her kullanıcının kendi seçimi saklanır. Öbür ekip için talep “Open” olarak başlar.

Talebi devreden kişi talebin gözlemcisi olur. Pencere bunu siz onaylamadan önce söyler. Gözlemci olarak durum değiştiğinde, talep kapatıldığında veya biri yorum yaptığında e-posta alırsınız. Her gözlemci gibi “Stop observing” ile kendinizi çıkarırsınız.

Taleplerinizde bir bilgi eksikse, örneğin envanter numarası, garantinin bitişi, masraf merkezi, onu kendiniz eklersiniz. “Settings → Ticket Settings” altında, en altta “Custom fields” kartı durur; düğmenin adı “Add custom field” şeklindedir.

Pencerede bir ad ve bir alan türü verirsiniz: “Text”, “Multiline text”, “Integer”, “Decimal”, “Date” ya da “Yes / No”. Neyin girilebileceğine tür karar verir; bir tarih alanı “gelecek hafta” değerini kabul etmez ve sonradan onun üzerinden rapor alabilmenizin nedeni tam olarak budur.

“Scope” altında alanın nerede geçerli olduğuna karar verirsiniz: “All teams (including new ones)” ya da “Selected teams only”. Birinci seçim henüz var olmayan ekipleri de kapsar; ancak yarım yıl sonra fark edeceğiniz türden bir fark.

“Defaults” altındaki üç anahtar “Mandatory by default”, “Hidden for customer by default” ve “Not editable by customer by default” anahtarlarıdır. Bir alan için ancak aynı sayfadaki alan ayarlarında o alana dair henüz bir şey kaydedilmemişse geçerlidirler. Orada ayarladığınız anda alan ayarları karar verir.

Talepte özel alanlar açıklama ile yorumlar arasında kendi kartında, “Additional information” kartında durur. Şablon olmadan form ekibin tüm özel alanlarını gösterir. Talep oluştururken bir şablon seçerseniz tam olarak o şablonun listelediği alanları, onun sırasıyla gösterir: “yalnızca bu işin ihtiyaç duyduğu alanlar”.

Bir şablon üstelik bir alanı zorunlu kılabilir. Yöneticinin müşterilerden gizlediği şey, bir şablon onu listelese bile gizli kalır. Bir şablonun listelemediği zorunlu bir alan sorulmaz; bu yüzden bu şablonla oluşturulan talepler için o zorunluluk geçerli değildir.

Bir ekibin kaç özel alanı olabileceği “Settings → General Settings” altında “Custom fields limit” kartında ayarlanır. Bir alandan “Deactivate” ile kurtulursunuz: formdan kaybolur, ama değerleri eski taleplerde kalır; “Show deactivated” anahtarı onu listeye geri getirir.

Bazen biri bir işi, üzerinde çalışmadan izlemelidir: hassas bir konuda ekip lideri, gelecek hafta devralacak meslektaş. Gözlemciler bunun içindir. Talepte “Observers” alanı “Actions” kartında durur, düğmenin adı “Add observer” şeklindedir; “Create new ticket” formunda da aynı alan vardır. Talepte oradaki bir değişiklik “Details” kartındaki “Save” ile kaydedilir.

Yalnızca talebin ait olduğu ekibin temsilcileri ve yöneticileri seçilebilir. Bir müşteri gözlemci olamaz; yoksa dahili çalışma hakkında posta alırdı.

Bir gözlemci, talepte bir şey olduğunda e-posta alır: yeni bir yorum, değişen bir durum, yeni bir atama, değişen alanlar. Posta hemen gönderilmez, toplanır: son değişiklikten sonra sistem bir dakika bekler ve sonra o süre içinde olan her şeyi kapsayan TEK bir posta gönderir. Böylece bir talebi tek seferde işlemek yedi posta tetiklemez. O süre içinde birkaç yorum gelirse hepsi postada yer alır.

Kimin gözlemlediği geçmişin parçasıdır: bir değişiklik, diğerleri gibi eski ve yeni durumuyla kaydedilir.

Gözlemci girmek Basic sürümünün parçasıdır. Gözlemcilere giden posta Professional sürümünün parçasıdır, çünkü giden posta gerektirir. O olmadan gözlemci girebilirsiniz ama hiçbir şey çıkmaz. Bir gözlemci “Stop observing” düğmesiyle kendini çıkarabilir. Bunun için talebi değiştirme yetkisi gerekmez.

Bir gözlemci kendiliğinden de eklenir: bir talebi “Escalate to another team” ile devreden kişi gözlemci olur. Böylece öbür ekibin talep üzerinde ne yaptığını öğrenir.

İki kişi aynı talep üzerinde aynı anda çalıştığında, sonraki kaydetme öncekinin üzerine yazabilir ve kimse bunu fark etmez. Bu yüzden talep, onu başka kimin açık tuttuğunu gösterir. Ayrıca eski bir sürüme dayanan kaydetmeyi reddeder.

Bildirim talebin üst kısmında durur. “Marco Rossi is viewing this ticket”, Marco'nun talebi açık tuttuğu anlamına gelir. “Marco Rossi is actively editing this ticket”, Marco'nun talepte kaydedilmemiş girdileri olduğu anlamına gelir. Bu, başlanmış bir yanıt, o sırada değiştirilen bir yorum, düzenleme modundaki başlık ya da açıklama, bir hatırlatma, bir özel alan veya bir zaman girdisi olabilir. “Actions” ve “Details” kartlarında değiştirilen alanlar da “Save” ile kaydedilmedikleri sürece sayılır. Talepte açık bir pencere de sayılır. Bunlar “Involve another team?”, “Escalate to another team?”, “Close ticket”, “Resolve incident” ve “Start a workflow” pencereleri ile durum değişikliğindeki yorum penceresidir. İki dakika boyunca hiçbir şey girilmezse bildirim, taslak hâlâ orada dursa bile yeniden “viewing” gösterir.

Talebi birkaç meslektaş açık tutuyorsa bildirim onları özetler, örneğin “Marco Rossi and 2 more are viewing this ticket”. Tüm adları görmek için bildirimin üzerine gelin. Biri etkin olarak düzenlediği anda satır yalnızca düzenleyenleri sayar. Kendinizi hiçbir zaman görmezsiniz. Talebi iki sekmede açık tutuyorsanız bir kez sayılırsınız. Talep yalnızca gizli bir sekmede açıksa yaklaşık bir dakika sonra diğerlerinin bildiriminden düşersiniz.

Bir meslektaş bir değişikliği kaydettiğinde bildirimde “Marco Rossi changed this ticket” yazar, yanında da “Refresh” düğmesi bulunur. Başka birinden gelen yeni bir yorum “Marco Rossi added a comment” gösterir. Değişikliği bir kişi değil de örneğin bir otomasyon kuralı veya gelen bir e-posta yaptıysa bildirimde “This ticket was changed” yazar. Bildirim, siz yenileyene kadar yerinde kalır.

“Refresh”, talebin güncel sürümünü yükler; örneğin durum, atama, alanlar ve geçmiş. Sayfanın tamamını yeniden yüklemez. Kaydedilmemiş girdileriniz kalır. Başlanmış bir yanıt yanıt kutusunda kalır, açık bir başlık veya açıklama da metninizi korur. Kaydedilmiş metin bu arada değiştiyse alanın altında “The saved text has changed in the meantime.” görünür. O zaman kaydederseniz metniniz kaydedilmiş olanın yerini alır. Talebin üst kısmındaki “Refresh” düğmesi de aynısını yapar.

Yine de eski bir sürüm üzerine kaydederseniz kaydetme reddedilir. “Ticket changed in the meantime” penceresi açılır. Değişikliği bir kişi yaptıysa pencere o kişinin adını verir. Değişikliğiniz kaydedilmemiştir. “Refresh” düğmesine tıklayın, değişikliğinizi güncel sürümle karşılaştırın ve yeniden kaydedin. Bu, talebin kendisindeki her değişiklik için geçerlidir; örneğin durum, atama, öncelik, “Details” kartı ve özel alanlar.

Yorumlar hiçbir zaman reddedilmez. İki yanıt birbirinin üzerine yazmaz. İkisi de talebe eklenir. Aynısı ekler ve zaman girdileri için de geçerlidir. Talep listesindeki toplu işlemler ve otomasyon kuralları da sürümle karşılaştırılmaz. Bunlar talebi doğrudan değiştirir. Talebi açık tutan kişi ardından bildirimi görür.

Müşteriler bunların hiçbirini görmez. Bildirimde yer almazlar. Taleplerinde kimin çalıştığını da görmezler.

Bir talebi kimin açık tuttuğu yalnızca sunucunun belleğinde tutulur. Kişi talepten ayrıldıktan yaklaşık bir dakika sonra kayıt kaybolur. Bunların hiçbiri bir günlüğe yazılmaz. Talep, onu en son kimin değiştirdiğini saklar. Bu bilgi, o kişinin veri dışa aktarmasına dahildir. Kişi anonimleştirildiğinde bu bilgi kaldırılır.

Posta kanalı iki yönlü tek bir yoldur ve iki yön birbirine aittir: gelen bir posta talebe dönüşür, yanıtınız posta olarak çıkar ve talep edenin yanıtı ikinci bir talebe değil, aynı talebe yorum olarak düşer.

Eşleştirme sezgiyle yapılmaz: bir yanıt, ancak posta konusunda işin göndermesini taşıyorsa ya da posta programının yanıt başlıklarını yanında getiriyorsa var olan talebe düşer. İkisi de olmayan bir posta yeni bir iş başlatır; yalnızca konu denk geldi diye ilgisiz iki işi birleştirmektense bir talep fazla olsun daha iyidir.

Bunun için gereken her şey “Settings → E-Mail Settings” altında durur. Üstteki kart, “SMTP settings”, çıkış yoludur: sunucu, bağlantı noktası, “Use SSL”, kullanıcı ve parola, ayrıca gönderen adresi ve gönderen adı. “Send test e-mail” ile kendinize bir örnek gönderirsiniz; kartın kendisinin de söylediği gibi önce kaydedin, sonra sınayın.

“IMAP settings” kartı giriş yoludur: sunucu, bağlantı noktası, sorgulama aralığı ve iki klasör. Klasör adını tahmin etmeniz gerekmez: “Read from server” posta kutunuzda gerçekten var olan klasörleri getirir, “Create on server” yeni bir tane oluşturur. Alan sonra posta sunucunuzun onun için kullandığı yolu alır; bir sunucu “INBOX/Processed” yazar, bir sonraki “INBOX.Processed”, ve ikisi de aynı şeyi anlatır.

“Processed folder”, sistemin kenara ayırdığı postaları alır: engellenen göndericilerden gelen postalar, otomatik oluşturulan postalar ve bir iş akışının kendi klasörü olmadan “Move to folder” ile taşıdığı postalar. Boş bırakırsanız gelen kutusunda kalırlar. Onun altında temizliğin ne zaman çalışacağını (“Hour”, “Minute”) ve bir iletinin ne kadar eskiyebileceğini (“Retention (days)”) ayarlarsınız; yoksa posta kutusu sessizce büyümeye devam eder.

Posta kutuları sisteme değil, ekibe aittir: “Team mailboxes” altında her ekip kendi adresini bir parolayla girer. O adres aynı zamanda o ekibin postalarının göndereni olur, böylece talep eden postanın toplandığı yerin aynısına yanıt verir.

Ve şimdi olmadan bunların hiçbirinin gerçekleşmediği bölüm: iş akışı. Yapılandırılmış bir posta kutusu tek başına hiçbir şey yapmaz. Bir ekibin etkin bir iş akışı yoksa posta kutusu sorgulanmaz bile: talep yok, onay yok, postalar öylece durur. Müşterilerinize giden otomatik yanıt yalnızca burada vardır ve onu kendiniz kurarsınız. Bu bilinçlidir: sorulmadan her gönderen adrese yazan bir sistem, susan bir sistemden daha kötü olurdu.

“E-Mail workflows” altında üstte ekibi seçer ve “+ Add workflow” ile bir iş akışı oluşturursunuz. İş akışı bir ad (yalnızca sizin için), bir “Enabled” anahtarı ve ne zaman geçerli olduğuna ilişkin iki ifade alır: “Match” tüm koşulların doğru olması mı (“All conditions”) yoksa birinin yetmesi mi gerektiğine karar verir, “Stop after match” ise bu iş akışı eşleşir eşleşmez çalışmayı bitirir; aşağıdaki bir iş akışının o zaman sırası hiç gelmez. Sırayı yanındaki oklarla değiştirirsiniz.

“When?” altında koşulun kendisi durur. “Every e-mail in this mailbox” her postayı alır; “Only when subject or text contains” konuda ya da gövdede bir sözcük ister. “Advanced” işi kesinleştirir: orada neye bakılacağını seçersiniz — “Subject or body”, “Subject”, “Body”, “Sender (From)” ya da “Recipient (To/Cc)” — ve nasıl karşılaştırılacağını: “Contains”, “Equals” ya da “Regex”. Örneğin ortak bir adrese gelen bildirimleri diğer her şeyden böyle ayırırsınız.

Onun altında anahtar olarak beş eylem durur. İş akışının asıl içeriği onlardır; açılmayan hiçbir şey gerçekleşmez:

“Create or append ticket” postayı talebe dönüştürür ya da gönderme konudaysa onu var olan bir talebe yorum olarak ekler. Bu eylem olmadan bir posta hiçbir zaman işe dönüşmez.

“Set fields” talep oluşturulurken önceliği, durumu, ana ve alt kategoriyi, sahip ekibi ve atanan kişiyi ayarlar. “— Keep default —” üzerinde bırakılan her şey, iş akışı olmasaydı nasıl olacaksa öyle kalır.

“Auto-reply” gönderene giden onaydır. Bu anahtar kapalıyken müşteriniz, diğer her şey ne kadar iyi kurulmuş olursa olsun, hiçbir onay almaz. Sonraki eylemin gösterdiği gibi “Send mail” de gönderene yazabilir.

“Send mail” ek bir posta gönderir: ya gelen postanın göndericisine ya da seçilmiş ekip üyelerine ve sabit adreslere. Kendi “Send conditions” koşulları vardır; onları boş bırakırsanız bu iş akışının her çalışmasında çıkar.

“Move to folder” işlenen postayı bir klasöre dosyalar. Alanı boş bırakırsanız yukarıdaki IMAP ayarlarındaki genel “Processed folder” geçerli olur.

“Auto-reply” eylemi ayrıntılı olarak: konuyu bloklardan kurarsınız. “Original subject {originalSubject}” gelen postanın konusunu devralır, “Ticket reference {ticketTag}” işin göndermesini ekler; birlikte “Printer problem [TICKET-99-a1b2c3]” gibi bir şey verirler.

Gönderme kendiliğinden eklenmez. Yalnızca {ticketTag} koyduğunuz yerde görünür. {ticketId} yalnızca çıplak numarayı ekler ve sistem bir yanıtı ondan tanımaz. Konuda gönderme olmasa da bir yanıt, onayın yanıt başlıklarını taşıyorsa yine eşleştirilir. Yalnızca ikisini de taşımayan bir posta yeni bir talep olur.

Onun altındaki metin sizin onay iletinizdir. Onu İngilizce yazın: diğer her metin gibi aynı dışa aktarma ve içe aktarmadan geçer ve ancak böyle diğer dillere çevrilebilir. Boş bırakırsanız sistem kendi varsayılan iletisini gönderir. Burada da aynı yer tutuculara izin verilir.

“Reply language” konunun ve metnin hangi dilde çıkacağına karar verir: “Standard English” İngilizceyi kullanır, “Fixed language” seçtiğiniz bir dili, “Assigned agent's language” atanan temsilcinin dilini ve “Team default language” ekibin varsayılanını. Çevirilerin kendisi diller sayfasında tutulur.

Sistemin de kartın üstünde yazdığı bir öğüt: bir işe ait olan her şey TEK bir iş akışına aittir. Yalnızca aynı iş akışındaki eylemler az önce oluşturulan talebi bilir; onayın numarasını söyleyebilmesinin ve ikinci bir iş akışındaki bir eylemin söyleyememesinin nedeni budur.

Posta kanalının tamamı, hem giriş hem çıkış, Professional sürümünün parçasıdır. Basic sürümünde sistem ne e-posta gönderir ne alır; talepler orada portal, telefon ve temsilci yoluyla oluşur.