Oto Servis Takip Programı Nasıl Seçilir?

Kısa cevap: oto servis yazılımı bir randevu defteri değil, bir araç geçmişi sistemidir. Bir programı değerlendirirken sorulacak ilk soru arayüz değil şudur: kayıt müşteriye mi yoksa araca mı açılıyor, sökümden sonra çıkan ek iş için müşteri onayı sistemin içinde mi alınıyor ve takılan parça iş emrine işlendiği anda stoktan düşüyor mu? Bu üç sorunun cevabı hazır paketlerin çoğunu daha ilk hafta eler.

Kayıt müşteriye değil araca açılır

Servisin asıl varlığı müşteri listesi değil, araç geçmişidir. Bir müşterinin üç aracı varsa bu üç ayrı bakım geçmişi, üç ayrı kilometre çizgisi ve üç ayrı garanti durumu demektir; faturanın tek kişiye kesilmesi bunu değiştirmez. Aynı şekilde araç el değiştirdiğinde geçmiş yeni sahibiyle birlikte devam eder — çünkü "bu araca en son hangi yağ konuldu" sorusu müşteriye değil araca aittir.

Bunun veri modeli sonucu nettir: aracın kimliği plaka değil şasi numarasıdır. Plaka değişir, devredilir, geçici plakaya döner; şasi sabittir. Plakayı birincil anahtar yapan bir program, araç satıldığında ya geçmişi kaybeder ya da iki farklı aracı aynı kayıtta birleştirir. Bu esneklik sonradan eklenemez, veri modeli baştan böyle kurulur.

Servis geçmişi aracın kendisine bağlı değilse, "bu fren balatası ne zaman değişti" sorusunun cevabı sistemde değil ustanın hafızasındadır. Usta ayrıldığında o cevap da gider.

Saha servisi ile atölye aynı yazılım değildir

Beyaz eşya ya da makine tarafındaki teknik servis takip programı bir takvim ve rota problemi çözer: teknisyen adrese gider, yol süresi planlanır, araç stoğu bir ambar gibi yönetilir. Oto serviste iş tersidir; müşteri size gelir. Buradaki kısıt yol değil, lift ve usta sayısıdır: aynı anda kaç araç kaldırılabiliyor ve hangi işi hangi usta yapabiliyor. Randevuyu bu iki kısıta göre vermeyen program ilk hafta yalanlanır, çünkü sabah dokuzda beş araç birden kabul edilmiş olur.

Genel amaçlı bir online randevu sistemi de aynı sebeple yetmez: periyodik bakım kırk dakika sürer, kaporta işi üç gün. İkisi aynı takvimde aynı biçimde durmaz.

En kritik modül iş emri değil, onay akışıdır

Oto serviste işin kapsamı aracın içine bakılmadan tam olarak bilinemez. Söküm başladıktan sonra çıkan ek arıza, ek parça ve ek işçilik demektir; ve onaysız yapılan ek iş çoğu zaman tahsil edilemeyen iş demektir. Bu yüzden programın en kritik parçası iş emri ekranı değil, iş emrini büyüten onay akışıdır.

• Açılan iş emri kalem kalem olmalı: her kalemde parça, işçilik süresi ve tutar ayrı görünmeli.
• Ek iş, mevcut iş emrine yeni kalem olarak eklenebilmeli — ikinci bir iş emri açmak geçmişi ikiye böler.
• Onay sistemin içinden istenmeli ve zaman damgalı kaydedilmeli: müşteriye gönderilen bağlantı, onaylandığı saat ve onaylanan tutar. Telefonda alınan sözlü onay, tartışma çıktığında kanıt değildir.
• Onay bekleyen iş emirleri ayrı bir listede birikmeli; "müşteri dönmedi diye lifti kapatan araç" servisin en pahalı kaybıdır.
• Reddedilen kalem de kayıtta kalmalı — bir sonraki gelişte "bunu geçen sefer önermiştik" demek için.

Onay bildirimini SMS yerine WhatsApp üzerinden göndermek dönüş hızını belirgin biçimde artırır; bunun altyapısını WhatsApp Business API entegrasyonu yazısında anlattık. Kanal ne olursa olsun kural aynı: onay, sistemin dışında verilmişse sistemde yoktur.

Parça, stok ve garanti tek kayıttan beslenir

Takılan parça iş emrine işlendiği anda stoktan düşmelidir. Bu bağ kurulmazsa depo kaydı birkaç hafta içinde gerçeklikten kopar ve "var sanılan" parça yüzünden araç liftte bekler. Ambar tarafının genel mantığı için stok takip programı mı özel yazılım mı yazısına bakabilirsiniz; oto servise özgü olan kısım ise şudur: parça kaydı yalnızca adet değil, marka/muadil bilgisi, parça numarası ve garanti süresi taşımalıdır.

Garanti takibi bu yüzden stoğun değil iş emrinin işidir: parçanın garantisi takıldığı tarihten ve o günkü kilometreden başlar. İkisinden biri kayıtta yoksa altı ay sonra gelen "bu parça garantili değil miydi" sorusuna cevap verilemez.

Periyodik bakım hatırlatması bir özellik değil, gelir kalemidir

Servise geri dönüşü en çok artıran modül hatırlatmadır ve mantığı basit bir kuraldır: bir sonraki bakım, tarih ve kilometreden hangisi önce gelirse o zaman gerekir. Bu hesap iş emri kapandığı anda yapılmalı, sonradan raporla üretilmeye çalışılmamalıdır. Kilometre tahmini için son iki ziyaret arasındaki günlük ortalama kullanılır:

type Ziyaret = { tarih: Date; km: number };

/** Bir sonraki bakım: tarih ve km eşiğinden hangisi önce doluyorsa o. */
export function sonrakiBakim(
  gecmis: Ziyaret[],
  aralikAy: number,
  aralikKm: number,
): { beklenenTarih: Date; sebep: 'tarih' | 'kilometre' } {
  const son = gecmis[gecmis.length - 1];

  const tarihEsigi = new Date(son.tarih);
  tarihEsigi.setMonth(tarihEsigi.getMonth() + aralikAy);

  // Günlük ortalama yalnızca iki gerçek ölçüm varsa hesaplanır;
  // tek ziyaret varsa km tahmini yapılmaz, karar tarihe bırakılır.
  const onceki = gecmis[gecmis.length - 2];
  if (!onceki) return { beklenenTarih: tarihEsigi, sebep: 'tarih' };

  const gun = (son.tarih.getTime() - onceki.tarih.getTime()) / 86400000;
  const gunlukKm = gun > 0 ? (son.km - onceki.km) / gun : 0;
  if (gunlukKm <= 0) return { beklenenTarih: tarihEsigi, sebep: 'tarih' };

  const kmEsigi = new Date(
    son.tarih.getTime() + (aralikKm / gunlukKm) * 86400000,
  );

  return kmEsigi < tarihEsigi
    ? { beklenenTarih: kmEsigi, sebep: 'kilometre' }
    : { beklenenTarih: tarihEsigi, sebep: 'tarih' };
}

Buradaki kritik ayrıntı, tek ziyaretlik araçta kilometre tahmini yapılmamasıdır. Yanlış tahmin, müşteriye erken hatırlatma göndermekten daha kötüsünü yapar: bir daha okunmayan bir bildirim kanalı üretir.

Hazır paket mi, özel yazılım mı?

Tek şubeli, standart bakım-onarım yapan bir servis için hazır paket çoğu zaman doğru karardır. Karar üç testle verilir; en az ikisine "evet" diyorsanız özel yazılım tarafına bakmanız gerekir:

• Birden fazla şube var ve araç geçmişi, parça stoğu ya da müşteri bakiyesi şubeler arasında ortak kullanılıyor mu?
• Sigorta eksper süreci, filo müşterisi sözleşmesi ya da anlaşmalı kurum iskontosu gibi standart dışı bir akış var mı? Filo tarafında fatura genellikle araç sahibine değil sözleşmeli firmaya kesilir; bunu desteklemeyen paket sizi Excel'e geri gönderir.
• Muhasebe, e-fatura veya yedek parça tedarikçisinin kataloğu gibi başka bir sistemle konuşması gerekiyor mu? Bu bağların nasıl kurulduğu muhasebe programı entegrasyonu yazısında var.

Hangi yolu seçerseniz seçin, teklif alırken sorulacak dördüncü bir soru daha var: veriler dışa aktarılabiliyor mu? Araç geçmişi, iş emirleri ve müşteri kayıtları standart bir formatta alınamıyorsa program değiştirmek yıllar sonra imkânsız hâle gelir.

Projeyi bozan beş hata

• Aracı plakayla kimliklendirmek — plaka değişince geçmiş kopar.
• Ek işi ikinci bir iş emrine yazmak — aynı ziyaret raporlarda iki ziyaret görünür.
• Onayı sistemin dışında (telefonda) almak — tahsilat tartışmasında elde kanıt kalmaz.
• Parça çıkışını iş emrinden ayırmak — depo bir ay içinde gerçeklikten kopar.
• Ustanın kullanacağı ekranı masaüstü için tasarlamak — atölyede eldivenli elle kullanılan tablet arayüzü üç büyük butondan ibaret olmalıdır; kullanılmayan ekran girilmeyen veri demektir.

Sonuç

Oto servis programını seçerken ekran sayısına değil üç şeye bakın: kayıt araca mı açılıyor, onay akışı sistemin içinde mi, parça ile stok tek kayıttan mı besleniyor. Bu üçü varsa periyodik bakım hatırlatması ve raporlama kendiliğinden anlamlı hâle gelir. Servisinizin akışı hazır paketlerin dışına çıkıyorsa bize yazın, mevcut iş akışınızı çıkarıp hangi kısmın hazır çözümle, hangi kısmın özel geliştirmeyle karşılanacağını birlikte netleştirelim.