Bilet triyajı iç aracı: bir günlük model ve iş akışı planı

Bilet triyaj araçlarının aslında hangi problemi çözdüğü

E-posta, sohbet, web formu ve dahili mesajlaşmalardaki hızlı bildirimler aracılığıyla biletler geldiğinde aynı istek iki kez görünür ya da daha kötüsü hiç görünmez. İnsanlar ekran görüntülerini iletir, notları tablolarına kopyalar ve kimin neyi sahiplenmiş olduğunu hafızaya dayanarak takip eder. Acil maddeler gömülür ve en yüksek sesli mesaj kazanır.

Manuel triyaj ayrıca devredişlerde de bozulur. Bir istek bir sohbet dizisinde «atanmış» olarak işaretlenir, sonra atanan kişi çevrimdışına geçer ve kimse bir sonraki adımı bilmez. Durumlar farklı kişiler için farklı şeyler ifade eder, bu yüzden yöneticiler panolara güvenemez ve talep sahipleri olması gerekenden daha uzun bekler.

Geç kalan yanıtlar genellikle kötü niyetten kaynaklanmaz. Yapı eksikliğinden olur: net sahiplik, net son tarihler ve yükseltme için açık bir yol olmadığında gecikmeler yaşanır.

Bir bilet triyaj iç aracı, dağınık girişleri basit ve görünür bir akışa çevirerek bunu düzeltir. Bir günlük bir yapım için hedef tam bir yardım masası uygulaması değil. Genişletilebilecek güvenilir bir omurgadır.

Günün sonunda dört şeye ulaşmayı hedefleyin:

• Biletler, talep sahipleri, ajanlar ve etkinlik için temel bir veri modeli
• Net geçişler ve sahiplik kurallarıyla küçük bir durum seti
• Açıklanması kolay SLA zamanlaması ve yükseltme tetikleyicileri
• Günlük işler için kullanılabilir bir dahili pano ve bilet detay ekranı

Bunu AppMaster gibi görsel bir platformda inşa ederseniz, iş akışını kod yazmak yerine iş süreci mantığı olarak haritalandırabilir ve ekip alışkanlıkları gerektirdiğinde kolayca ayarlayabilirsiniz.

Bir günde yapılacak işin kapsamı: en küçük faydalı triyaj sistemi

Bir triyaj aracının ilk günde faydalı olması için üç şeyi güvenilir şekilde yapması gerekir: biletleri tek bir yere almak, bir sahip atamak ve gecikmiş işleri görünür kılmak. Diğer her şey bekleyebilir.

Başlangıç için bir veya iki bilet kaynağı seçin. İlk sürüm için genellikle e-posta ve basit bir web formu yeterlidir. Sohbet daha sonra gelebilir; çünkü gürültü ekler (kısa mesajlar, eksik ayrıntılar) ve genellikle istekleri gruplamak ve etiketlemek için ek kurallar gerektirir.

Bir bilete kimlerin dokunduğunu ve her grup için "bitti"nin ne anlama geldiğini belirleyin. Takım haritasını küçük ve net tutun. Örneğin: Support giriş ve temel düzeltmeleri yapar, Ops erişim ve hesap işlerini üstlenir, Engineering kod gerektiren hatalar ve değişikliklerle ilgilenir. Bir takım belirli bir bilet türünde işlem yapamıyorsa, o takıma atanabilir olmamalıdır.

Gerçekçi bir bir günlük kapsam için şu çıktılara bağlı kalın: bilet oluşturma ve görüntüleme (başlık, talep sahibi, aciliyet, kategori), triyaj ve atama (sahip ve takım, net bir «atanmamış» durumu ile), bir SLA saati izleme (ilk yanıt tarihi ve çözüm tarihi), süresi geçenlerde yükseltme tetikleyicileri (doğru kanalı veya kişiyi bilgilendir) ve kısa bir sonuç notuyla kapatma.

Bu, AppMaster içinde güzel oturur: basit bir veri modeli, temel bir dahili pano ve atama ile yükseltme bildirimleri için görsel iş süreçleri mantığı.

Şimdilik metrikleri atlayın. Ham veriyi yakalayın (zaman damgaları, durum değişiklikleri, atama geçmişi) ama raporları hemen kurmayın. Daha sonra ilk yanıt süresi veya en çok görülen kategoriler gibi eğilimler için panolar ekleyin, ancak analitik araçlar bugün ihtiyaç duyulan aracı geciktirmesin.

İyi bir sezgi testi: yeni bir istek 09:00'de gelirse ve kimse 11:00'e kadar bakmadıysa, ilk sürüm bu hatayı görünür ve göz ardı edilmesi zor hale getirmelidir.

Roller, erişim ve hesap verebilirlik

Bir triyaj aracı, kimsenin açıkça sorumlu olmadığı durumda başarısız olur. Önce gerçekten ihtiyaç duyduğunuz birkaç rolü adlandırın, sonra izinleri gerçek destek işleyişine uyacak şekilde ayarlayın.

Çoğu takım neredeyse her şeyi dört rol ile karşılayabilir:

• Requester: bilet oluşturabilir, yorum ekleyebilir ve yalnızca kendi biletlerini görür.
• Agent: kendisine atanan biletleri çalışır ve durum, öncelik ile notları günceller.
• Team lead: takımdaki işleri yeniden atayabilir, yükseltmeleri onaylayabilir ve önceliği geçersiz kılabilir.
• Admin: takımları, kategorileri ve SLA kuralları gibi genel ayarları yönetir.

Görünürlük bir sonraki karardır. Bir model seçin ve ona sadık kalın, yoksa insanlar araca güvenmeyi bırakır.

Pratik bir yaklaşım: talep sahipleri yalnızca kendi biletlerini görsün; ajanlar kendi takım kuyruklarını görsün; takım liderleri kendi departmanlarının tüm biletlerini görsün; adminler her şeyi görsün. Gizlilik gerekiyorsa, sadece liderler ve adminlerin açabildiği "kısıtlı" bir bayrak ekleyin.

Hesap verebilirlik, büyük bir izin matrisi değil, birkaç sıkı kuraldan gelir. Örneğin, sadece liderler ve adminler ekipler arası sahipliği değiştirebilir; yalnızca atanan kişi (veya lider) bir bileti Çözüldü durumuna taşıyabilir; kapatma bir çözüm notu ve kategori gerektirir; yeniden açma bir gerekçe ister.

Son olarak, bir denetim izi zorunlu kılın. Hizmeti etkileyen her değişiklik kaydedilmelidir: durum, atanan, öncelik, SLA seviyesi ve herhangi bir yükseltme. Kim yaptı, ne zaman yaptı ve eski ile yeni değerlerin ne olduğu saklanmalıdır.

AppMaster içinde, yerleşik kimlik doğrulama ile bunu zorlayabilir ve ana alanlar değiştiğinde bir AuditEvent kaydı yazan görsel iş süreçleri oluşturabilirsiniz.

Hızlı bir test: bir lider "Bu bilet neden 18:12'de Çözüldü olarak işaretlendi?" diye sorsa, sisteminizin tek bir ekranda cevabı vermesi gerekir.

Veri modeli kılavuzu: ihtiyaç duyacağınız tablolar ve alanlar

Bir bilet triyaj aracı veri modeline bağlıdır. Tablolar temizse, iş akışı ve pano inşası basit kalır (ve sonradan değiştirmesi kolay olur).

Veritabanınızda (örneğin AppMaster Data Designer ile PostgreSQL) beş yapı taşı ile başlayın:

• Tickets: subject, description, channel (email, web, phone), priority, current status, requester info, ayrıca created_at ve updated_at.
• People structure: users (ajanlar ve adminler) ve teams (support, billing, ops). Takım üyeliği, rol ve on_call bayrağı ekleyin ki iş akışı doğru kişiyi hızlıca bulabilsin.
• Assignment history: hızlı filtreleme için ticket üzerinde current_assignee_id tutun, ama her yeniden atamayı assigned_by, assigned_to, reason ve assigned_at ile saklayın.
• Conversation: visibility bayrağı olan yorumlar veya mesajlar (internal note vs customer-facing). Eklentileri (attachments) ayrı bir tablo yapın ki mesajlarda veya denetim kayıtlarında yeniden kullanılabilsin.
• Audit log: durum değişiklikleri, SLA sayaç başlangıç/durdurma ve yükseltme olaylarını kaydetmek için tek bir yer.

Gelecekte sorun çıkarmayacak birkaç alan ekleyin. first_response_due_at ve resolve_due_at alanlarını ekleyin (hesaplasanız bile saklayın). last_customer_message_at ve last_agent_message_at alanlarını tutun ki karmaşık sorgulara gerek kalmadan sessizlik tespit edebilin.

Durumları ve öncelikleri enum (veya referans tablolar) yapın. Bu, raporlama tutarlılığını korur ve "High", "HIGH" ve "Urgent!!!" gibi farklı etiketlerin oluşmasını engeller.

Anlaşılır kalan durumlar ve geçişler

İnsanların bir durumu ne anlama geldiğini söyleyemediği zaman triyaj aracı bozulur. Seti küçük ve açık tutun. Basit bir temel: Yeni, Triyajlandı, İşlemde, Beklemede, Çözüldü, Kapandı. Takım yedinci bir durum için tartışıyorsa genellikle etiketleme sorunudur, iş akışı sorunu değil.

Durumlar en iyi şekilde her birinin tek bir soruya cevap verdiği zaman çalışır:

• Yeni: bunu biri inceledi mi?
• Triyajlandı: kimin sahip olduğu ve ne kadar acil olduğu belli mi?
• İşlemde: biri aktif olarak üzerinde çalışıyor mu?
• Beklemede: müşteri, tedarikçi veya başka bir takım yüzünden mı engellendik?
• Çözüldü: bir çözüm veya yanıt mı sağlandı?
• Kapandı: takip ve raporlama için iş bitirildi mi?

Geçişler kazanılan veya kaybedilen netliği belirler. Nereye kimin taşıyabileceğini yazın. AppMaster'da bu kuralları görsel iş mantığında zorlayarak UI'ın sadece geçerli sonraki eylemleri göstermesini sağlayabilirsiniz.

Kaçışları engelleyen pratik kurallar:

• Sadece triyaj rolü Yeni -> Triyajlandı geçişini yapabilir ve öncelik ile atamayı ayarlayabilir.
• Sadece atanan kişi Triyajlandı -> İşlemde geçişini yapabilir.
• Herhangi bir ajan Beklemede durumunu seçebilir, ancak mutlaka bir bekleme nedeni (Müşteri yanıtı, Tedarikçi, Dahili bağımlılık) seçmelidir.
• Çözüldü bir çözüm notu gerektirir; Kapandı kapanış nedeni (Tekrar, Düzeltmeyecek, Onaylı düzeltme vb.) gerektirir.
• Yeniden açma yalnızca Çözüldü veya Kapandı'dan yapılabilir ve her zaman bir yeniden açma nedeni ister.

Hangi olayların zaman damgalarını oluşturduğunu baştan kararlaştırın; çünkü bu raporları ve SLA'ları besler. İlk yanıt süresi, insanın attığı ilk kamuya açık yanıtla kilitlenmelidir. Çözüm zamanı durum Çözüldü olduğunda kilitlenmelidir. Eğer bir bilet yeniden açılırsa, orijinal zaman damgalarını saklayın ve tekrar oluşan olay için ayrı bir reopened_at ekleyin ki tekrar eden sorunları geçmişi yeniden yazmadan görebilesiniz.

SLA'ları karmaşıklaştırmadan modellemek

SLA bir söz ve bir zamanlayıcıdır. Ekiplerin gerçek kullanımlarına uygun zamanlayıcılara odaklanın: ilk yanıt (birinin acknowledge etmesi), sonraki yanıt (konuşmanın devam etmesi) ve çözüm (işin bitmesi).

Kuralı nasıl seçeceğinize karar verin. Basit bir yaklaşım önceliğe göre seçmektir. Müşteri türü destekleniyorsa, ek bir anahtar olarak müşteri katmanını ekleyin. Bu, istisnalar labirenti olmadan öngörülebilir SLA kuralları verir.

SLA bitiş zamanlarını sadece süre olarak değil zaman damgası olarak saklayın. Her ikisini de saklamak isterseniz saklayın, ama raporlama ve yükseltmelerin güvenilir olması için deadline timestamp gereklidir. Örneğin, bir P1 bilet 10:00'de oluşturulduğunda FirstResponseDueAt = 10:30, NextResponseDueAt = 12:00, ResolutionDueAt = 18:00 gibi hesaplanıp saklanır.

Saatin ne zaman durduğunu açıkça tanımlayın. Çoğu takım sonraki yanıt ve çözüm saatini "Beklemede müşteri" durumunda duraklatır, ancak ilk yanıtı duraklatmaz.

• İlk yanıt zamanlayıcısı bilet oluşturulunca başlar
• Sonraki yanıt zamanlayıcısı son ajan yanıtından sonra başlar
• Zamanlayıcılar yalnızca belirli durumlarda duraklatılır (ör. Beklemede)
• Bilet aktif bir duruma döndüğünde zamanlayıcılar devam eder
• İhlal, "şimdi" saklanan bitiş zamanını geçince olur

Bir SLA'nın karşılandığını neyin oluşturduğunu açıkça tanımlayın. Her zamanlama için bir etkinlik seçin ve ona bağlı kalın: bir ajan yorumu, İşlemde durumuna geçiş veya gönderilen bir mesaj gibi.

AppMaster'da bunu İş Süreci Editörü'nde, ticket created, comment added ve status changed tetikleyicileriyle modelleyip bitiş zamanlarını yeniden hesaplayıp ticket'a yazdırarak uygulayabilirsiniz.

Adım adım iş akışı: yeni biletten kapatmaya

Bir bilet triyaj aracı, yolunun tahmin edilebilir olduğu zaman en iyi şekilde çalışır. Çoğu bilet için bir "mutlu yol" hedefleyin ve istisnaları görünür tutun.

1) Bileti oluşturma (varsayılanları ayarla)

Bir bilet oluşturulduğunda (form, e-posta veya dahili istekten), hiçbir şey yarım başlamasın diye birkaç alanı otomatik ayarlayın. Başlangıç durumu genellikle Yeni olur, varsayılan bir öncelik (Normal), talep sahibi ve created_at ile last_activity_at gibi zaman damgalarını kaydedin.

Triyaj için gereken asgari bilgiyi yakalayın: kısa başlık, açıklama ve kategori veya hizmet alanı. Eksikse bileti Incomplete olarak işaretleyin ki yanlışlıkla atanmasın.

2) Triyaj (çalışmaya hazır hale getirme)

Triyaj hızlı bir kalite kontrolüdür. Gerekli alanları onaylayın, bir kategori belirleyin ve basit kurallardan SLA bitiş zamanlarını hesaplayın (ör. öncelik + müşteri türü = ilk yanıt süresi). AppMaster kullanıyorsanız bu, görsel bir iş süreci olarak due_at alanlarını yazıp bir triage_event kaydı oluşturabilir.

Devam etmeden önce hızlı bir "bu bizim mi?" kontrolü yapın. Eğer değilse, doğru kuyruğa yönlendirin ve kısa bir not ekleyin, böylece geri geri dönmez.

3) Atama (sahibi seçme ve bildirme)

Atama gün 1 için manuel olabilir veya kural tabanlı (kategori -> takım, sonra en düşük açık sayısı). Atanan kişi belirlendiği anda durumu Triyajlandı olarak tutun ve sahipliği görünür kılmak için net bir bildirim gönderin.

4) Çalışma (zaman ve iletişimi doğru tutma)

Çalışma sırasında İşlemde veya Beklemede gibi durum değişikliklerine izin verin. Her kamuya açık yanıt next_response_due zamanını güncellemeli ve her yorum last_activity_at değerini güncellemelidir. Bu, SLA takibini ve yükseltmeleri güvenilir kılar.

5) Çözüm ve kapatma (sonucu yakalama)

Çözüm kısa bir özet, bir çözüm kodu (düzeltildi, düzeltmeyecek, kopya) ve resolved_at gerektirmelidir. Kapatma sessiz bir dönem sonrası otomatik veya onayla manuel olabilir, ama her zaman closed_at saklanmalıdır ki raporlama tutarlı kalsın.

İnsanların görmezden gelmediği yükseltme bildirimleri

Yükseltmeler iki nedenle başarısız olur: çok sık tetiklenirler veya alıcıya ne yapması gerektiğini söylemezler. Hedef daha fazla uyarı değil. Doğru zamanda tek bir net dürtüdür.

Birkaç tetikleyici seçin, her durumu değil

Açıklaması ve test edilmesi kolay tetikleyicilerle başlayın. Çoğu takımın ihtiyaç duyduğu küçük set: SLA riske girdi (ör. pencerenin %75'i geçti), SLA ihlal oldu, kısa bir tolerans süresi sonrası atanmadı (10-15 dakika gibi) ve Beklemede uzun süre kalma.

Her tetikleyiciyi sorunu çözebilecek en küçük kişilere yönlendirin. Önce atanan kişiyi bildirin. Atanan yoksa takım liderini veya on-call rotasyonunu bilgilendirin. Talep sahibini yalnızca girdi gerektiğinde veya vaat edilen çözüm zamanını değiştirdiğinizde bilgilendirin.

Uyarıyı eyleme geçirilebilir ve görmezden gelinmesi zor yapın

İyi bir yükseltme mesajı bilet başlığını, önceliği, mevcut durumu, kalan süreyi (veya geçen süreyi) ve bir sonraki adımı içerir. Örnek: «Bilet #1842, ihlalden 30 dakika uzakta. Durum: İşlemde. Sahip: atanmamış. Sonraki: bir sahip ata veya önceliği not ile düşür.»

Amaçlı kanallar kullanın. Riskte olanlar için e-posta uygundur. İhlal veya kritik atanmadı durumları için SMS veya Telegram daha uygundur. Uygulama içi bildirimler, pano içindeki sessiz dürtmeler için iyidir.

Spam'ı önlemek için basit soğuma (cooldown) kuralları ekleyin: her aşama için bir uyarı, tekrar etmeden önce örn. 60 dakika bekleme. Bilet durum veya sahibi değişirse yükseltme zamanlayıcısını sıfırlayın.

Her bildirimi kaydedin ki güven sorunlarını daha sonra çözebilin. En azından ne zaman gönderildiğini, hangi tetikleyiciden kaynaklandığını, kanal ve alıcıyı ve teslim sonucunu (gönderildi, başarısız, geri döndü) saklayın. Eğer onay (tıklandı, yanıtlandı, görüldü) yakalayabiliyorsanız onu da saklayın.

AppMaster'da bu, bir Notification tablosuna ve zamanlayıcıları kontrol eden, alıcıları seçen (atanan, lider, on-call) ve e-posta, SMS veya Telegram modülleri aracılığıyla gönderip aynı zamanda uygulama içi kaydı yazan bir iş süreçlerine doğal olarak uyar.

Tasarımınızı test edecek gerçekçi bir senaryo

Ekranları inşa etmeden önce zorlu bir senaryoyu çalıştırın. Durumlarınızı, tarihleriniz ve bildirimlerinizi gerçek hayatta mantıklı kılıp kılmadığını hızlıca gösterir.

Saat 12:10. Önemli bir müşteriden gelen "Ödeme başarısız" başlıklı bir bilet geliyor; başlıkta acil işaretli ama atanmış değil. Triyaj sisteminiz, öğle arasında kimse panoya bakmasa bile bunu zaman duyarlı olarak ele almalıdır.

Önce triyaj Kategori = Billing ve Priority = Urgent olarak ayarlar. Bu alanlar ayarlandığı anda sistem ilk yanıt bitiş zamanını (ör. 15 dakika) hesaplar ve bilete kaydeder. Bu bitiş, liste görünümünde görünür olmalı, gömülü olmamalıdır.

Sonra otomatik atama devreye girer. Billing için on-call ajansı seçer ve kısa bir bildirim gönderir: "Acil ödeme biletiniz atandı. İlk yanıt 12:25'te bekleniyor." AppMaster içinde bu, ticket creation (veya priority change) tetikleyicisi ile birkaç karar bloğu olarak görsel iş sürecine kolayca sığar.

12:25'e kadar hala kamuya açık bir yanıt yoksa yükseltme çalışır. Basit ve tutarlı kalın: takım liderini bilgilendir, ilk yanıt SLA'sının kaçırıldığını içeren iç not ekle ve yeni bir escalation_level alanı ayarlayın (insanların yanlış kullanacağı yeni bir durum icat etmek yerine).

12:40'ta ajan yanıt verir ve bileti Beklemede (Müşteri) olarak işaretler. SLA bu sırada durmalı. Müşteri 14:05'te yanıt verdiğinde SLA kaldığı yerden devam etmeli, sıfırdan başlamamalıdır. Bu tek test çoğu iş akışı hatasını yakalar.

İlk olarak inşa edilecek ekranlar

Bir günde, işleri azaltacak ekranları oluşturun: kuyruk görmek için bir yer, karar vermek için bir yer ve çalışmak için bir yer.

1) Bilet listesi (triyaj kuyruğu)

Bu ana ekrandır. 10 saniyede şu an neye dikkat edilmesi gerektiğini yanıtlamalıdır.

İnsanların gerçekten nasıl triyaj yaptığına uyan filtreleri ekleyin: status, priority, SLA durumu (yolda, riskte, ihlal), atanmadı ve kategori.

Her satırı kompakt tutun: başlık, talep sahibi, öncelik, mevcut sahip, SLA geri sayımı ve son güncelleme zamanı.

2) Bilet detayı (işin yapıldığı yer)

Detay sayfası tek bir zaman çizgisi gibi hissettirmeli. Önemli eylemleri en üste koyun: ata, durum değiştir, yorum ekle, öncelik belirle. Sonra tam geçmişi (durum değişiklikleri, atamalar, yorumlar) sırayla gösterin.

SLA'yi rahatsız etmeyecek şekilde görünür kılın. Basit bir geri sayım etiketi ve renk yeterlidir. Kenar durumlar için net bir Yükselt (Escalate) eylemi ekleyin.

3) Triyaj formu (hızlı giriş)

Birisi bilet oluştururken asgari alanları zorunlu kılın: kategori, kısa özet ve etki. Bana ata ve Kopya olarak işaretle gibi hızlı eylemler ekleyin. Mümkünse kategori veya iş yüküne göre önerilen atananı gösterin.

4) Ajan görünümü vs lider görünümü

Ajanlar için Benim biletlerim, Vakti gelenler ve tek tıklamayla durum güncellemeleri gerekir. Liderler için Atanmamış, Riskte ve İhlal olmuş listeyi ve hızlı yeniden dengeleme araçlarını sağlayın.

5) Küçük admin ekranı

Admin sıkı tutun: kategorileri ve SLA kurallarını (kategori ve önceliğe göre) yönetin, ayrıca kim rotasyonda onu belirleyin. AppMaster'da bu ekranlar UI oluşturucularla hızlıca toplanırken kurallar görsel iş süreçlerinde durur; böylece uygulamayı yeniden yazmadan değiştirebilirsiniz.

Triyaj sistemini bozan yaygın tuzaklar

Çoğu triyaj aracı basit nedenlerle başarısız olur: kurallar belirsizdir ve UI açık kararlar yerine geçici çözümlere teşvik eder.

İlk tuzak durum çoğalmasıdır. Takımlar her uç durum için yeni bir durum ekler ("Tedarikçi Bekliyor", "Finans Bekliyor", "Ürün Engeli"), ve kısa sürede kimse her birinin ne anlama geldiği konusunda hemfikir olmaz. Durumları az tutun ve ilerlemek için neyin doğru olması gerektiğini tanımlayın (ör. İşlemde = atanan var ve sonraki adım biliniyor).

SLA zamanlaması ikinci tuzaktır. Hiç durmayan bir saat, ajanları müşteri beklediğinde cezalandırır. Her zaman duran bir saat ise SLA'ları anlamsız kılar. Bir cümlede açıklanabilecek açık duraklatma kuralları seçin ve bunları küçük bir durum setine bağlayın (ör. yalnızca müşteri bekleniyorken duraklat).

Bildirimler genellikle sahibinin olmaması nedeniyle başarısız olur. Uyarılar herkese gönderildiğinde arka plan gürültüsüne dönüşür. Yükseltmeler belirli bir kişiye veya role gitmeli ve ne yapılacağı açıkça belirtilmelidir.

Yaygın başarısızlık örüntüleri:

• Durum adlarının duyguları ("Sıkıştı") değil, koşulları ("Müşteri yanıtı bekleniyor") tanımlaması.
• SLA kurallarının yargıya dayalı olması ("adil görünüyorsa duraklat").
• Yükseltme uyarılarının geniş kanallara gönderilmesi yerine on-call lidere veya takım gelen kutusuna gitmesi.
• Değişiklik geçmişinin olmaması (öncelik kim değiştirdi, ne zaman yeniden atandı veya yeniden açıldı gibi).
• Talep sahibi mesajlarının dahili notlarla karışması ve istemeden aşırı paylaşım.

Basit bir test: bir bilet yükseltildiğinde ve talep sahibi şikayet ettiğinde, bir dakikada kimin hangi adımda sahibi olduğunu, SLA'nın ne zaman durduğunu ve dışarıya ne söylendiğini cevaplayabiliyor musunuz? Eğer hayırsa, bir denetim izi ve kamuya açık yanıtları dahili notlardan ayırın. AppMaster'da bunu ayrı veri alanlarıyla ve hangi ekranın hangisini gösterdiğini zorlayan iş süreçleriyle uygulayabilirsiniz.

Hızlı kontrol listesi ve sonraki adımlar

İnşa etmeden önce "yarın çalıştırabilir miyiz?" zihniyetiyle bir geçiş yapın. Araç yalnızca veriler, kurallar ve bildirimler birbirleriyle uyumlu olduğunda işler.

Kontrol edin:

• Veri modeli: Tickets (başlık, açıklama, öncelik, durum, talep sahibi), Users, Teams, Comments, Audit Log (kim neyi ne zaman değiştirdi) ve SLA bitiş tarihleri (first_response_due_at, resolve_due_at, paused-until).
• İş akışı: Net geçişler (Yeni -> Triyajlandı -> İşlemde -> Beklemede -> Çözüldü -> Kapandı), atama kuralları (manuel vs otomatik) ve SLA'lar için basit duraklatma/ devam kuralları (sadece Beklemede iken duraklat, aktif duruma dönünce devam).
• Bildirimler: Tetkleyiciler (yakında ihlal, ihlal oldu, yeniden atandı, yükseltildi), alıcılar (atanan, takım lideri, on-call), sınırlama (dakikada ping atma) ve kayıtlı sonuçlar.
• UI: Kuyruk için liste görünümü, bilet detay sayfası, triyaj ekranı (ata, öncelik ayarla, durum değiştir) ve kategoriler, SLA ayarları ile rotasyon yönetimi için küçük admin alanı. Rol tabanlı erişimi belirgin yapın.
• Hesap verebilirlik: Her bilet için aynı anda bir sahip, bir sonraki eylem ve herkesin görebileceği bir bitiş zamanı.

Önce tabloları oluşturun, sonra iş akışını bağlayın. AppMaster'da veritabanını Data Designer (PostgreSQL) ile modelleyip, ardından durum geçişlerini, SLA zamanlayıcılarını ve yükseltme kurallarını Business Process Editor'da görsel mantıkla uygulayın. Bir takımla ve bir SLA politikasıyla başlayın, haftalık çalıştırın ve ancak sonra karmaşıklık ekleyin (birden fazla kuyruk, mesai saatleri, özel formlar).

Stabil hissettiğinizde, ekibin rahat olduğu ortamda dağıtın: AppMaster Cloud, AWS, Azure, Google Cloud veya ihtiyacınız varsa kaynak kodu dışa aktararak kendi ortamınızda barındırın. AppMaster adını ve appmaster.io adresini içeren değerlendirmeler, görsel iş akışları ve üretime hazır uygulama oluşturma seçeneklerini keşfetmek için bir başlangıç noktası sağlar.