Teknik Servis Takip Programı Nasıl Kurulur?

Teknik servis takip programı, müşteriden gelen her arıza ve bakım talebini bir servis çağrısına çeviren, o çağrıya bir teknisyen, bir adres ve bir zaman aralığı atayan ve iş bittiğinde yapılan işi belgeleyen yazılımdır. Bir destek talep sisteminden tek bir yapısal farkı vardır ama o fark her şeyi değiştirir: talep bir yanıtla kapanmaz, sahaya giden bir insanla kapanır. Bu yüzden yazılımın asıl ürünü liste değil, plandır — kimin, nereye, hangi saat aralığında ve yanında hangi parçayla gideceği. Kurmanın üç yolu var: hazır bir saha servis programı, mevcut ERP ya da CRM’in servis modülü, ya da kendi süreçlerinize göre özel yazılım. Aşağıda helpdesk’ten ayrıldığı noktayı, çağrının yaşam döngüsünü, randevu penceresi ve yol süresi hesabını, teknisyen atama mantığını, araç stoğunu, offline zorunluluğunu, maliyet kalemlerini ve projeyi bozan beş hatayı bulacaksınız.

Helpdesk’ten nerede ayrılır?

İki sistem uzaktan aynı görünür: ikisinde de numaralanmış bir kayıt, bir sahip, bir öncelik ve bir hedef süre vardır. Ayrım kapanış biçimindedir. Bir destek talebi yazıyla kapanır; servis çağrısı ise ancak biri o adrese gidip işi yaptığında kapanır. Buradan üç şey doğar ve hiçbiri bir helpdesk’te bulunmaz: yol süresi, araçtaki parça stoğu ve internetin olmadığı bir bodrumda çalışabilme zorunluluğu. Talepleriniz masa başında çözülüyorsa yanlış yerdesiniz; kurulumunu destek talep sistemi (helpdesk) yazımızda anlattık. İşin bir kısmı sahada bitiyorsa okumaya devam edin.

Pratik ölçüt şudur: bir talebi kapatmak için birinin bir yere gitmesi gerekiyorsa, sizin ihtiyacınız bir destek sistemi değil bir planlama sistemidir. Helpdesk kuyruğu yönetir, saha servis yazılımı takvimi yönetir.

Servis çağrısının yaşam döngüsü

Yazılım seçmeden önce kendi sürecinizi bu yedi adımda yazmanız gerekir; hazır program da özel geliştirme de bu iskelet üzerine kurulur:

• Kayıt — talep telefon, form, WhatsApp veya bayiden düşer; numara alır. Kritik alan burada müşteri değil cihazdır: seri numarası ya da tesis kimliği alınmazsa geçmiş hiçbir zaman birleşmez.
• Ön eleme — sorun uzaktan çözülebilir mi? Saha ziyaretinin en pahalı olduğu yer burasıdır; telefonda çözülen her çağrı bir yol parası ve bir teknisyen saatidir.
• Planlama — teknisyen, tarih ve zaman aralığı atanır, müşteriye bildirilir. Randevu penceresi olmadan verilen söz “bugün geleceğiz”dir ve şikâyetlerin çoğu buradan çıkar.
• Yolda — teknisyen yola çıktığında müşteriye haber gider. Küçük bir özellik ama gelen “nerede kaldınız” çağrılarını belirgin biçimde azaltır.
• Sahada — yapılan iş, harcanan süre, takılan yedek parça ve varsa fotoğraf kaydedilir. Parça tüketimi burada düşülmezse depo kaydı bir hafta içinde gerçeklikten kopar.
• Kapanış — servis formu müşteriye imzalatılır (ıslak imza ya da ekranda), garanti kapsamı işaretlenir. Ücretli mi, garanti mi, sözleşme kapsamında mı — bu tek alan faturalamanın tamamını belirler.
• Takip — çözülemeyen iş için ikinci ziyaret aynı kayıt üzerinden planlanır, yeni numara üretilmez. İlk ziyarette çözüm oranını ölçmenizi sağlayan tek kural budur.

Randevu penceresi ve yol süresi

Saha servisinde planlamanın işi işleri sıraya dizmek değil, iki kısıtı aynı anda tutmaktır: müşterinin evde ya da iş yerinde olduğu saat aralığı ve teknisyenin bir noktadan diğerine gitme süresi. Yol süresini hesaba katmayan bir plan kâğıt üzerinde tıka basa doludur, sahada ise günde iki iş kaçırır.

• Pencere gerçekçi olsun. İki saatlik pencere müşteriyi memnun eder ama trafikte tutulamaz; şehir içinde üç-dört saatlik pencere hem tutulabilir hem kabul edilebilir.
• İş süresi çağrı tipine göre değişir. Periyodik bakım ile arıza aynı süreyi tutmaz; her çağrı tipine bir standart süre yazın, sonra gerçek verilerle düzeltin.
• Bölge bazlı planlayın. Aynı teknisyene aynı gün şehrin iki ucundan iş verilmesi, plandaki en pahalı hatadır.
• Acil işler için gün içinde boşluk bırakın. Yüzde yüz doldurulmuş bir takvim, ilk acil çağrıda komple dağılır; günün yüzde 15-20’sini rezerve tutmak pratikte daha çok iş bitirir.

Müşterinin randevuyu kendisinin seçmesini istiyorsanız bu ayrı bir arayüz işidir; randevu tarafının nasıl kurulduğunu online randevu sistemi yaptırma yazımızda ayrıntılandırdık.

Teknisyen atama: yetkinlik, müsaitlik, mesafe

Atama üç kısıtın kesişimidir ve sırası önemlidir: yetkinlik bir eleme kriteridir (yoksa gitmesin), müsaitlik bir eleme kriteridir (yoksa gidemez), mesafe ise bir sıralama kriteridir. Aşağıdaki fonksiyon bu üçünü bu sırayla uygular ve yanında parçası olan teknisyeni öne alır:

interface ServiceCall {
  requiredSkill: string;
  lat: number;
  lng: number;
  windowStart: string; // 'HH:MM' — müşterinin uygun olduğu aralık
  windowEnd: string;
  estimatedMinutes: number;
  requiredParts: string[];
}

interface Technician {
  id: string;
  skills: string[];
  vanStock: Record<string, number>; // araçtaki yedek parça
  busy: { start: string; end: string }[]; // o güne ait dolu aralıklar
  lastLat: number; // en son işin bitiş konumu
  lastLng: number;
}

const toMinutes = (hhmm: string): number => {
  const [h, m] = hhmm.split(':').map(Number);
  return h * 60 + m;
};

/** Kaba yol süresi. Gerçek projede harita servisinin matris API'si kullanılır. */
function travelMinutes(tech: Technician, call: ServiceCall): number {
  const dLat = (call.lat - tech.lastLat) * 111;
  const dLng =
    (call.lng - tech.lastLng) * 111 * Math.cos((tech.lastLat * Math.PI) / 180);
  const km = Math.sqrt(dLat * dLat + dLng * dLng);
  return Math.round((km / 25) * 60); // şehir içi ortalama 25 km/sa
}

/** Pencere içinde, yol süresi dâhil, işin sığdığı bir başlangıç saati var mı? */
function findSlot(tech: Technician, call: ServiceCall): number | null {
  const travel = travelMinutes(tech, call);
  let cursor = toMinutes(call.windowStart) + travel;
  const deadline = toMinutes(call.windowEnd);
  const blocks = [...tech.busy].sort(
    (a, b) => toMinutes(a.start) - toMinutes(b.start),
  );

  for (const block of blocks) {
    const blockStart = toMinutes(block.start);
    if (cursor + call.estimatedMinutes <= blockStart) break; // boşluğa sığdı
    cursor = Math.max(cursor, toMinutes(block.end) + travel);
  }
  return cursor + call.estimatedMinutes <= deadline ? cursor : null;
}

export function rankTechnicians(
  call: ServiceCall,
  technicians: Technician[],
): { techId: string; startsAt: number; travel: number; hasParts: boolean }[] {
  return technicians
    .filter((t) => t.skills.includes(call.requiredSkill)) // 1) eleme: yetkinlik
    .map((t) => ({ t, slot: findSlot(t, call) }))
    .filter((c): c is { t: Technician; slot: number } => c.slot !== null) // 2) eleme: müsaitlik
    .map(({ t, slot }) => ({
      techId: t.id,
      startsAt: slot,
      travel: travelMinutes(t, call),
      hasParts: call.requiredParts.every((p) => (t.vanStock[p] ?? 0) > 0),
    }))
    // 3) sıralama: parçası olan önce, sonra en kısa yol
    .sort(
      (a, b) =>
        Number(b.hasParts) - Number(a.hasParts) || a.travel - b.travel,
    );
}

Fonksiyonun döndürdüğü liste bir karar değil, bir öneridir — ve öyle kalması gerekir. Saha servisinde planlamayı tamamen otomatiğe bağlayan sistemler, planlamacının bildiği ama sistemin bilmediği şeyler yüzünden (müşteriyle geçmiş bir gerginlik, teknisyenin o sitede kartı olması, aracın o gün serviste olması) itiraz görür ve kullanılmayı bırakır. Doğru kurgu şudur: sistem sıralar, insan onaylar.

Araç stoğu ve yedek parça

Saha servisinin depo tarafında kendine özgü bir problemi var: stok tek bir yerde durmuyor. Ana depo dışında her aracın kendi stoğu var ve bu stok her akşam değişiyor. Bunu yönetmenin dört kuralı vardır:

• Her araç bir ambar sayılır. Parça ana depodan çıktığında kaybolmaz, teknisyenin ambarına transfer olur. Bu tanım yoksa envanterle sayım hiçbir zaman uyuşmaz.
• Tüketim serviste düşülür. Teknisyen formu kapatırken taktığı parçayı işaretler; sistem o parçayı aracın stoğundan düşer ve faturalanacak kaleme ekler.
• Kritik parçalar için minimum seviye tanımlanır. Araç stoğu eşiğin altına düştüğünde otomatik tamamlama talebi açılır; teknisyenin bunu hatırlamasını beklemeyin.
• Arızalı parça geri dönüşü takip edilir. Garanti kapsamında değişen parçanın üreticiye iadesi ayrı bir akıştır ve unutulduğunda doğrudan zarardır.

Ana depo ve satın alma tarafını zaten bir sistemle yönetiyorsanız iki yazılımın çakışmaması gerekir; stok tarafının nerede yetmeye başladığını stok takip programı mı özel yazılım mı, üretim bağlantısını ise üretim takip programı (MRP) yazımızda anlattık.

Sahadaki uygulama offline çalışmak zorunda

Bu, saha servis projelerinde en çok küçümsenen ve en pahalıya patlayan gereksinimdir. Teknisyenin gittiği yer bir bodrum, bir asansör kuyusu, bir fabrika sahası ya da şehir dışında bir tesis olabilir. Bağlantı yoksa uygulamanın çalışmaya devam etmesi ve bağlantı gelince kaydı göndermesi gerekir. Pratikte üç şey gerekir: günün işleri sabah cihaza indirilir, form ve fotoğraflar cihazda tutulur, bağlantı gelince arka planda senkronize olur. Uygulamanın geri kalanı için de tek bir tasarım kuralı vardır — eldiven, güneş ve tek elle kullanım: büyük butonlar, az alan, çok az yazı.

Teknisyen mesai ve yol takibini de aynı uygulamadan yapmak isterseniz bunun ayrı bir sistemle çakışmaması gerekir; sınırları personel takip programı (PDKS) yazımızda çizdik.

Garanti, sözleşme ve faturalama

Servis yazılımının para tarafı tek bir soruya iner: bu ziyaret ücretli mi? Cevabı üç kaynaktan gelir ve üçünün de sistemde tanımlı olması gerekir:

• Cihaz garantisi — seri numarasına bağlı başlangıç ve bitiş tarihi. Teknisyenin sahada kafadan karar vermesi, en sık görülen gelir kaybı sebebidir.
• Bakım sözleşmesi — yıllık sözleşmede kaç periyodik bakım, kaç arıza ziyareti dâhil; kapsam dışı ne var. Sözleşme kotasını sistem saymazsa kimse saymaz.
• Ücretli servis — işçilik, yol ve parça ayrı kalemler. Yol ücretinin mesafeye göre mi sabit mi olduğunu baştan yazın; sahada tartışılan en yaygın kalem budur.

Kapanan formun faturaya dönmesi bir entegrasyon işidir; muhasebe tarafını muhasebe programı entegrasyonu, e-belge tarafını e-fatura entegrasyonu yazımızda ele aldık.

Hazır program, ERP modülü, özel yazılım

Üç yol var ve seçim, işinizin ne kadar standart olduğuna bağlı:

• Hazır saha servis programı — hızlı başlar, mobil uygulamasıyla gelir, aylık abonelikle ilerler. Cihaz kurulumu ve arıza onarımı yapan çoğu servis için doğru seçim. Sınırı: kendi form yapınız ve garanti kurallarınız programın veri modeline sığmıyorsa süreci yazılıma göre değiştirmek zorunda kalırsınız.
• ERP veya CRM’in servis modülü — müşteri, stok ve faturalama zaten aynı yerde olduğu için entegrasyon derdi en az olan yol. Mevcut sisteminiz varsa ilk bakılacak yer burasıdır; zayıf tarafı genellikle mobil uygulamadır.
• Özel yazılım — cihaz bazlı karmaşık garanti kuralları, müşteriye özel servis seviyeleri, mevzuat gerektiren muayene formları ya da bayi ağı üzerinden çalışan bir servis modeli varsa tek gerçekçi yol. Karar kriterlerini özel yazılım mı hazır çözüm mü yazımızda karşılaştırdık.

Maliyet kalemleri

Teklifleri tek bir rakamla karşılaştırmak yanıltır; bütçe bu projelerde dört kaleme dağılır:

• Yazılım — hazır programda teknisyen başına aylık abonelik, özel yazılımda adam-gün üzerinden geliştirme. Özel geliştirmede fiyatın nasıl kurulduğunu özel yazılım maliyeti yazımızda açtık.
• Mobil taraf — saha uygulaması projenin en az yarısıdır. Web tarafına odaklanıp mobili “sonra” bırakan projelerin çoğu ikinci fazda durur; teknisyen kullanmazsa sistem yoktur.
• Cihaz ve saha donanımı — tablet ya da dayanıklı telefon, gerekiyorsa mobil yazıcı ve barkod okuyucu, hat ve veri paketi.
• Veri hazırlığı ve eğitim — müşteri, cihaz ve garanti verisinin sisteme girilmesi ile teknisyen eğitimi. Cihaz envanteri dağınıksa bu kalem yazılımdan büyük çıkar.

Projeyi bozan beş hata

• Cihaz kaydı tutulmuyor, yalnızca müşteri kaydı var. Aynı adreste üç cihaz varsa hangisinin kaç kez arıza verdiği bilinemez; bu veri olmadan ne garanti ne de kalite ölçülebilir.
• Randevu penceresi verilmiyor. “Bugün geleceğiz” demek, gelmemekle aynı memnuniyetsizliği üretir ve santralinizi meşgul eder.
• Yol süresi plana girmiyor. Kâğıt üzerinde dolu görünen takvim sahada günde iki iş kaçırır; en somut verim kaybı buradadır.
• Mobil uygulama masabaşı için tasarlanıyor. Uzun formlar ve zorunlu on alan, teknisyeni akşam toptan ve uydurma doldurmaya iter. Veri kalitesini bu tek karar belirler.
• Aynı anda her şey açılıyor. Çağrı yönetimi, planlama, araç stoğu, sözleşme takibi ve faturalama aynı ay devreye alındığında ekip hiçbirine güvenmez. Sıra nettir: önce çağrı ve planlama, sonra parça, en son faturalama.

Sonuç

Teknik servis takip programı servisi hızlandırmaz; kimin nereye ne zaman gittiğini ve orada ne yaptığını görünür kılar, hızlanmayı siz yaparsınız. Bu yüzden başarı ürünün markasıyla değil üç şeyle ilgilidir: cihaz bazlı kayıt, yol süresini hesaba katan gerçekçi bir planlama ve teknisyenin gerçekten kullandığı bir mobil uygulama. Servisiniz standart kurulum ve onarımdan oluşuyorsa hazır bir programla ya da mevcut sisteminizin modülüyle başlayın; bayi ağıyla çalışıyor, cihaz bazlı karmaşık garanti kuralları taşıyor ya da mevzuat gereği muayene formu üretiyorsanız kurumsal çözümler hizmetimize bakın veya teknisyen sayınızı ve günlük çağrı adedinizi yazıp teklif alın.