Kılavuz

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 hiç görüneceği ve bunlardan hangilerinin zorunlu olduğu “Settings → Ticket Settings” altında, temsilciler ve müşteriler için ayrı ayrı ayarlanır. Bu yüzden bir müşteri sizinkinden daha kısa bir form görür, hem de kimsenin iki form bakımı yapması gerekmeden.

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, öncelik, atama, kanal ve gözlemciler bir kart yukarıda “Actions” altında durur ve ayrı bir kaydetme olmadan hemen etkili olur.

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. O talepler ancak ondan sonra canlı veritabanından kaybolur 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.

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 “Only for Admin/Agents” 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.

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.

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 orada kısaltılmış görünür; tam ifade “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. Altı durum listede “Mandatory” rozetini taşır: Open, Assigned, In Progress, Resolved, Closed ve Reopened. 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 “Rejected” 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”.

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”, “Site”, “Role”, “Status” ve “Priority”. Her birinin arkasında aynı kullanım vardır, böylece onu yalnızca bir kez öğrenmeniz gerekir.

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 site”, “+ Add department” ve benzeri. Altındaki satırlar var olan girdilerdir: bir adı orada değiştirir ve yanındaki “Save” ile onaylarsınız.

Aynı anda çok sayıda girdi için “Export JSON” ve “Import JSON” vardır. 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 altısı ve Site, Position ve Department listelerinde birer yer tutucu (“None selected or available”). Yeniden adlandırılabilir ama silinemezler: onlara, yoksa tek kelime etmeden duracak yetkiler ve süreçler asılıdır.

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 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 “Email”.

Sistemin atadığı bir kanalı sonradan “Phone” değerine çevirememenizin nedeni de budur: 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ı.

“Email” 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. 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.

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.

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.

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 yeni talepler için geçerlidir: “Mandatory by default”, “Hidden for customer by default” ve “Not editable by customer by default”. Bunlar varsayılandır; aynı sayfadaki alan ayarları, rol başına kesin ayarı yaptığınız yer olarak kalır.

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, ama bir kuralı kaldıramaz: yöneticinin müşterilerden gizlediği ya da zorunlu ilan ettiği şey, bir şablon aksini söylese de öyle kalır. Yoksa şablon, bir ev kuralından sıyrılmanın yolu olurdu.

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.

Yalnızca katılan bir 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.

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

Bildirim bir e-postadır, yani giden postanın kurulmuş olması gerekir (Professional). O olmadan gözlemci girebilirsiniz ama hiçbir şey çıkmaz.

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.

İşlenen postalar “Processed folder” klasörüne taşınır; 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; sistemin kendiliğinden yanıt verdiği tek yer. Bu anahtar kapalıyken müşteriniz, diğer her şey ne kadar iyi kurulmuş olursa olsun, hiçbir zaman otomatik yanıt almaz.

“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]” gibi bir şey verirler.

Gönderme kendiliğinden eklenmez. Yalnızca {ticketTag} ya da {ticketId} koyduğunuz yerde görünür ve sistem müşterinizin yanıtını sonradan tam olarak ondan tanır. Konuda o olmadan sonraki her ileti, eski talebe yorum olacağına yeni bir talep başlatır.

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.

Zaman takibi fabrika ayarı olarak kapalıdır. Kapalıyken raporda ne bir alan, ne bir sütun, ne de bir kutucuk vardır.

Ölü bir alan hiç olmamasından kötü olurdu, bu yüzden özellik soluk durmak yerine tümüyle kaybolur.

Anahtar “Settings → General” altında “Time tracking per ticket” kartında durur ve adı “Enable time tracking” şeklindedir.

Sonrasında her ekip katılır. Birini dışarıda bırakmak için onu ekibin kendisinde, “Settings → Teams” altında “Team details” kutusunda kapatırsınız.

Dahili bir BT ekibi ve müşteriyle çalışan bir ekibi olan bir şirketin buna çoğu zaman yalnızca ikincisi için ihtiyacı olur.

Zaman takibini sonradan yeniden kapatırsanız var olan kayıtlar okunabilir ve dışa aktarılabilir kalır; onlar bir kolaylık değil, faturalama temelidir. Yeni bir şey kaydedilemez.

Talep, adı “Time spent” olan bir kart taşır. “Log time” girişi açar.

Alanın yanında hızlı düğmeler durur: “30m” düğmesine bir tıklama otuz dakika kaydeder. Hangi düğmelerin görüneceği ayarlarda belirlenir.

“Duration” alanı serbest giriş de kabul eder: “90” doksan dakikadır, “1.5h” bir buçuk saattir ve “1h 30m” de öyledir. Birimsiz bir sayı her zaman dakikadır.

Sistemin tam olarak anlamadığı giriş geri çevrilir. “1h in the evening” bir saatlik bir kayda dönüşmez; bir hata iletisine dönüşür.

“What for (optional)” alanına sürenin ne için olduğunu yazarsınız. Metin dışa aktarmaya gider ve talep geçmişinde görünmez.

Aynı talepte birden çok temsilci süre kaydeder. Her kayıt gününü, notunu ve işi yapan kişinin adını taşır.

Süre bir saat noktasına değil, bir güne kaydedilir. Dünü doldurmak olağan durumdur ve bir saat noktası, girişin sahip olmadığı bir kesinliği ileri sürerdi.

Uzun oturumlar için talepte bir kronometre vardır: “Start timer” onu başlatır, “Pause” durdurur.

Kronometre hiçbir zaman kendiliğinden bir kayıt oluşturmaz. Geçen süreyi önerir ve siz “Log” düğmesine basmadan hiçbir şey kaydedilmez.

O, zihinden hesap yapmanın yerini alır, bilginin değil. Onsuz da özellik eksiksizdir, çünkü asıl yol değeri yazmaktır.

Başka bir talebi açmak işleyen kronometreyi duraklatır ve yeni talep size onun hangi talebe bağlı olduğunu söyler.

Gizlenmiş bir pencere mola değildir. Yalnızca başka bir yere tıklarsanız kronometre işlemeye devam eder.

Gece boyunca açık unutulan bir kronometreye karşı bir en uzun çalışma süresi vardır. Değer üst sınıra çekilir, hiçbir zaman atılmaz, ve temsilciye bildirilir.

Kronometre fabrika ayarı olarak kapalıdır. Onu ayarlarda “Stopwatch on the ticket” altında bulursunuz.

Her kayıt bir “Billable” işareti taşır. Süre bir kez kaydedilir ve işaret, onun faturaya girip girmeyeceğine karar verir.

Bu yüzden talep iki toplam gösterir: solda kaydedilenlerin tamamı, sağda faturalanabilir toplam.

İyi niyet çalışması için ayrı bir tür yoktur. İyi niyet, garanti işi ve dahili yeniden işleme her şirkette başka türlü adlandırılır ve sistem yalnızca paranın asılı olduğu tek ayrımı bilir.

İyi niyet çalışmasını şöyle kaydedersiniz: süreyi her zamanki gibi girin, kutunun işaretini kaldırın ve gerekçeyi nota yazın.

Kayıt o zaman görünür biçimde “not billable” taşır. Dakikalar kaydedilen toplamda kalır, çünkü iş gerçekten yapıldı.

Süreyi hiç kaydetmeyen, sonradan bir müşteriden neden bu kadar az ücret alındığını açıklayan sayının tam olarak kendisini kaybeder.

Çalışmanızın çoğu faturalanabilir değilse varsayılanı “New entries are billable by default” anahtarıyla tersine çevirin.

Fabrika ayarı olarak her şey dakikası dakikasına faturalanır. Çeyrek saatle faturalayan iki değer ayarlar.

“Rounding increment (minutes)” adımdır. Her kayıt bir sonraki katına yukarı yuvarlanır.

“Minimum per entry (minutes)” tabandır. Her kayıt en az bu değerle faturalanır.

İkisi art arda çalışır: önce taban, sonra adım. Taban 20 ve adım 15 iken beş dakika otuz olur, çünkü sonuç ikisini de karşılamak zorundadır.

İki alanın altında kendi değerlerinizle bir örnek cümle durur. O, ileri sürülmüş değil, hesaplanmıştır.

Yalnızca faturalanan değer yuvarlanır ve yalnızca kayıt başına, hiçbir zaman toplam üzerinden. İki küçük kayıt bu yüzden iki kez yukarı yuvarlanır.

Kaydedilen süreye dokunulmaz. Yuvarlamayı sonradan değiştirmek hiçbir eski veriyi bozmaz, çünkü değer gösterilirken hesaplanır.

Kayıtta ikisini de görürsünüz: yuvarlamanın değeri değiştirdiği yerde sonuç yanında parantez içinde durur.

Bir hizmet sağlayıcı çoğu zaman kaydedilmiş süre olmadan hiçbir talebin kapatılmasını istemez. Bunun için bir anahtar vardır.

Adı “Require a time entry before resolving or closing” şeklindedir ve fabrika ayarı olarak kapalıdır.

Yalnızca bir kişi durumu değiştirdiğinde geçerlidir. Kaydı olmayan bir temsilci bir ileti alır ve talep açık kalır.

Otomatik kapatma, birleştirme ve toplu işlemler hiçbir zaman engellenmez. Yoksa kimsenin artık kapatamayacağı talepler olurdu.

Bu, özelliğin tamamının en tehlikeli anahtarıdır. Onu ancak ekibiniz gerçekten her seferinde süre kaydettiğinde açın.

Talep listesi, bir işte şimdiye kadar ne kadar kaydedildiğini gösteren bir “Time” sütunu alır.

Onu siz açmazsınız. Listedeki bir talep süre taşır taşımaz belirir.

Dar pencerelerde ilk düşenlerden biridir. Liste o zaman, onlarsız bir talebin bulunamayacağı sütunları korur.

Yalnızca tek bir talepte duran süre bir fatura temeli değildir. Bu yüzden rapor sayfası bir “Time spent” kartı taşır.

Üstte dört sayı durur: kaydedilen, faturalanan, kayıtların sayısı ve hiç süre taşıyan taleplerin sayısı.

Bu son sayı, toplamdan sonra en önemlisidir. Beş yüz talebin üçünde kırk saat bir değerlendirme değildir; yalnızca kayıt tutan üç temsilcidir.

Onun altında dökümler gelir: talep edene göre, ekibe göre, kategoriye göre ve güne göre.

Bunun üstüne özel alan başına bir tablo gelir. Şirkete ya da masraf merkezine göre faturalamanın yolu budur: bir özel alan oluşturursunuz, onu talepte doldurursunuz ve rapor ona göre gruplar.

Sayfanın üstündeki dönem, işin yapıldığı gün için geçerlidir. Haziran tarihli bir talepteki temmuz işi bu yüzden temmuz raporunda durur.

Sayıların üstündeki bir not ciddiye alınmayı hak eder: onlar insanların yaptığı kayıtlardan ve sizin yuvarlama kurallarınızdan gelir. Bir çalışma temelidirler, denetlenmiş bir fatura değil.

Kartın altında üç düğme durur. Onlar sayfadaki toplamları değil, tek tek kayıtları teslim eder.

Bunlar üç dosya biçimi değil, iki alıcıdır. “Export entries (CSV)” ve “Export entries (Excel)” muhasebeye gider: ikisi de eksiksizdir ve hiçbir zaman kısaltılmaz.

“Export entries (PDF)” bir insan için belgedir. Faturaya ek olarak müşteriye gider.

PDF 20.000 kayıtla sınırlanmıştır ve belge bunu kendisi söyler. Zaten kimse bundan daha çok satırlı bir faturayı okumaz.

Üç dosya da aynı kaynaktan kurulur: süzgeçler, yuvarlama, sütunlar ve sayılar bir kez vardır, böylece üçü birbirinden ayrılamaz.

Faturalanabilir olmayan bir kaydın faturalanabilir sütununda sıfır değil, boş bir hücre vardır. Bir sıfır, bir özet tabloda toplanırdı.

Bir müşteri süre kayıtlarını hiçbir zaman görmez, kendi talebinde bile.

Bu bir ayar değil, sunucudaki bir kilittir. Onu açan bir anahtar yoktur.

Nedeni kayıtların kendisindedir: notlar ekip için yazılır. Neyin ters gittiğini ve nedeni aramanın ne kadar sürdüğünü söylerler.

Bu türden diğer sistemler de aynısını yapar. Sürenin müşteriye ulaştığı yerde, ona bir belge olarak ulaşır.

PDF dışa aktarımı bunun içindir: faturayla birlikte çıkar, müşteri portalındaki talebe düşmez.

Rapor ek olarak kimin ne kadar kaydettiğini gösterebilir. Fabrika ayarı olarak göstermez.

Kişi başına süre başarı verisidir ve birçok şirkette çalışan temsilciliğinin bunda söz hakkı vardır.

Anahtarın adı “Per-agent evaluation” şeklindedir ve ayarlarda durur.

Kapalıyken sunucu sayıları teslim bile etmez. Tablo gizlenmiş değildir; yoktur.

Bu fark önemlidir. Yalnızca gösterimin bildiği bir kilit, kilit değildir.