Odoo Saha Servisi: İş Emrinden Faturaya Tek Akış

Teknisyen işi bitirdi. Kullanılan parça stoktan düştü mü, servis formu tamamlandı mı, ücret faturaya yansıdı mı? Saha servisinde takibin koptuğu yer çoğu zaman tam burasıdır. Telefon görüşmelerinde, mesajlarda ve kâğıt formlarda kalan bilgiyi aynı iş kaydında toplamak; servis yöneticisinin, teknisyenin, deponun ve muhasebenin birlikte çalışmasını sağlar.

Bu rehberde Odoo saha servisi yönetimini, müşteri talebinden işin tamamlanmasına ve faturalamaya uzanan bir operasyon olarak ele alıyoruz. Bir servis yöneticisinin takip etmek istediği sonuçları ve bu sonuçları üretecek teknik yapıyı birlikte açıklıyoruz.

Odoo ile saha servisi yönetimi nedir?

Saha servisi yönetimi, müşterinin bulunduğu yerde gerçekleştirilen kurulum, devreye alma, arıza giderme ve bakım işlerinin planlanması, yürütülmesi ve kayıt altına alınmasıdır. Hangi müşteriye gidileceği kadar, hangi cihaz üzerinde ne yapılacağı, kimin sorumlu olduğu, hangi parçanın gerektiği ve hizmetin nasıl ücretlendirileceği de bu sürecin parçasıdır.

Odoo’da bu akış farklı uygulamaların aynı müşteri ve ticari kayıtlar etrafında çalışmasıyla kurulabilir. Field Service sahadaki görevi, Helpdesk müşteri talebini, Sales ticari koşulları, Inventory malzeme hareketini ve Timesheets harcanan zamanı takip etmekte kullanılır. Uygulama seti, kullandığınız Odoo sürümüne ve servis modelinize göre seçilir.

Makine üreticileri, teknik servis şirketleri, iklimlendirme ve endüstriyel ekipman firmaları, yerinde kurulum yapan teknoloji ekipleri ve birden fazla lokasyona bakım veren işletmeler için bu bağlantı özellikle değerlidir.

Bir fırsattan veya servis talebinden iş emrine

Hikâye bazen CRM’de bir fırsatla başlar: müşteri yeni bir cihaz, kurulum veya bakım hizmeti ister. Bazen de daha önce teslim edilmiş bir ürün için arıza bildirir. Bu iki başlangıcın ticari anlamı farklıdır; sistemde de kaynağı belli olmalıdır.

Yeni satış, kurulum ve devreye alma

CRM fırsatı → teklif → satış siparişi → saha görevi zincirinde, sahaya çıkılacak iş onaylanan hizmete bağlanır. Odoo’nun standart Field Service akışında, hizmet ürününün sipariş onayında görev oluşturacak şekilde yapılandırılmasıyla saha görevi üretilebilir. Böylece görevin hangi satıştan doğduğu izlenebilir. Ayrıntılar: Odoo görev oluşturma dokümanı.

Arıza ve satış sonrası destek

Mevcut müşterinin talebi Helpdesk üzerinden alınabilir; yerinde müdahale gerektiğinde bu ticket ile bağlantılı Field Service görevi açılabilir. Bir talebin iki ziyaret gerektirmesi veya önce uzaktan teşhis yapılması gibi durumlarda, talep ile ziyaret kayıtlarını ilişkilendirmek geçmişi takip etmeyi kolaylaştırır. Bu bağlantı Odoo satış sonrası hizmetler akışında da yer alır.

İş emrine en azından müşteri, servis adresi, cihaz veya ekipman, arıza açıklaması, öncelik ve iletişim kişisi bağlanmalıdır. Aynı müşterinin farklı fabrikaları varsa, fatura adresi ile servis adresinin ayrı tutulması yanlış lokasyona yönlendirmeyi önler. Cihaz seri numarası, garanti bilgisi ve önceki müdahalelerin ilişkilendirilmesi ise ekipman geçmişini anlamlı hale getirir; bu veri modeli proje kapsamında tasarlanır.

Teknisyen planlama, rota ve SLA

Bir takvimde boş saat görmek, o teknisyenin işe uygun olduğunu göstermez. Planlama sırasında uzmanlık, bölge, tahmini iş süresi, müşteri randevusu, yol süresi ve parça bulunabilirliği birlikte değerlendirilmelidir. Örneğin parçası henüz teslim alınmamış bir işe ekip göndermek yerine, işi “parça bekliyor” durumunda görünür tutmak daha doğru bir operasyon kararıdır.

Odoo Field Service, müşteri adreslerini haritada gösterebilir. Rota gösterimi için Mapbox yapılandırması kullanılır; görevler planlanan tarihe göre sıralanır ve güzergâh Google Maps’te açılabilir. Bu işlev, bütün ekipler için süre ve kapasite kısıtlarıyla otomatik rota optimizasyonu veya sürekli GPS takibi yapıldığı anlamına gelmez. Böyle bir ihtiyaç varsa ayrıca tasarlanır. Kaynak: Odoo rota planlama dokümanı.

Hangi süreyi ölçüyoruz?

SLA (Service Level Agreement) kurgusunda ilk yanıt, sahaya varış ve çözüm süreleri ayrı hedefler olabilir. “Talebe dört saatte cevap verildi” ile “arıza dört saatte giderildi” aynı sonuç değildir. Mesai takvimi, aciliyet ve müşteri onayı beklenen süre gibi kurallar başlangıçta belirlenmelidir.

Odoo Helpdesk SLA politikaları, tanımlanan koşullara uyan ticket’ın hedef aşamaya ulaşma süresini takip eder; çalışma saatleri ve hesaplamadan hariç tutulan aşamalar yapılandırılabilir. Saha görevinin durumu ile ticket aşaması arasında otomasyon isteniyorsa bu bağlantı ayrıca kurulmalı ve test edilmelidir. Kaynak: Odoo Helpdesk SLA dokümanı.

Sahada çalışma: servis formu, süre ve müşteri onayı

Teknisyenin sahada uzun metinler yazmasını beklemek yerine, yapılan işe uygun kısa bir kayıt akışı tasarlamak gerekir. Arıza müdahalesi ile periyodik bakımın formu aynı olmak zorunda değildir. Birinde arıza nedeni ve değiştirilen parça, diğerinde kontrol noktaları ve ölçüm değerleri öne çıkar.

Odoo’nun Worksheets yapısıyla görev için kontrol listeleri, giriş alanları, talimatlar ve görseller içeren şablonlar hazırlanabilir. Standart Worksheet şablonları Studio ile tasarlanır; bu özelliğin açılması Studio kurulumu ve kullanılan abonelik planı açısından değerlendirilmelidir. Zorunlu alanları doğru seçmek de önemlidir: formun kaydedilmiş olması, her kontrolün tamamlandığını tek başına kanıtlamaz. Kaynak: Odoo Worksheets dokümanı.

• İşe başlarken: cihaz ve seri numarası doğrulaması, müşteri şikâyeti, mevcut durum ve gerekli hazırlıklar.
• Müdahale sırasında: yapılan işlem, kullanılan parça, ölçüm sonucu, gerekli fotoğraf ve teknik not.
• İşi kapatırken: test sonucu, açık kalan iş, takip ziyareti ihtiyacı ve müşteri teslim kaydı.

Timesheets kayıtlarında yol, teşhis, müdahale ve bekleme sürelerinin nasıl ayrılacağı belirlenmelidir. Harcanan her süre müşteriye fatura edilecek süre olmayabilir. Servis formundaki müşteri onayı ile şirket içi teknik veya ticari onay da ayrı adımlar olarak ele alınmalıdır.

Mobil kullanımda tasarımı gerçek saha koşullarında denemek gerekir: küçük ekran, fotoğraf yükleme ve kesintili bağlantı. İnternet olmadan kayıt tutma ve sonradan senkronizasyon gerekiyorsa bunun kullanılan uygulamada nasıl çalışacağı ayrıca doğrulanmalıdır; mobil erişim tek başına offline çalışma garantisi değildir.

Yedek parça ve araç stoğu: kayıt fiili hareketi izlemeli

Teknisyene üç parça teslim edilip sahada yalnızca ikisi kullanıldıysa, üçüncü parça kaybolmuş gibi görünmemelidir. Benzer şekilde arızalı çıkan parçanın iadesi, yeni parçanın tüketimiyle aynı hareket değildir. Servis yazılımının depo sürecine bağlandığı nokta budur.

Odoo Field Service’in ürün kataloğu ve varsayılan depo yapısı, görevde kullanılan ürünlerin ilgili ticari ve stok akışına bağlanmasını destekler. Kullanıcı için varsayılan depo tanımlanabilir. Standart yapıdaki hareketlerin sizin depo veya araç stoğu modelinizle nasıl eşleştiği kurulumda kontrol edilir. Kaynak: Odoo Field Service ürün ve depo yönetimi.

Teknik tasarımda özellikle şu ayrımlar açık olmalıdır:

• Talep ve rezervasyon: gerekli parça ile kullanılabilir stok ayrı bilgilerdir; talep açılması parçanın hazır olduğu anlamına gelmez.
• Teslim ve tüketim: ana depodan teknisyene aktarılan malzeme ile müşteride kullanılan malzeme ayrı hareketler olarak izlenebilir.
• Seri numarası: hangi parçanın hangi cihazda kullanıldığı, stok takibi ve servis kaydı arasında ilişkilendirilmelidir.
• İade: kullanılmayan sağlam parça, arızalı parça ve garanti incelemesine gidecek parça için farklı süreçler gerekebilir.

Bu ayrımlar için gereken onaylar ve hareket kuralları projeye göre yapılandırılır veya geliştirilir. Kullanılan parça miktarını yalnızca servis formunda metin olarak tutmak, Inventory’de gerçek bir stok hareketi üretmez.

İşçilik, sözleşme ve faturalama nasıl bağlanır?

Servis tamamlandığında muhasebenin “ne yapılmıştı?” diye teknisyeni aramaması gerekir. İşçilik, parça ve diğer bedellerin hangi ticari koşula göre değerlendirileceği iş kaydına bağlı olmalıdır. Sabit bedelli kurulum, saat üzerinden ücretlendirilen müdahale ve bakım sözleşmesi kapsamındaki ziyaret farklı faturalama modelleridir.

Odoo’da Sales, Timesheets ve faturalama uygulamaları üzerinden zaman bazlı hizmetlerin ticari takibi kurulabilir. Helpdesk tarafında önceden satın alınan hizmet saatlerinin veya verilen hizmet sonrasında kaydedilen sürenin faturalama akışı da tanımlanabilir. Kaynak: Odoo zaman takibi ve faturalama dokümanı.

Proje tasarımında şu kararlar netleştirilmelidir: yol ücreti alınıyor mu, mesai dışı hizmetin bedeli farklı mı, hangi parçalar garanti kapsamında, sözleşme limitini aşan süre için onay gerekiyor mu? İndirim ve kapsam dışı işlem onayları da buna göre kurulur.

“Servis tamamlandı” ve “fatura onaylandı” ayrı durumlardır. İşin bitmesiyle faturalamaya uygun kayıt oluşabilir; müşteriye fatura gönderimi, şirketin kontrol ve onay sürecine göre yürütülmelidir. Ödeme ve kalan bakiye takibi de muhasebe kayıtlarına dayanır. Türkiye’deki e-belge bağlantısını ayrıca Odoo e-Fatura entegrasyonu rehberimizde açıklıyoruz.

Örnek akış: bir endüstriyel cihazın servis yolculuğu

Aşağıdaki senaryo, sürecin nasıl tasarlanabileceğini gösteren örnek bir uygulama akışıdır. Tek bir müşteri projesinin sonuçlarını veya her kurulumda hazır gelen özellikleri temsil etmez.

1. Fırsat ve satış: CRM’de başlayan görüşme, cihaz ve kurulum hizmetini içeren bir siparişe dönüşür. Kurulum görevi satış kaydıyla ilişkilendirilir.
2. Devreye alma: ekip randevuya gider; cihazın seri numarası, kurulum bilgileri ve test sonuçları kayıt altına alınır.
3. Bakım planı: sözleşmede tanımlanan periyotlara göre ziyaretlerin nasıl üretileceği ve atanacağı yapılandırılır. Takvimde oluşan bir görevin parça ve ekip ihtiyacı ayrıca kontrol edilir.
4. Arıza bildirimi: müşteri aynı cihaz için ticket açar. Servis geçmişi incelenir; uzaktan çözüm mümkün değilse yerinde müdahale planlanır.
5. Parça ve müdahale: gerekli malzeme hazırlanır, teslim ve kullanım kaydedilir. Teknisyen yaptığı işlemi ve harcadığı süreyi görevle ilişkilendirir.
6. Teknik kapanış: son test yapılır, servis formu tamamlanır; takip ziyareti gerekiyorsa açıkça belirtilir.
7. Ticari kapanış: sözleşme veya garanti kapsamı kontrol edilir. Ücretlendirilecek kalemler onaylanarak faturaya, ödeme gerçekleştiğinde tahsilat kaydına bağlanır.

Bu akışın değeri, ekipler arası bilgi kaybını azaltmasıdır. Bir sonraki ziyarette teknisyen önceki müdahaleyi görebilir; depo kullanılan parçayı, yönetim ise tamamlanmasına rağmen ticari kapanışı bekleyen işleri izleyebilir.

Vekosis saha servisi modülü ve teknik uyarlama

Vekosis olarak müşterilerimizin ihtiyaçları için açık kaynak saha servisi modülleri geliştiriyoruz. Servis işleyişini Odoo üzerinde ele alırken mevcut uygulamalarla karşılanan adımları ve özel geliştirme gerektiren ihtiyaçları birlikte belirliyoruz. Sözleşme, hakediş ve tahsilat takibi gibi diğer geliştirmelerimizle kurulacak bağlantılar da projenin akışına göre değerlendirilir.

Örneğin depo onaylı parça teslimi, birden fazla teknisyenin aynı işte çalışması, ekipmana özel servis formları, bayi veya alt yüklenici erişimi ve dış ERP ile veri alışverişi analizde ele alınabilecek başlıklardır. Hangi işlevin hangi sürümde kullanılacağı, proje kapsamı ve testleriyle netleştirilir.

BT ekibi açısından dikkat edilmesi gereken yapı

• Veri ilişkileri: müşteri, lokasyon, cihaz, ticket, saha görevi, satış satırı, stok hareketi ve fatura arasında izlenebilir bağlantılar kurulmalıdır. Aynı bilgiyi ayrı metin alanlarına tekrar yazmak yerine ilgili kayıtlar ilişkilendirilir.
• Yetkilendirme: teknisyen, servis yöneticisi, depo, muhasebe ve portal kullanıcısı için ayrı erişim kapsamı tanımlanır. Record Rules ile kayıt erişimi; kullanıcı grupları ve gerektiğinde alan yetkileriyle işlem ve bilgi erişimi kontrol edilir.
• Entegrasyon: dış sistemden gelen kayıtlar benzersiz bir referansla eşleştirilmelidir. Aynı isteğin tekrar gönderilmesi ikinci bir iş emri veya stok hareketi oluşturmamalıdır; bu davranış idempotency testleriyle doğrulanır.
• Durum geçişleri: eksik servis formuyla kapanış, yetersiz stokla tüketim veya onaysız ticari işlem gibi durumların hangi koşullarda engelleneceği tanımlanır.
• Sürüm ve barındırma: Python kodu içeren özel modüller için Odoo Online yerine bu geliştirmeyi destekleyen bir ortam seçilir. Odoo.sh veya yönetilen sunucu seçenekleri, kullanılan sürüm ve modül bağımlılıklarıyla birlikte değerlendirilir.

Odoo Online’ın özel modül sınırları resmi barındırma dokümanında açıklanır. Alternatifleri Odoo barındırma rehberimizde, genel uygulama kapsamlarını ise Odoo modülleri rehberimizde bulabilirsiniz.

Servis yöneticisi hangi göstergeleri takip etmeli?

Yalnızca kapanan görev sayısına bakmak, operasyonun bütününü göstermez. Aynı iş için tekrar gidiliyorsa, parçalar uzun süre bekleniyorsa veya tamamlanan servisler faturalanmıyorsa bu durumlar ayrı görünmelidir. Aşağıdaki göstergeler, rapor tasarımı için kullanılabilecek bir çerçevedir.

Bu göstergelerin tamamının tek bir standart raporda hazır bulunması beklenmemelidir. Raporlar seçilen modüller ve kaydedilen verilere göre oluşturulur. Örneğin First-Time Fix Rate için aynı arızaya ait tekrar ziyaretin nasıl ilişkilendirileceği belirlenmeden güvenilir bir oran üretilemez.

Canlıya geçmeden hangi senaryoları test etmeliyiz?

Başlangıçta bir servis türü, sınırlı bir ekip ve örnek cihazlarla pilot çalışma yapılabilir. Amaç yalnızca görev açmak değil, işi başladığı kayıttan ticari kapanışına kadar takip edebilmektir. Bu sırada müşteri ve cihaz verileri, depo hareketleri ve kullanıcı yetkileri birlikte sınanır.

• Siparişten veya Helpdesk ticket’ından doğru müşteri ve adresle görev oluşuyor mu?
• Parça eksikliği veya müşteri ertelemesi, planlamada ve SLA hesabında tanımlanan kurala uygun görünüyor mu?
• Teknisyene verilen, kullanılan ve iade edilen miktarlar depo kayıtlarıyla tutuyor mu?
• Garanti kapsamındaki işlem ile ücretli işlem farklı ticari sonuç üretiyor mu?
• İş tamamlanınca süre, parça, servis formu ve fatura satırlarının bağlantısı korunuyor mu?
• Bir müşteri portal kullanıcısı başka müşterinin görevine veya ekine erişebiliyor mu?
• Tekrar gelen entegrasyon isteği veya bağlantı kesintisi mükerrer kayıt oluşturuyor mu?

Odoo saha servisi projesinin başarısı, sahadaki ekibin doğru kaydı kolayca oluşturmasına ve diğer ekiplerin bu kaydı kullanabilmesine bağlıdır. Bu nedenle ekranlar, işlem kuralları ve eğitim aynı servis senaryosu etrafında hazırlanmalıdır.

Sık sorulan sorular

Kaynaklar ve kapsam

Standart ürün açıklamaları Odoo 19.0 dokümantasyonu esas alınarak hazırlanmıştır. İş akışı önerileri, örnek senaryo ve test listesi Vekosis’in bu rehber için sunduğu uygulama yaklaşımıdır. Kullanılabilir işlevler; sürüm, abonelik, kurulu uygulamalar ve özel geliştirmelere göre farklılaşabilir.

• Odoo — Field Service görev oluşturma
• Odoo — Satış sonrası hizmetler ve yerinde müdahale
• Odoo — Rota planlama
• Odoo — Worksheets
• Odoo — Ürün ve depo yönetimi
• Odoo — Helpdesk SLA politikaları
• Odoo — Zaman takibi ve faturalama
• Odoo — Online barındırma ve özel modül kapsamı