Dijital teklif sürecinde sürüm, kapsam ve onay nasıl yönetilir?

Örnek bir iş senaryosu

Bir müşteri standart renk yerine özel renk istediğinde değişen yalnızca birim fiyat olmayabilir. Termin, aksesuar ve işçilik de değişebilir. Yeni sürümde sadece toplamı göstermek yerine değişen satırları ve gerekçeyi belirtin. Eski bağlantıyı açan müşteri güncel teklifin bulunduğunu anlayabilsin. “Görüntülendi” bilgisiyle “kabul edildi” bilgisini ayırın; bağlantının açılması tek başına bir onay süreci değildir.

Dört adımda çalışma düzeni

İlk bakışta görünmeyen noktalar

Teklif ekranındaki hesaplamaları birkaç sınır örneğiyle deneyin. Miktarı sıfır olan satır, ondalıklı ölçü, satır indirimi ve genel indirim bir arada kullanıldığında sonuç açıklanabilir olmalıdır. Kullanıcı toplamı elle değiştiriyorsa bu değişikliğin hangi kaleme yansıdığı görünmelidir. Para birimi ve geçerlilik bilgisi teklifin üst bölümünde yer almalı; farklı sürümlerin toplamları karşılaştırılırken aynı kapsamı temsil edip etmediği kontrol edilmelidir. Gönderilen belgeye sonradan ürün açıklaması değişikliği yansıtmak yerine belgeyi gönderildiği haliyle koruyun. Böylece müşterinin aldığı bilgi ile şirketin daha sonra gördüğü kayıt aynı kalır. Teklifin sözleşmeye dönüşmesinde hangi alanların taşınacağı ayrıca kararlaştırılmalıdır.

Operasyon ekibiyle uygulama çalışması

Birlikte çalışacağınız ekipten son dönemde tamamlanan bir normal işi ve sorun yaşanan bir işi seçmesini isteyin. Müşteri bilgilerinin yerine temsili isimler kullanın. Her iki iş için ilk talep, keşif, teklif, planlama ve kapanış sırasında hangi bilgiye ihtiyaç duyulduğunu sırayla yazın. Normal işte görünmeyen kontrol ihtiyacı sorunlu örnekte ortaya çıkabilir. Örneğin renk değişikliği, eksik malzeme veya müşterinin tarihi ertelemesi farklı durumlar gerektirir. Bu çalışma ekran tasarlamadan önce işin sınırlarını netleştirir. Sonunda her adımın sahibi, gerekli girdisi ve tamamlanma koşulu belli olmalıdır.

İlk denemede bütün ürün gruplarını kapsamak yerine tek bir akış seçin. Kullanıcının aynı bilgiyi kaç kez girdiğini, bir önceki aşamadaki belgeyi nasıl bulduğunu ve bekleyen işin nedenini anlayıp anlamadığını gözleyin. İşin farklı kişiye devri özellikle test edilmelidir: yeni kişi telefonla açıklama almadan mevcut durumdan devam edebiliyor mu? Devam edemiyorsa eksik bilgiyi belirleyin. Her alanı zorunlu yapmak yerine gerçekten devir için gereken bilgiyi zorunlu tutun. Tamamlanmış işler üzerinde toplu değişiklik yapılmasının geçmişi nasıl etkilediğini de kontrol edin.

Değerlendirme toplantısını yalnızca ekran beğenisi üzerinden yürütmeyin. Bir işin aranıp bulunma süresi, plan değişikliğinin ekibe ulaşması ve açık eksiklerin görünürlüğü gibi somut sonuçlara bakın. Başlangıç değerlerini küçük bir örneklemde ölçüp aynı koşullarda yeniden deneyin. Sonuçları bütün işletme için kesin başarı oranı gibi sunmayın; pilotun kapsamını belirtin. Kullanıcının sistem dışında not tutmaya devam ettiği yerleri sorun. Bu notlar bazen gereksiz alışkanlık, bazen de eksik iş akışının işaretidir. Nedenini anlamadan yasaklamak yerine uygulamayı ve çalışma düzenini birlikte iyileştirin.

Ekibinize sorabileceğiniz sorular

• Müşterinin gördüğü son sürüm hangisi?
• Kapsam değişiklikleri açıkça karşılaştırılabiliyor mu?
• Teklifin neden kaybedildiği kayda giriyor mu?

Bu soruları seçtiğiniz örnek kayıt üzerinde yanıtlayın. Her açık nokta için sorumlu kişiyi, yapılacak düzeltmeyi ve yeniden kontrol tarihini not edin. Böylece görüşme, uygulanabilir bir iş listesiyle tamamlanır.