Yanıt ve talep şablonları

Şablonlar “Settings → Templates” altında durur. Başlığın altındaki satır ne yaptıklarını ve ne yapmadıklarını söyler: “Reply templates fill the comment editor and suggest field actions. Nothing is sent automatically.” Şablon hazırlanmış bir hamledir, bir makine değil; her zaman kendiniz gönderirsiniz.

İki tür vardır ve oluştururken birini seçersiniz: açık bir talepteki yanıt için “Add reply template”, yeni talep formu için “Add ticket template”. Tür sonradan değiştirilemez, çünkü formun hangi alanları göstereceğine o karar verir. Her şablonun üstündeki rozet hangisine baktığınızı söyler: mavi “Reply template”, yeşil “Ticket template”.

Bir yanıt şablonu yanıt metninden (“Reply text”), “Internal note” onay kutusundan ve istediğiniz kadar eylemden oluşur. Altı eylem vardır: “Set the status”, “Set the priority”, “Assign to a user”, “Remove the assignee”, “Hand over to another team” ve “Set a follow-up”.

“Assign to a user” listesi “The agent who applies it” girdisiyle başlar. Şablonu birden çok kişi paylaşıyorsa onu seçin: talep o zaman listedeki sabit bir kişiye değil, onu uygulayana ait olur. “Set a follow-up” bir miktar ve bir birim (dakika, saat, gün, iş dakikası, iş saati, iş günü) ister, ayrıca talebin neden geri geldiğini sonradan size söyleyecek notu.

Her şablonun sonundaki mavi kutu ne yapacağını tek cümleyle yazar, örneğin “Inserts the text as a public comment, sets status to Waiting for Service Provider Response, assigns to the applying agent, sets a follow-up in 3 days.” Cümle siz düzenlerken kendini yeniden kurar. O sizin karşı denetiminizdir: niyet ettiğinizden başka bir şey söylüyorsa bir ayar yanlıştır.

Metin zorunlu değildir. “Bunu tek kelime yazmadan ağ ekibine devredin” geçerli bir şablondur; cümle o zaman “Suggests actions without a reply text” şeklinde okunur. “Set the status” eylemi, elle yapılan bir durum değişikliğiyle aynı kurallara uyar. Aynı anda birkaç talebe uygulandığında şablon kilitli talepleri atlar ve nedenini söyler.

“Close ticket” penceresi de “Template” alanında yanıt şablonları sunar. Yalnızca etkin “Set the status” eylemi çözülmüş ya da kapanmış sayılan bir durum ayarlayan şablonları listeler. Dahili şablonlar orada sunulmaz. Birini seçerseniz pencere onun metnini yorum olarak alır. Şablon posta gönderiyorsa ve pencere posta göndermeyi sunuyorsa alıcıyı yalnızca “Requester” ya da sabit bir adres olduğunda alır. Şablonun diğer eylemleri ve ekleri orada çalışmaz. Talep her zamanki gibi kapatılır.

Açık bir talepte yorum düzenleyicisinin üstünde “Template” düğmesi durur. Bir tıklama yazarken arama kutusunu açar (“Search templates…”), birini seçmek yorum düzenleyicisini doldurur. Başka hiçbir şey olmaz ve altındaki satır bunu söyler: “Nothing happens until you add the comment.”

Şablonun her eylemi düğmenin yanında bir rozete dönüşür, hem de teknik dille değil açık sözcüklerle: “sets status to Waiting for Service Provider Response”, “assigns to the applying agent”, “sets a follow-up in 3 days”. Bir rozete tıklamak onun üzerini çizer: çıkarılmıştır ve çalışmayacaktır. Bir tıklama daha onu geri getirir.

Çıkarılan eylemler kaldırılmaz, üzeri çizilir. Böylece şablonun neyi önereceği görünür kalır ve siz göndermediğiniz sürece karar geri alınabilir olur.

Hangi rozetlerin etkin başlayacağına şablon karar verir: ayarlarda her eylem bir “Suggested” anahtarı taşır. O anahtar her durum için öneridir; talepteki rozet ise bu durum için karardır.

Rozetlerin arkasındaki “×” şablonu yeniden kaldırır. Metin düzenleyicide kalır; onu belki çoktan yeniden yazmışsınızdır. Yalnızca etki, yani eylemler, posta ve ekler ortadan kalkar.

Her zamanki yorum düğmesiyle gönderirsiniz. Yorum ancak o zaman oluşur ve hâlâ etkin olan eylemler ancak ondan sonra çalışır.

Yanıt metni beş yer tutucu kullanabilir; liste alanın altında durur: “{requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}”. Onları süslü parantezle, tam orada göründükleri gibi yazın.

“{ticketRef}” talebin göndermesidir, “[TICKET-8-…]” biçimindedir. Sistem müşterinin yanıtı e-postayla geri geldiğinde onu ondan tanır. “{ticketId}” ise buna karşılık yalnızca çıplak numaradır.

Onlar şablon kaydedilirken değil, UYGULANIRKEN çözümlenir: ayarlar sayfası “{requesterName}” göstermeye devam eder, talepteki yorum düzenleyicisi gerçek adı gösterir. Nedeni pratiktir: kaydederken çözümleme, TEK bir talebin değerlerini şablona kalıcı olarak yakardı.

Böylece bitmiş metni, şirketten bir şey çıkmadan önce okursunuz. Hitap uymuyorsa onu düzenleyicide her metin gibi değiştirirsiniz.

Kimin “requester” sayılacağına hesap değil, talep karar verir: talepte kayıtlı talep eden, onu açan hesabın önüne geçer. Bir temsilci telefon görüşmesinden sonra bir meslektaşı için talep açarsa yanıt yine meslektaşa seslenir, temsilciye değil.

Yanlış yazılmış bir yer tutucu kaydederken geri çevrilir ve adlandırılır: “Reply text: unknown placeholders {requesterNam}. Available here: {requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}.” Böylece onu bir müşteride değil, şablonu yazarken fark edersiniz.

E-posta konusunun KENDİNE ait, daha kısa bir listesi vardır (“{originalSubject}, {ticketTag}, {ticketId}”) ve orada ikinci kez yazılmasının nedeni budur. “{ticketRef}” de orada çalışır ve “{ticketTag}” ile aynı anlama gelir. “{requesterName}”, “{ticketTitle}” ve “{agentName}” konuda çalışmaz ve aynı şekilde geri çevrilir.

“Send the comment as e-mail” anahtarı yorumu aynı zamanda postaya dönüştürür. Bunun için bilinçli olarak ikinci bir metin alanı yoktur: talepte ne yazıyorsa müşteri onu okur; iki metin er ya da geç birbirinden ayrılırdı.

“Recipient” altında şunlar arasında seçim yaparsınız: “Requester”, “Assignee”, “Observers” ve “Fixed address”. Talep edenin kim olduğunu şablon uygulanırken sunucu çözümler; bir şablon talebi henüz bilmez. Posta gelen kutusu hesabına hiçbir zaman yazılmaz; o, kendimize ileti göndermek olurdu. “User” alanında adresi olmayan bir ad varsa talep edene posta gitmez. Onun yerine talebi kaydeden kişiye de gönderilmez.

Konu “{originalSubject}”, “{ticketTag}” ve “{ticketId}” taşıyabilir. “{ticketTag}” ifadesini içeride tutun: sistem müşterinin yanıtını o göndermeden tanır ve aynı talebe ekler. O olmadan her yanıt yeni bir talebe dönüşür.

Posta düz metin olarak çıkar. Kalın yazı, listeler ve bağlantılar gönderilmeden önce ayıklanır, yoksa müşteri ham biçimlendirme kodunu okurdu. Talebin içinde yorum biçimlendirmesini korur.

Talepte posta, eylemlerin yanında bir rozet daha olur (“E-mail to Requester”) ve tıpkı onlar gibi çıkarılabilir. Böylece bir şablon siz görmeden hiçbir şey göndermez. Rozet yalnızca ekibin posta kutusu talep eylemi postaları gönderdiğinde görünür.

Bir şablonun ekleri (“Attachments”) dosyaların kendine ait kopyalarıdır. Şablonu uygulamak onları TALEBE ekler, geçmişte kendi satırlarıyla birlikte; postanın parçası değildirler. Bir şablonda ek taşımak Professional lisansı gerektirmez, yalnızca göndermek gerektirir. “Internal note” işaretli bir şablon dosya eklemez.

Çoğu şablon çizim masasında değil, aynı yanıtı ikinci kez yazdığınız anda doğar. Bu yüzden bir talepteki her yorum sağda küçük bir sayfa simgesi taşır, adı “Make template” şeklindedir. Tam olarak o yorumu başlangıç metni olarak alır, bir meslektaşın yorumunu da. Simgeyi yalnızca şablonları yönetebilen kişiler görür.

Talebin ekleri varsa önce bir pencere hangilerinin geleceğini sorar: “Tick only the attachments the template should carry — one of them may be a customer’s screenshot. Nothing is ticked by default.” Hiçbiri önceden işaretli değildir ve bu bilinçlidir.

Sonrasında henüz KAYDEDİLMEMİŞ bir taslakla şablonlar sayfasına inersiniz. Üstte kehribar rengi şerit durur: “Draft from ticket #… — name it and review the text (it may contain customer details), then save.” Ad boştur: bir tane vermeniz gerekir, yoksa kaydedilmez.

Devralınanlar: metin, “Internal note” onay kutusu, talebin ekibi ve talebin durumu öneri olarak; durumu ve önceliği iki eylem olarak zaten orada durur. Devralınmayanlar: talep eden, adres ve başlık. Onlar bu tek işe aittir.

Kaydetmeden önce metni okuyun. Gerçek bir işten gelir ve bir kişinin adını, bir sipariş numarasını ya da bir odayı taşıyabilir. Sizin için hiçbir şey anonimleştirilmez; şerit bunu söyler, ama yapmak sizin işinizdir.

Şablonu yalnızca “Save” oluşturur; işaretli ekler o zaman kopyalanır ve bir iletiyle onaylanır.

“Applies to” şablonun kime sunulacağına karar verir: belirli bir ekibe ya da “All teams” seçeneğine. Yeni bir şablon somut bir ekiple başlar; “All teams” birinin vermesi gereken bir karardır, sessiz bir varsayılan değil.

Bir talepte size sahip ekibin şablonları ve genel olanlar sunulur. Talep bir devretmeden sonra başka bir ekibe geçerse liste de onunla gider; seçebilecekleriniz yeni ekibin şablonlarıdır.

“Draft” anahtarı şablonu atölyenize dönüştürür: “Only you can see this template until you publish it.” Bir başkasının taslağı hiçbir listede görünmez ve adresinden de erişilemez, yöneticiler tarafından bile. Yeni bir şablon taslak olarak başlar; ancak siz onu kapatıp kaydettiğinizde diğerleri görür.

Karşılaşabilecek iki şablon aynı adı taşıyamaz: genel bir şablon, hangi ekipte olursa olsun aynı addaki her şablonla çakışır. Ancak bir yanıt şablonu ile bir talep şablonu aynı adı taşıyabilir; onlar hiçbir zaman aynı listede yan yana görünmez.

“Duplicate” bir kopya oluşturur ve kopya her zaman taslaktır: “Duplicated. The copy is a draft only you can see.” Yarım kalmış sürüm başkalarına sunulmadan bir varyanta ulaşmanın rahat yolu budur.

Bir talep şablonu “Create new ticket” formunu doldurur. Yanıt metni, eylemleri ve postası yoktur; o anda üzerinde işlem yapılacak bir talep yoktur. Form bu yüzden bir yanıt şablonundakinden başka alanlar gösterir ve yeşil çerçeve bir talep şablonuna baktığınızı söyler.

“Ticket title”, “Owning team of the new ticket”, “Main category”, “Subcategory”, “Priority” ve “Ticket description” alanlarını önceden doldurabilirsiniz. Her alan “Not prefilled” kalabilir; boş kalanı sonradan formu kullanan doldurur.

İki ekip alanı arasındaki farka dikkat edin: üstteki “Applies to” şablonu KİMİN göreceğini söyler. “Owning team of the new ticket” yeni talebin NEREYE gideceğini söyler. Bunlar iki ayrı sorudur ve yanıtları farklı olabilir.

Kategoriler ekibe göre gruplanır, çünkü bir kategori bir ekibe aittir. Başka bir ekipten birini seçerseniz form size bunu söyler ve kaydetme geri çevrilir: hedef ekibin yeni talep formunda o kategori hiç sunulmazdı, dolayısıyla önceden doldurma boşa çıkardı.

Burada yer tutucu yoktur ve metnin altındaki ipucu bunu söyler: “No placeholders here: the template only prefills the form, nothing is resolved or sent.” Bir “{requesterName}” yeni talepte harfi harfine görünürdü; kaydederken geri çevrilmesinin nedeni budur.

Mavi kutu şablonun burada ne yaptığını da özetler: “Prefills the new ticket with title ‘New notebook for a colleague’ · category Notebook / New request · priority Medium · team Helpdesk · the description.”

Formun kendisinde şablonu “Template” düğmesiyle seçersiniz; yanında “Prefills the form - nothing is created until you submit.” yazar. Önceden doldurulan her şey hâlâ değiştirilebilir ve siz göndermeden hiçbir şey oluşmaz.

Sistemle birlikte bir örnek şablon gelir: “Example: create accounts for a new colleague”. İşin biçimini gösterir ve kendiliğinden hiçbir şey yapmaz; onu yeniden kurun ya da silin.

“Offer this template to customers” anahtarı kutudan çıktığı gibi kapalıdır. Yanındaki ipucu bilmeniz gereken iki şeyi de söyler: “Customers can pick this template when they create a ticket. A draft stays hidden either way.”

Neden varsayılan olarak kapalı: bir şablon çoğu zaman iç sözcüklerle adlandırılır ve meslektaşlar için yazılır. Onu müşterilere görünür kılmak dışarıya yönelik bir ifadedir; birinin bunu rastlantıyla değil, bilerek yapması gerekir.

Müşteri yeni talep formunun üstünde aynı “Template” düğmesini görür, ama yalnızca açılmış şablonları. Bir taslak, anahtar açık olsa da gizli kalır; iki kural yan yana değil, art arda durur.

Amaç kolaylık değil, ilk temastır: eksiksiz gelen bir istek, yoksa iki gün sürecek soru turunu kazandırır. O soruları şablonun açıklamasına koyun; müşteri onları talebi oluştururken yanıtlar.

“Fields to ask for” ile daha ileri gidebilirsiniz. Şablon o zaman formun hangi özel alanları soracağına, hangi sırayla soracağına ve hangilerinin zorunlu olduğuna karar verir. Bu seçim ekibin olağan alanlarını EKLEMEZ, onların YERİNE geçer. Amacı tam olarak budur. Özel alanların kendisi Professional sürümünün parçasıdır; kartlarının adı “Custom fields” şeklindedir. Bir şablonu müşterilere açmak her sürümde çalışır.

Müşterilerden gizlenmiş bir alan, bir şablon onu listelese de gizli kalır. Alan seçimi düzen ve kesit aracıdır, alan ayarlarının etrafından dolaşmanın yolu değil.

Metin eklemekten fazlasını yapan her kullanım geçmişe “Template” alan adı altında TEK bir girdi yazar. Şablonu adlandırır. Çalışan eylemler kendi satırlarını yazar. O olmadan, bir talebin neden birden “In Progress” durumuna atladığını sonradan açıklamanın yolu olmazdı: tek tek eylemler kendi satırlarını yazar, ama hiçbiri şablonu adlandırmaz.

Resimde şöyle okunur: “Template ‘First reply: we have your ticket’ applied”. Şablonun ne yaptığı, örneğin durum değişikliği, kendi eylemlerinin satırlarında durur.

Çıkarılan eylemler içinde yoktur: onlar gerçekleşmedi. Bir başarısızlık içindedir ve “failed” sözcüğünün arkasında böyle adlandırılır. Eylemi, postası ya da eki olmayan düz bir metin şablonu tek bir talepte “Template” girdisi bırakmaz. Yalnızca metin eklemiştir. Aynı anda birkaç talebe uygulandığında girdi her zaman yazılır, dahili “Bulk” satırıyla birlikte.

Girdi DAHİLİDİR; talep eden onu görmez. Bir şablonun adı iç sözcüklerdir (“standard rejection”) ve geçmiş, talebi oluşturana da açıktır. Alan değişikliklerinin kendisi ona görünür kalır; yalnızca bir şablondan geldikleri görünmez.

Yazar temsilcidir, “system” değil ve şablon değil. Bu bilinçlidir: onu uygulamak onun kararıydı. Bir otomasyon kuralından farklı olarak burada talepte bir insan durur.