Görev Atama Yazılımı Nasıl Seçilir? Dispatch'te 6 Kritik Özellik

Saha ekibi yönetiminde en çok zaman harcanan operasyonel karar, hangi teknisyenin hangi işi ne zaman yapacağıdır. Bu karar günde onlarca kez tekrarlanır; her tekrar koordinasyon çabasına, telefon trafiğine veya gözden kaçan çakışmalara açık bir penceredir.

Genel amaçlı proje yönetimi veya CRM araçları bu denklemi çözemiyor çünkü saha atamasında kısıtlar çok boyutludur: teknisyenin konumu, sertifikası, aracındaki parça stoku, aktif işinin bitmesi beklenen saat, müşterinin tercih ettiği zaman aralığı ve SLA saati aynı anda hesaba katılmalıdır. Bunları Excel veya WhatsApp üzerinde dengelemek, operasyon büyüdükçe hata üretmeye başlar.

Piyasada 'iş takibi', 'görev yönetimi' ve 'dispatch yazılımı' başlıkları altında konumlanan onlarca araç bulunmakta. Bunların büyük çoğunluğu ilk 10 teknisyen için yeterli görünse de operasyon 20-30 kişiyi geçtiğinde önemli kırılma noktaları ortaya çıkıyor. Bu nedenle satın alma kararı, yalnızca bugünkü değil 12-18 ay sonraki operasyon yükünü de kapsayan bir perspektifle verilmelidir.

Peki doğru yazılımı hangi kriterlere göre seçersiniz? Bu yazıda satın alma kararını netleştiren 6 temel özelliği inceliyoruz ve sonunda bağımsız bir karar matrisi sunuyoruz.

Görev atama yazılımlarının en belirgin ayrım noktası, karar yetkisinin nerede olduğudur. Bazı sistemler gelen işi belirli kurallara göre doğrudan atayıp teknisyene bildirim gönderir; bazıları dispatchar'a öneri sunar ve son kararı insana bırakır. Her iki uç da kendi başına yetersiz kalabilir.

**Tam otomatik atama** hız avantajı sağlar, ancak kural setinin karmaşıklığı arttıkça hata payı da büyür. Sertifikası olan ama o gün erken izne çıkan bir teknisyene otomatik atama gitmesi, hem müşteri deneyimini hem de SLA saatini etkiler.

**Katı manuel süreç** ise operasyon hacmi arttıkça bottleneck yaratır; dispatcherın gözünü kaçırdığı ya da mevcut bilgiyi bilmediği atamalar gecikmeye yol açar.

İdeal çözüm, otomatik atama motoru ile güçlü bir manuel override kombinasyonudur. Yazılımın şu soruları yanıtlaması gerekir: Dispatcher tek tıkla öneriyi geçersiz kılabiliyor mu? Override gerekçesi kayıt altına alınıyor mu? Otomatik atama hangi kurallara dayanıyor ve bu kurallar yönetim panelinden düzenlenebiliyor mu? Bu sorulara net yanıt alamadığınız her sistem, ilerleyen süreçte esneklik sorunu yaratır.

Atama motorunun yalnızca 'en yakın teknisyen'e bakması, sahada sık karşılaşılan bir hatayı üretir: işi tamamlayacak yetkinliğe sahip olmayan kişiyi yola çıkarmak. Bu durum hem müşteri memnuniyetini düşürür hem de first-time-fix (FTF) oranını olumsuz etkiler.

Yetkinlik eşleştirme özelliği, her teknisyenin profilinde hangi hizmet türlerini, cihaz modellerini veya güvenlik sertifikalarını (elektrik yetki belgesi, basınçlı kap muayeneci belgesi vb.) taşıdığını saklayarak atama önerilerini bu filtreyle sınırlar. Temel beklentiler şunlardır:

• Hizmet tipi bazında yetkinlik ataması (klima kurulum, periyodik bakım, acil arıza gibi ayrımlar)
• Sertifika geçerlilik tarihi takibi ve süre dolduğunda otomatik dışlama
• Kısmi yetkinlik senaryoları (ekip lideri eşliğinde çalışabilir gibi hiyerarşik profil)

Bu özellik yoksa ya da yüzeysel kalıyorsa, atama kararları her zaman dispatcherın hafızasına kalmaya devam eder. Hafıza ise ölçeklenebilir değildir.

Derinlemesine bilgi için Saha Ekibi Takip Programı Nasıl Seçilir? başlıklı rehberimize bakabilirsiniz.

Her gün hem planlı bakım hem de beklenmedik arıza çağrıları aynı anda akar. Bu iki tür işi aynı sıraya almak operasyonun dengesini bozar; acil bir arıza saatler sonrasına sarkabilir ya da özenle planlanmış periyodik bakım takvimi tutarsız hale gelir.

Sağlam bir dispatch motoru, öncelik kurallarını birden fazla boyutta tanımlamanıza izin vermelidir:

• **SLA tabanlı önceliklendirme:** Yanıt süresi kısa olan müşteri sözleşmeleri otomatik olarak kuyruğun üstüne taşınır.
• **İş tipi tabanlı önceliklendirme:** Belirli arıza kodları veya ekipman kategorileri (örn. doğalgaz güvenlik valfi) acil bayrağı taşır.
• **Müşteri segmenti tabanlı önceliklendirme:** VIP ya da kritik altyapı müşterileri ayrı bir öncelik kümesinde değerlendirilebilir.

Sistemi seçmeden önce şu soruyu sorun: Kural mantığı değiştiğinde teknik destek açmak zorunda kalıyor musunuz, yoksa operasyon yöneticisi bunu kendisi yapılandırabiliyor mu? Kural setini düzenleyebilmek için her seferinde satıcıya bağımlı olmak, operasyonel esnekliği ciddi ölçüde kısıtlar.

Teknisyen kapasitesini görsel olarak yönetememek, iki farklı sorunu aynı anda üretir: bazı ekip üyeleri üst üste işlerle bunalırken, bazıları neredeyse boş kalır. Bu dengesizlik hem teslim süresini hem de çalışan memnuniyetini etkiler.

Kapasite dengesi özelliği, dispatcherın gün içinde her teknisyenin takvimini doluluk oranıyla birlikte görmesini sağlar. Gelişmiş sistemlerde bu görünüm gerçek zamanlı güncellenir: aktif işin tahmini bitiş saati değiştiğinde sonraki atamanın zamanlaması otomatik olarak kaydırılır.

Bir yazılımı bu kriter üzerinden değerlendirirken dikkat edilecek noktalar:

• **Seyahat süresi hesabı:** Bir iş bittiğinde bir sonraki iş yerine ulaşma süresi kapasiteye dahil ediliyor mu? Bu hesap olmadan takvim görünür boş gözüküp sahada zaman açığı oluşur.
• **Çalışma saati sınırları:** Teknisyenin mesai bitişi veya yasal dinlenme süresi (4857 sayılı İş Kanunu md. 63-68 kapsamında) atama algoritmasına kısıt olarak eklenebiliyor mu?
• **Tampona alma mekanizması:** Beklenmedik işler için rezerv kapasite (buffer) tanımlanabiliyor mu?

Kapasite görünürlüğü olmadan yapılan atama, kağıt üzerinde dolu görünen ama pratikte kaçan randevu demektir.

Planlar, her zaman planlandığı gibi yürümez. Teknisyen hastalanır, araç arızalanır, bir önceki iş uzar. Bu anlarda ne kadar hızlı ve tutarlı bir şekilde yeniden atama yapabildiğiniz, dispatch yazılımının gerçek değerini ortaya koyar.

Reassign akışının üç temel boyutu vardır:

**Hız:** Dispatcher, etkilenen tüm işleri tek ekranda görüp alternatif teknisyen önerisiyle birlikte yeniden atama yapabiliyor mu? Yoksa her iş tek tek mi açılıyor?

**Müşteri bilgilendirmesi:** Yeniden atama yapıldığında, müşteriye otomatik SMS/e-posta bildirimi gidiyor mu? Manuel bilgilendirme gerektiren sistemlerde bu adım çoğunlukla atlanır ve müşteri hayal kırıklığına yol açar.

**Denetim izi:** Kimin ne zaman kimi hangi gerekçeyle yeniden atadığı kayıt altına alınıyor mu? SLA ihlali yaşandığında bu kayıt hem iç analiz hem de müşteriye hesap verebilirlik açısından kritiktir.

Bu üç boyutu kapsayan bir reassign akışı, iyi organize edilmiş bir operasyonun temel güvencesidir. Manuel Çizelge vs Optimizer vs Hibrit Atama: 3 Workforce Scheduling Yöntemi başlıklı yazımız, bu tür akış kararlarını büyük ölçek senaryolarında nasıl ele alacağınızı gösteriyor.

Görev atama yazılımının değeri, tek başına çalışmasından değil; mevcut sistemlerle konuşmasından gelir. İki kritik entegrasyon noktası öne çıkar: takvim ve CRM.

**Takvim entegrasyonu** (Google Calendar, Microsoft 365 / Exchange, ya da iCalendar RFC 5545 uyumlu herhangi bir sistem), teknisyenin kişisel izin taleplerini, toplantılarını veya eğitim bloklarını otomatik olarak atama motoruna kısıt olarak yansıtır. Bu entegrasyon olmadığında izinli teknisyene iş atanması, ya manuel kontrol yüküyle ya da müşteri hayal kırıklığıyla sonuçlanır.

**CRM entegrasyonu** ise müşteri geçmişini, açık fırsatları veya önceki servis notlarını teknisyenin iş emrinde görmesini sağlar. Teknisyen sahaya gitmeden müşteriyle ilgili bağlamı biliyorsa, hem konuşma kalitesi hem de çözüm hızı artar.

Entegrasyon değerlendirirken dikkat edilmesi gereken teknik sorular: - Sistem açık API sunuyor mu (REST/webhook)? Kapalı API'ye sahip sistemler, kurumunuzun mevcut araçlarıyla bütünleşemez ve özel geliştirme maliyeti doğurur. - Veri aktarımı gerçek zamanlı mı, yoksa belirli aralıklarla toplu güncelleme (batch sync) üzerinden mi çalışıyor? Toplu güncelleme, çift atama riskini artırır. - Entegrasyon kurulumu kendi başınıza yapılabiliyor mu, yoksa her bağlantı için ayrı bir satıcı mühendisliği süreci mi işliyor?

Entegrasyon derinliği, yazılımın uzun vadeli sahiplik maliyetini (TCO) doğrudan etkiler.

Aşağıdaki matris, değerlendirdiğiniz her yazılım için 1-3 arası puan atamanızı sağlar. 3 = tam karşılanıyor, 2 = kısmen karşılanıyor, 1 = yok veya çok sınırlı.

| Kriter | Ağırlık | Yazılım A | Yazılım B | |--------|---------|-----------|----------| | Otomatik atama + manuel override | %20 | — | — | | Yetkinlik eşleştirme | %20 | — | — | | Öncelik kuralları (yapılandırılabilir) | %15 | — | — | | Kapasite dengesi (seyahat dahil) | %20 | — | — | | Reassign akışı (hız + bildirim + iz) | %15 | — | — | | Entegrasyon (API + takvim + CRM) | %10 | — | — |

Ağırlıklı puan toplamı en yüksek çıkan yazılım, teknik olarak en uygun adaydır. Ancak bu puanı yorumlarken satıcı desteği kalitesi ve fiyatlama modelini de tablonun yanına koyun.

Bir adım daha: Demo sürecinde gerçek bir iş senaryonuzu sisteme girin. Kağıt üzerinde tüm kutuları işaretleyen yazılımlar, kendi müşteri verisiyle çalışırken farklı bir deneyim sunabilir. Demo'da şunları test edin: acil bir iş geldiğinde atama önerisi kaç saniyede geliyor; yeniden atama sırasında müşteri bildirimi otomatik gönderildi mi; takvim entegrasyonu izinli teknisyeni gerçekten dışarıda bıraktı mı?

EkibimJet'in görev atama ve dispatch yetenekleri hakkında daha fazla bilgi almak için EkibimJet Nedir? sayfasını inceleyebilir ya da kendi operasyon senaryonuzu aktarmak için demo talep edebilirsiniz.