Bir müşteri satın aldığı üründe sorun yaşadığında, işletme başvuruyu ürün ve siparişle ilişkilendirmeli, sıradaki adımı açıklamalıdır. Talebi sıradan bir mesaj kutusuna bırakmak, bilgilerin tekrar sorulmasına ve ekiplerin farklı kayıtlar tutmasına yol açabilir. Bu rehber, servis vakasının açılışından kapanışına kadar izlenebilir bir akışı tarif eder.

Buradaki örnekler yöntem açıklamak için kurgusaldır; belirli bir işletmenin hizmet verdiğini, yerel servisi, süreyi, ücreti veya sonucu anlatmaz. Garanti hakkı, tüketici yükümlülüğü, yasal süre, ücret ve uygun servis kararı bu yazının konusu değildir. Bunlar ürün, sözleşme ve güncel koşullara göre işletmenin yetkili kişileri ve gerektiğinde uzmanları tarafından belirlenmelidir. Yazılımın işi, onaylanan iş akışını anlaşılır kaydetmek ve ilgili kişilere doğru bilgiyi sunmaktır.

Önce servis vakasını başka taleplerden ayırın

Bir müşteri kullanım kılavuzunu bulamıyorsa, sipariş adresini değiştirmek istiyorsa veya ürünü iade etmek istiyorsa bunlar aynı işlem değildir. Servis vakası, ürünün incelenmesi, onarım gereksiniminin değerlendirilmesi ya da yetkili servis sürecinin başlatılması gibi ayrı bir operasyon gerektirir. İlk ekranda talep türünü seçilebilir kılın; ancak müşteriden teknik teşhis koymasını beklemeyin. “Sorun bildir”, “kurulum bilgisi iste” ve “iade/değişim talep et” gibi yolları birbirine karıştırmayın.

Vakayı doğru sipariş ve ürünle eşleştirin

Bir siparişte aynı modelin farklı renkleri, birden çok ürün veya farklı tarihlerde verilmiş siparişler bulunabilir. Bu nedenle yalnızca müşteri adı ya da ürün adı üzerinden arama yapmak yeterli olmayabilir. Talep, ilgili sipariş satırı ve ürün varyantıyla bağlanmalıdır. Ürün kodu, sipariş numarası veya seri numarası gibi alanlardan hangilerinin gerektiğini işletmenin gerçek ürün kayıtlarına göre belirleyin. Her ürün için seri numarası bulunacağı varsayılmamalıdır.

Sistem müşteriyi oturum açmaya zorlamadan da talebi doğrulayabilir; bunun yolu kullanılan altyapıya bağlıdır. Giriş zorunluysa başka bir kişinin siparişine erişimi önleyecek kontrol tanımlanmalıdır. Misafir alışverişinde sipariş numarası ve doğrulama yöntemi gibi seçenekler, gereksiz kişisel veri toplamadan değerlendirilmelidir. Kimlik ve erişim kararları teknik tasarım kadar işletmenin güvenlik ve veri işleme sorumlularıyla da ele alınmalıdır.

Formu teşhis sınırıyla tasarlayın

İyi bir form, müşteriye “üründe ne bozuk?” diye teknik bir hüküm verdirmez. Bunun yerine sorunun ne zaman fark edildiğini, hangi kullanım adımında ortaya çıktığını, ürünün açılıp açılmadığını veya hata mesajı görülüp görülmediğini sade sorularla öğrenebilir. Fotoğraf veya kısa video isteniyorsa bunun hangi durumda yararlı olduğu ve müşterinin hangi hassas bilgileri görüntüye eklememesi gerektiği açıklanmalıdır. Dosya ekleme her vaka için zorunlu tutulmamalıdır.

Talep formu ilk incelemeyi başlatır; tanıyı ve onarım kararını otomatik olarak doğrulamaz. Belirsiz cevaba izin verin. Müşterinin “emin değilim” diyebilmesi, tahmini bir seçeneği gerçek bilgi gibi kaydetmekten iyidir. Çalışan da ek bilgi gerektiğinde hangi soruyu sorduğunu ve yanıtın hangi vaka için alındığını kaydedebilmelidir. Bu, müşterinin daha sonra aynı açıklamayı farklı kanallarda tekrar etmesini azaltmaya yardımcı olur; belirli bir destek sonucu garantisi değildir.

Durumları gerçek iş olaylarına bağlayın

“İşlemde” gibi tek bir etiket müşteriye ve ekibe yeterli bağlam sağlamaz. Örneğin “talep alındı”, “sipariş eşleşmesi bekliyor”, “inceleme için yönlendirildi”, “ek bilgi bekleniyor”, “değerlendirme tamamlandı” ve “vaka kapatıldı” ayrı anlamlar taşıyabilir. Her durumun ne zaman seçileceği, bir sonraki sorumlunun kim olduğu ve müşteriye hangi açıklamanın gideceği önceden yazılmalıdır.

Bir kayıt oluşturulunca fiziksel inceleme başlamış sayılmaz; servis birimine iletmek de onarımın kabul edildiği anlamına gelmez. İş akışı, talep ile yapılan işlemi ayırmalıdır. Ekip karar verdikten sonra sistem durumunu değiştirebilir; müşteriye gösterilen ifade de aynı gerçeği anlatmalıdır. Bir aşama işletmenin kullandığı süreçte yoksa, sırf yazılım örneğinde bulunduğu için eklemeyin. Durum sayısı değil, her durumun anlaşılır ve uygulanabilir olması önemlidir.

Teklif, onay ve hizmet kararını birbirinden ayırın

İnceleme sonunda ücretli işlem, ek parça, ürün değişimi ya da başka bir hizmet önerilebilir; bazı vakalarda öneri oluşmayabilir. Bu seçeneklerin hangi koşulda sunulacağı işletmenin onaylı politikasına bağlıdır. Yazılım, müşteriye henüz incelenmemiş bir bedeli kesin fiyat gibi göstermemeli; öneriyi, müşterinin onayını ve gerçekleşen işlemi farklı kayıtlar olarak tutmalıdır. Onay alınmadan başlatılmaması gereken bir adım varsa bunu görünür kılın.

Ürün hareketi varsa fiziksel teslimi de kaydedin

Bazı incelemeler ürünü bir servis noktasına ulaştırmayı gerektirebilir, bazıları uzaktan yürütülebilir. Hangi yöntemlerin sunulacağı işletme kararıdır. Ürün taşınacaksa gönderi talebi, taşıyıcıya teslim, kabul ve geri gönderim olayları vaka kaydından izlenebilmelidir. Bu bilgiler siparişin ilk kargo kaydıyla karıştırılmamalıdır; servis hareketi farklı tarih ve sorumlulara sahip olabilir.

Müşteriye verilen mesajları vaka durumuna göre ayarlayın

Otomatik e-posta ya da hesap ekranı, müşteriye beklenen sonraki adımı söyleyebilir. “Talebiniz ulaştı” mesajı, “ürününüz incelendi” veya “işlem tamamlandı” mesajından farklı olmalıdır. Kesinleşmemiş süre ve ücretleri söz vermeden yazın. Ek bilgi gerekiyorsa hangi sorunun yanıtlanacağı açık olsun; müşteri yanıt verdiğinde cevabın hangi vakaya ekleneceği de korunmalıdır. Bir bildirim gönderilemediyse vaka kaydının kendisi kaybolmamalıdır. Sipariş sonrası doğru talimat ve başvuru bilgisini ayırma yaklaşımı için satın alma sonrası destek rehberine de bakabilirsiniz.

Yönlendirme ve erişim sorumlularını belirleyin

Vaka desteğe ulaştığında kimin inceleyeceği, hangi durumda teknik ekibe veya yetkili hizmet noktasına aktarılacağı ve cevap beklenirken kimin takip edeceği belli olmalıdır. Bir kişinin şirketten ayrılması ya da görev değişikliği, açık kayıtların sahipsiz kalmasına yol açmamalıdır. Her rolün ihtiyacı kadar erişim verin. Talebi gören herkesin ödeme, iletişim veya müşteri profilinin tüm ayrıntılarını görmesi gerekmeyebilir.

Atama kuralları gerçek ekip yapısıyla uyuşmalı; otomatik yönlendirme başarısız olduğunda yedek sorumlu tanımlanmalıdır. İşletmede ayrı teknik ekip yoksa yazılım böyle bir ekip varmış gibi varsayım üretmemelidir. Başlangıçta basit bir sorumlu listesi ve elle yönlendirme uygun olabilir. Önemli olan açık kayıtların yaşını, beklediği kişiyi ve son güncelleme olayını görebilmektir. Ürün modeli, seçenek ve fiziksel nesne ayrımını daha iyi tanımlamak için ürün ve yedek parça uyumluluğu rehberine bakabilirsiniz; bu içerik satış sonrası servis vakasının yerine geçmez.

Servis verisini ürün ve iade kayıtlarından ayrı ilişkilendirin

Bir servis vakası siparişe ve ürüne bağlı olsa bile aynı kayıt türü değildir. Sipariş satış anını, iade talebi malın geri dönüşünü, servis vakası ise inceleme ve hizmet kararlarını anlatır. Bunları tek bir metin alanında birleştirirseniz hangi aşamanın tamamlandığı anlaşılamayabilir. İade hareketinin kendi stok ve ödeme adımları için e-ticaret iade akışı rehberini inceleyin; servis ile iade aynı işlem değildir. Ayrı kayıtlar gerektiğinde ortak sipariş numarasıyla ilişkilendirilebilir. Ürün stoğu veya iade tutarı, servis vakası açıldı diye kendiliğinden değişmemelidir.

Yayına çıkmadan önce uçtan uca servis senaryosu deneyin

Testi sadece formun gönderilmesiyle bitirmeyin. Giriş yapmış sipariş, misafir siparişi, yanlış ürün seçimi, ürün kimliği bulunamayan kayıt, eksik fotoğraf, ek bilgi bekleme, teklif kabulü, reddi, fiziksel teslim, yönlendirme hatası ve kapanış gibi örnekleri hazırlayın. Her senaryoda başlangıç verisini, beklenen durum değişikliğini, sorumluyu, müşteriye gidecek mesajı ve doğrulama adımını yazın. Gerçek müşterilerin özel bilgileri yerine test kayıtları kullanın.

Aynı talebin yeniden gönderilmesi iki ayrı açık vaka üretmemelidir. Sistem önceki kaydı bulamıyorsa ekip benzer ürün, sipariş ve zaman bilgisini kontrol etsin; eski kapanış değiştirilmeden yeni gelişme ayrıca kaydedilsin. Yayın öncesi senaryolar için e-ticaret kabul testi rehberi yardımcı olabilir.

Proje kapsamını ve içerik sorumluluğunu netleştirin

Bir e-ticaret projesinde ajans form ekranı, vaka durumları, bildirim şablonları ve entegrasyonları geliştirebilir; hangi ürünlerin servise kabul edildiği, ücret, süre, garanti, onarım ve müşteri iletişim politikası işletmenin onaylaması gereken kararlardır. Ürün bilgisini ve hizmet koşullarını yetkili kişiler sağlamalıdır. Ajansın bu koşulları kendiliğinden tanımlaması doğru değildir. Teklifte hangi ekranın, raporun, otomasyonun ve eğitim dokümanının teslim edileceğini ayrı yazın.

BiKreatif’in E-Ticaret Yazılımı hizmeti, mağaza ve sipariş operasyonunu proje kapsamı içinde değerlendirmek isteyen işletmeler için görüşme başlangıcı olabilir. Görüşmeye bugün kullanılan destek kanallarını, bir örnek sipariş akışını ve servis kararı veren rolleri getirin. Herhangi bir yerel ofis, servis ağı, müşteri sonucu veya belirli performans iddiası bu yazıda ileri sürülmüyor.

Sık sorulan sorular

Servis talebi ile ürün kullanım sorusu nasıl ayrılır?

Kullanım sorusu çoğu zaman ürünün doğru talimatına veya bilgi kaynağına yönlendirmeyi gerektirir. Servis talebi ise inceleme, onarım değerlendirmesi veya yetkili hizmete aktarım gibi ayrı bir iş gerektirebilir. Müşterinin başta doğru seçimi yapması yararlı olsa da kararı teknik teşhis olarak sunmayın. İnceleme sırasında tür değiştirilebilsin ve ilk açıklama kaybolmasın.

Formda seri numarası zorunlu tutulmalı mı?

Yalnız ürünlerde gerçekten bulunan ve süreçte eşleştirme için kullanılan numarayı isteyin. Her üründe seri numarası yoksa bu alanı zorunlu yapmak müşteri başvurusunu engeller. Alternatif olarak sipariş satırı, ürün seçimi veya ürün kodu kullanılabilir. Hangi tanımlayıcının gerekli olduğu katalog yapısına ve hizmet sürecine göre işletme tarafından belirlenmelidir.

Fotoğraf yüklemek servis talebinde şart olmalı mı?

Fotoğraf bazı görünür durumları anlamaya yardımcı olabilir, fakat her sorunu göstermez ve müşterinin elinde uygun görüntü olmayabilir. Formda neden istendiğini açıklayın, isteğe bağlı seçenek sunmayı değerlendirin ve görüntüde ödeme bilgisi, adres veya başka hassas ayrıntıların yer almaması gerektiğini belirtin. Fotoğraf tek başına arıza tanısı ya da onarım kararı sayılmamalıdır.

Talep açılınca onarım başlamış sayılır mı?

Hayır. Talebin kaydedilmesi yalnızca başvurunun alındığını gösterir. Ürün ve sipariş eşleşmesi, inceleme, hizmet kapsamı ve gerekiyorsa müşteri onayı ayrı aşamalardır. Müşteri ekranında talep alındı ile işlem başladı ifadelerini birbirinden ayırın. Gerçek çalışma başlamadan tamamlanma tarihi veya sonuç sözü vermeyin.

Servis vakası ile iade kaydı aynı siparişe bağlanabilir mi?

Bağlanabilir, ancak iki olayın kayıtları ve durumları ayrı kalmalıdır. İade malın geri dönmesi ve ödeme/stok kararlarını; servis vakası inceleme ve hizmet adımlarını anlatır. Biri diğerini otomatik olarak kapatmamalıdır. Aynı siparişteki ortak ürün ve satır bilgileri ilişki kurmaya yardım ederken işlemlerin farklı sorumluları da görülebilir.

Müşteriye ne zaman süre veya ücret bilgisi verilir?

İşletmenin yetkili kişileri doğrulanmış bilgiye ulaştığında, ilgili koşul ve varsa belirsizlik açıkça aktarılmalıdır. İnceleme yapılmadan standart süre veya fiyatı her vakaya uygulamak doğru olmayabilir. Sistem teklif, onay ve gerçekleşen işlemi ayrı göstermeli; otomatik mesaj henüz kesinleşmeyen bir kararı kesinleşmiş gibi sunmamalıdır.

Bir vaka kapatıldıktan sonra yeni bilgi gelirse ne yapılır?

İşletme yeni bilginin aynı vakaya eklenmesini veya yeni vaka açılmasını hangi koşullarda istediğini tanımlamalıdır. Önceki karar ve kapanış geçmişi korunmalı; yeni gelişme ayrı zaman ve sorumluyla kaydedilmelidir. Sistem eski notu sessizce silmemeli. Müşteriye yeni bir kayıt açıldıysa bunun önceki taleple ilişkisi açıklanabilir.

Başlangıçta ayrı bir servis yazılımı gerekir mi?

Her işletme için aynı altyapı gerekli değildir. Mevcut mağaza paneli temel vaka ve durum kaydını destekleyebilir veya harici bir araçla entegrasyon gerekebilir. Kararı çalışan sayısı, ürünler, erişim ihtiyacı, mevcut destek kanalları ve gerçek iş akışı belirler. Küçük bir örnek senaryoyu uçtan uca deneyerek hangi kayıtların eksik kaldığını görün.