Dijital Dönüşümde Web Sitesinin Rolü Nedir? Şirketler İçin Yol Haritası

Dijital dönüşümde web sitesinin rolü, çoğu şirketin sandığından çok daha geniştir. Site yalnızca bir tanıtım vitrini değildir; müşterinin kendi işini kendisi hallettiği, teklif istediği, sipariş verdiği ve sipariş durumunu takip ettiği bir çalışma alanıdır. Bu yazıda 2012'den beri sahada gördüklerime dayanarak, sitenizi operasyonun merkezine taşıyan aşamalı bir yol haritası paylaşıyorum.

Dijital dönüşümde web sitesinin rolü nedir?

Dijital dönüşümde web sitesinin rolü, müşteriyle yürüttüğünüz tekrar eden işleri telefondan, e-postadan ve kâğıttan alıp çevrim içi, ölçülebilir ve kendi kendine işleyen akışlara taşımaktır. Site; self servis bilgi, müşteri portalı, online teklif ve sipariş ile iç sistemlere bağlanan otomasyonların buluştuğu ana kapı olur.

Burada ayrımı net koymak istiyorum. Sitenin pazarlama kanallarını toplayan merkez olması ayrı bir konudur; reklam, SEO ve sosyal medya trafiğini karşılayan tarafı anlatır. Bu yazı ise işin arka ofis yüzüne bakıyor: müşteri siteye geldikten sonra hangi işi sizin çalışanınızı meşgul etmeden bitirebiliyor?

Örneğin bir sanayi firması düşünün. Bayi her hafta telefon açıp stok soruyor, fiyat listesi istiyor, siparişini e-postayla gönderiyor. Satış ekibi bu mesajları tek tek sisteme giriyor. Dönüşüm, bu zinciri bir portal ve bir sipariş formuyla kısaltmaktır. Yani teknoloji amaç değil, zaman ve hata maliyetini düşürmenin aracıdır.

Neden dönüşüm projeleri siteyi merkeze almalı?

Çünkü müşteri artık tedarikçiyle konuşmadan önce kendi başına araştırıyor ve mümkünse işini kendi başına bitirmek istiyor. Gartner'ın satışın geleceği araştırmasına göre B2B alıcılar satın alma sürecinde zamanlarının yalnızca yüzde 17'sini olası tedarikçilerle görüşmeye ayırıyor. Gartner aynı çalışmada B2B satış etkileşimlerinin yüzde 80'inin dijital kanallara kayacağını öngörmüştü.

Bu tablo size şunu söyler: müşterinizin zamanının büyük kısmını sizinle değil, ekranla geçiriyorsunuz. Dolayısıyla o ekranda cevap bulamayan müşteri ya sizi arar ve ekibinizi meşgul eder ya da cevabı veren rakibe gider.

Öte yandan iç süreç tarafında da benzer bir baskı var. Excel dosyaları, WhatsApp grupları ve e-posta zincirleri büyüdükçe hata oranı artıyor. Site ve portal, bu dağınık bilgiyi tek kayıt noktasında topluyor. Böylece hem müşteri hem çalışan aynı veriye bakıyor.

Kısacası dönüşümün ön yüzü sitedir. Arka tarafta ERP veya CRM ne kadar iyi olursa olsun, müşteri onu siteden görür ve siteden kullanır.

Web sitesi hangi operasyonel işleri devralabilir?

İlk adım olarak sitenin devralabileceği işleri listelemenizi öneririm. Bunu yaparken çalışanlarınıza şu soruyu sorun: "Hangi soruyu haftada on kez cevaplıyorsunuz?" Cevaplar genellikle aşağıdaki başlıklarda toplanır.

• Bilgi talepleri: ürün özellikleri, teknik föyler, kullanım kılavuzları, sertifikalar.
• Fiyat ve teklif: standart ürünlerde fiyat, özel işlerde yapılandırılmış teklif formu.
• Sipariş ve tekrar sipariş: bayi veya kurumsal müşterinin geçmiş siparişini tek tıkla yinelemesi.
• Durum takibi: sipariş, kargo, servis kaydı veya başvuru durumunu müşterinin kendisinin görmesi.
• Belge erişimi: fatura, irsaliye, sözleşme ve garanti belgelerini portaldan indirme.
• Randevu ve servis talebi: takvimden boş saat seçme, arıza kaydı açma.

Bu listenin her maddesi, telefonda veya e-postada harcanan bir dakikayı temsil eder. Ancak hepsini aynı anda çözmeye çalışmayın. Hacmi en yüksek ve kuralı en net olan işten başlarsınız; ilerleyen bölümlerde bu önceliklendirmeyi nasıl yapacağınızı anlatacağım.

Self servis bilgi merkezi nasıl kurulur?

Self servis, müşterinin sorusunun cevabını sizi aramadan bulabilmesidir. Bunun en ucuz ve en hızlı sonuç veren biçimi iyi düzenlenmiş bir bilgi merkezidir: sık sorulan sorular, teknik dokümanlar, nasıl yapılır rehberleri ve kısa videolar.

Kurarken şu sırayı izliyorum. İlk olarak destek ve satış ekibinden son üç ayın en sık sorularını topluyorum. Ardından her soruyu tek bir sayfada, net bir başlıkla cevaplıyorum. Sonra bu sayfaları ürün sayfalarından ve portal içinden bağlıyorum. Böylece müşteri cevabı tam ihtiyaç duyduğu anda görüyor.

Önemli bir detay: bilgi merkezinin arama kutusu gerçekten çalışmalı. Müşteri kendi kelimeleriyle arar; siz ise teknik terimlerle yazarsınız. Bu yüzden arama kayıtlarını ayda bir inceleyip boş sonuç dönen sorguları yeni içeriğe çeviriyorum. Bu yaklaşımın SEO tarafındaki karşılığını merak ediyorsanız öne çıkan snippet rehberim soru odaklı sayfaların nasıl yapılandırılacağını anlatıyor.

Üstelik bilgi merkezi, ileride kuracağınız sohbet botuna veya yapay zekâ asistanına da kaynak olur. Temiz yazılmış yüz cevap, kötü beslenmiş bir bottan her zaman daha değerlidir.

Bilgi merkezinin başarısını da basitçe ölçebilirsiniz. Bir sayfayı okuyan müşterinin ardından destek hattını arayıp aramadığına bakın. Arıyorsa, sayfa soruyu tam cevaplamıyor demektir. Bu durumda sayfayı destek ekibinin gerçek cevabıyla yeniden yazıyorum.

Müşteri portalı ne zaman gerekir?

Müşteri portalı, giriş yapan müşteriye özel verileri gösteren kapalı alandır. Genel bilgi merkezinden farkı kişiselliktir: müşteri kendi siparişlerini, kendi faturalarını, kendi fiyat listesini görür.

Portala şu durumlarda ihtiyaç duyarsınız. Birincisi, aynı müşteriyle tekrar eden bir ilişkiniz varsa; bayi, abonelik, bakım sözleşmesi gibi. İkincisi, müşteriye özel fiyat veya koşul uyguluyorsanız. Üçüncüsü, belge trafiği yoğunsa ve muhasebe ekibiniz sürekli fatura kopyası gönderiyorsa.

Buna karşılık tek seferlik satış yapan bir işletmede portal çoğu zaman gereksiz bir maliyettir. Orada iyi bir sipariş takip sayfası ve e-posta bildirimleri yeterli olur. Yani portal kararı teknolojiyle değil, müşteri ilişkisinin tekrar sıklığıyla verilir.

Portalı teknik olarak kurarken bir noktaya dikkat edin: giriş gerektiren sayfalar arama motorunda görünmemeli. Google Search Central'ın noindex rehberi bu sayfaları dizinden nasıl uzak tutacağınızı açıkça anlatıyor. Ayrıca portal adresini robots dosyasında doğru tanımlamak için robots.txt oluşturucu aracını kullanabilirsiniz.

Online teklif süreci nasıl tasarlanmalı?

Teklif, B2B tarafında en çok zaman kaybettiren süreçlerden biridir. Müşteri eksik bilgiyle yazar, satışçı geri döner, bilgiler üç e-postada tamamlanır. Online teklif formu bu döngüyü ilk adımda kapatmayı hedefler.

Standart ürünlerde bir adım daha ileri gidebilirsiniz: fiyat hesaplayıcı. Müşteri ölçüyü, adedi ve seçenekleri girer, tahmini fiyatı anında görür. Böylece satış ekibi yalnızca gerçekten özel işlere zaman ayırır. Ancak hesaplayıcının kurallarını satış müdürüyle birlikte yazın; yanlış bir fiyat, hiç fiyat vermemekten daha fazla zarar verir.

İyi bir teklif formu, teklif hazırlamak için gereken bilgiyi zorunlu alanlarla ister ama müşteriyi yormaz. Bunun için formu adımlara bölüyorum: önce ürün veya hizmet türü, sonra miktar ve teknik detay, en son iletişim bilgisi. Her adım bir önceki cevaba göre şekilleniyor; ilgisiz alanlar görünmüyor.

Formun arkası da en az önü kadar önemli. Talep geldiğinde CRM'de kayıt açılmalı, doğru satışçıya atanmalı ve müşteriye otomatik bir alındı mesajı gitmeli. Bu mesajda teklifin ne zaman geleceğini yazmak, gereksiz takip aramalarını belirgin biçimde azaltıyor; bu benim saha gözlemim, garanti değil.

Form tasarımının ayrıntılarını, alan sayısını ve hata mesajlarını randevu, teklif ve demo formu tasarımı yazımda ayrıca ele aldım. Burada vurgulamak istediğim, formun bir iş akışının başlangıcı olduğudur.

Online sipariş için e-ticaret sitesi mi, B2B sipariş portalı mı?

Online sipariş denince akla ilk olarak klasik e-ticaret geliyor. Ancak kurumsal müşteriye satış yapan şirketlerde ihtiyaç farklıdır: müşteriye özel fiyat, vadeli ödeme, minimum sipariş miktarı, onay akışı ve toplu sipariş. Aşağıdaki tablo iki yaklaşımı yan yana koyuyor.

Bazı şirketler ikisine birden ihtiyaç duyar: son tüketiciye açık bir mağaza ve bayilere kapalı bir portal. Bu durumda aynı ürün verisini iki yüzde kullanmak en sağlıklı yoldur. Bu konuda karar verirken e-ticaret danışmanlığı sürecimde ilk iş sipariş kurallarınızı yazıya döküyorum.

Süreç otomasyonu siteye nasıl bağlanır?

Süreç otomasyonu, siteden gelen bir olayın insan eli değmeden bir sonraki adımı tetiklemesidir. Örneğin bir sipariş geldiğinde stoktan düşmek, depoya iş emri açmak ve müşteriye onay e-postası göndermek.

Bunu kurmanın üç yolu var. Birincisi doğrudan API entegrasyonu; site, ERP veya CRM ile doğrudan konuşur. İkincisi entegrasyon platformları; hazır bağlayıcılarla iki sistemi eşleştirirsiniz. Üçüncüsü ara tablo veya dosya aktarımı; eski sistemlerde tek gerçekçi seçenek olabilir.

Hangisini seçeceğiniz, arka sistemin kabiliyetine bağlıdır. Bu nedenle projeye başlamadan önce ERP tedarikçinizden API belgesini isteyin. Belge yoksa ya da eksikse, bunu en başta bilmek bütçeyi ve takvimi gerçekçi kurmanızı sağlar.

Otomasyonda en sık gördüğüm hata, hata durumunu düşünmemektir. Entegrasyon bir gün mutlaka kopar. O gün siparişin kaybolmaması için her aktarımın kaydını tutun ve başarısız olanları bir kişiye bildirin. Böylece otomasyon sessizce bozulmaz, hatayı siz müşteriden önce görürsünüz.

Hangi süreçten başlamalısınız?

Öncelik sırasını belirlemek için basit bir puanlama kullanıyorum. Her aday süreç için üç soruyu soruyorum: bu iş ayda kaç kez tekrar ediyor, kuralları ne kadar net ve hata yaptığında maliyeti ne kadar yüksek?

1. Hacim: ayda yüzlerce kez tekrar eden iş, onlarca kez tekrar edenden önce gelir.
2. Kural netliği: "her zaman şöyle yaparız" dediğiniz iş kolay otomatikleşir; "duruma göre" dediğiniz iş beklemeli.
3. Hata maliyeti: yanlış fiyat veya kaybolan sipariş gibi pahalı hatalar önceliği yükseltir.
4. Müşteri görünürlüğü: müşterinin doğrudan hissettiği iyileşme, iç motivasyonu da artırır.
5. Bağımlılık: başka bir sistemin hazır olmasını bekleyen iş, sonraki aşamaya kalır.

Pratikte bu puanlama çoğu şirkette aynı sonucu verir: sipariş durumu takibi ve belge erişimi ilk sıraya çıkar. Çünkü ikisi de yüksek hacimli, kuralları net ve müşteri tarafından hemen fark ediliyor. Özel fiyatlı sipariş portalı ise genellikle ikinci veya üçüncü aşamaya kalıyor.

Dijital dönüşümde web sitesinin rolü için aşamalı yol haritası nasıl olmalı?

Tek seferde her şeyi yapmaya çalışan projeler genellikle ya bitmez ya da bittiğinde ihtiyaç değişmiş olur. Bu yüzden dönüşümü aşamalara bölüyorum. Her aşama tek başına değer üretmeli ve bir sonrakine veri sağlamalı.

1. Keşif (aşama 0): süreç envanteri, tekrar eden işlerin listesi, mevcut sistemlerin haritası.
2. Temel (aşama 1): hızlı, mobil uyumlu, güncel bir site; bilgi merkezi ve yapılandırılmış teklif formu.
3. Görünürlük (aşama 2): sipariş ve servis durumu takibi, belge indirme, otomatik bildirimler.
4. İşlem (aşama 3): giriş yapan müşteriye özel fiyat, online sipariş, tekrar sipariş.
5. Entegrasyon (aşama 4): ERP, CRM ve muhasebe ile çift yönlü veri akışı.
6. İyileştirme (aşama 5): kullanım verisine göre yeni self servis işlevleri ve kişiselleştirme.

Sürelere gelince, bunları şirketin büyüklüğü ve mevcut altyapısı belirler. Saha tecrübeme göre küçük ve orta ölçekli bir şirkette ilk iki aşama birkaç ay içinde canlıya çıkabilir; ancak bu bir başlangıç aralığıdır, garanti değildir. Entegrasyon aşaması ise en çok sürpriz çıkaran bölümdür.

Her aşamanın sonunda kısa bir değerlendirme toplantısı yapıyorum. Bu toplantıda üç şeye bakıyoruz: hedeflenen metrik değişti mi, kullanıcılar ne şikâyet etti ve bir sonraki aşamanın kapsamı hâlâ doğru mu? Böylece yol haritası donmuş bir belge olmaktan çıkıyor ve gerçek kullanım verisiyle güncelleniyor.

Aşama 1'de sitenin temeli nasıl sağlamlaştırılır?

Portal ve otomasyon, sağlam olmayan bir sitenin üzerine kurulursa sorunlar katlanır. Bu nedenle ilk aşamada sitenin kendisini ele alıyorum: hız, mobil uyum, içerik yönetimi ve güvenlik.

Mobil tarafı özellikle önemsiyorum. Sahada çalışan bayi, servis teknisyeni veya satın almacı siteyi telefondan açıyor. Bu yüzden form ve portal ekranlarını önce telefona göre tasarlıyorum. Yaklaşımın ayrıntıları mobil öncelikli tasarım yazımda duruyor.

İçerik yönetimi de temelin bir parçası. Fiyat listesini, teknik föyü veya duyuruyu güncellemek için her seferinde yazılımcıya gitmek zorunda kalıyorsanız dönüşüm yavaşlar. Yani ekibinizin kendi içeriğini kendisi yönetebildiği bir panel, ilk aşamanın olmazsa olmazıdır.

Son olarak kurumsal e-posta altyapısını kontrol edin. Otomatik bildirimler şirket alan adınızdan gidecek; bu adres spam klasörüne düşerse sistem çalışsa bile müşteri görmez. Bu konuyu kurumsal e-posta altyapısı yazımda ayrıntılı anlattım.

Mimari seçim: hazır platform mu, özel yazılım mı?

Bu soru her projede gündeme geliyor ve tek bir doğru cevabı yok. Hazır platformlar hızlı başlar, bakımı kolaydır; ancak özel iş kurallarınızı zorlayabilir. Özel yazılım tam uyum sağlar; fakat maliyeti ve bakım yükü daha yüksektir.

Benim kullandığım ölçüt şudur: iş kuralınız sektörünüzde yaygın mı? Yaygınsa, örneğin standart bir B2B fiyatlandırma, hazır bir çözüm büyük ihtimalle bunu destekler. Kural size özgüyse ve rekabet avantajınızı oluşturuyorsa, o parça için özel geliştirme mantıklı hâle gelir.

Çoğu zaman karma bir yapı çıkıyor. Tanıtım sitesi ve bilgi merkezi hazır bir içerik yönetim sisteminde, portal ise ayrı bir uygulama olarak çalışıyor. Büyük kurumlarda bu parçaları bağımsız ekiplerin yönetebildiği yapılar da mümkün; micro frontend mimarisi yazım tam bu ihtiyacı anlatıyor.

Hangi yolu seçerseniz seçin, veri sahipliği sizde kalsın. Müşteri ve sipariş verisini dışa aktaramadığınız bir platform, ileride sizi kilitler.

Ekip ve iç süreçler dönüşüme nasıl hazırlanır?

Teknoloji kurulur ama insanlar kullanmazsa hiçbir şey değişmez. Sahada gördüğüm başarısız projelerin çoğu yazılımdan değil, benimsenmemekten başarısız oldu.

Bu nedenle her süreç için bir sahip belirliyorum. Teklif formundan satış müdürü, portal belgelerinden muhasebe, bilgi merkezinden destek ekibi sorumlu oluyor. Sahipsiz içerik birkaç ay içinde eskiyor ve müşteri güvenini kaybettiriyor.

Sahiplerin işini kolaylaştırmak için basit bir takvim de koyuyorum. Örneğin fiyat listesini her ay başında, teknik föyleri ürün değiştiğinde, sık sorulan soruları üç ayda bir gözden geçiriyoruz. Bu hatırlatmaları proje yönetim aracına ekliyorum; böylece güncelleme kişinin hafızasına kalmıyor.

İkinci adım, eski kanalı yavaş yavaş kapatmaktır. Portal açıldıktan sonra fatura kopyası isteyen müşteriye kibarca portal bağlantısını göndermek, alışkanlığı değiştirir. Ancak bunu bir anda yasaklamayın; müşteriye geçiş süresi tanıyın.

Üçüncü adım, çalışanlara zaman kazancını göstermektir. Otomasyonun işini elinden alacağından korkan bir ekip, sistemi farkında olmadan sabote edebilir. Oysa doğru anlatıldığında aynı ekip, rutin işten kurtulup daha değerli işe zaman ayırdığını görüyor.

Dijital dönüşümde web sitesinin rolü hangi metriklerle ölçülür?

Operasyonel dönüşümün başarısını pazarlama metrikleriyle ölçemezsiniz. Ziyaretçi sayısı artabilir ama destek ekibinin yükü aynı kalıyorsa dönüşüm olmamıştır. Bu yüzden şu göstergeleri takip ediyorum.

• Self servis oranı: siteden veya portaldan tamamlanan işlemlerin toplam işlemlere oranı.
• Destek talebi hacmi: tekrar eden soru türlerinde aylık telefon ve e-posta sayısı.
• Teklif dönüş süresi: talep ile teklif gönderimi arasındaki ortalama süre.
• Sipariş hata oranı: düzeltilmesi gereken sipariş sayısı.
• Portal aktif kullanımı: ay içinde giriş yapan müşteri hesabı oranı.

Bu metriklerin çoğunu sitede değil, CRM ve destek sisteminde bulursunuz. Dolayısıyla ölçüm, pazarlama ekibinin değil, proje sahibinin sorumluluğunda olmalı. Her metriği projeye başlamadan önce ölçün; yoksa iyileşmeyi kanıtlayamazsınız. Ölçüm kurgusunun genel çerçevesi için KPI rehberime, hedef tanımı için dönüşüm hedefi yazıma bakabilirsiniz.

Güvenlik ve kişisel veri tarafında nelere dikkat etmelisiniz?

Portal ve online sipariş, siteyi kişisel veri ve ticari bilgi taşıyan bir sisteme dönüştürür. Dolayısıyla güvenlik, tanıtım sitesine göre çok daha ciddi bir konu hâline gelir.

Temel kontrol listem şu maddelerden oluşuyor. Tüm trafik HTTPS üzerinden akmalı. Giriş ekranında deneme sınırlaması ve mümkünse iki adımlı doğrulama bulunmalı. Her kullanıcı yalnızca kendi şirketinin verisini görmeli; bu yetki kontrolünü her istekte sunucu tarafında yapmalısınız.

Ayrıca KVKK kapsamında aydınlatma metnini ve açık rıza gerektiren işlemleri hukuk danışmanınızla birlikte gözden geçirin. Portalda hangi kişisel veriyi tuttuğunuzu, ne kadar süre sakladığınızı ve kimlerin eriştiğini yazılı hâle getirin.

Son olarak yedekleme ve kayıt tutmayı unutmayın. Bir sipariş kaybolduğunda veya bir fatura yanlış kişiye gittiğinde, ne olduğunu kayıtlardan geri izleyebilmelisiniz. Bu kayıtlar hem hatayı düzeltmenizi hem de müşteriye şeffaf açıklama yapmanızı sağlar.

Sanayi ve hizmet firmalarında tipik senaryolar neler?

Sektöre göre yol haritası değişir ama bazı kalıplar sık tekrar ediyor. Aşağıda en sık karşılaştığım üç senaryoyu özetliyorum.

Üretici ve distribütör: bayiler için özel fiyatlı sipariş portalı, stok görünürlüğü ve teknik doküman arşivi. Burada ilk kazanım genellikle telefon trafiğinin azalmasıdır. Sanayi firmaları için site tarafını sanayi ve üretim firmaları için web tasarım yazımda ayrıca ele aldım.

Servis ve bakım firması: arıza kaydı açma, teknisyen randevusu, servis geçmişi ve bakım raporlarının portalda saklanması. Böylece müşteri "teknisyen ne zaman geliyor?" sorusunu sormadan cevabı görür. Üstelik servis geçmişi portalda durduğu için yeni teknisyen de sahaya hazırlıklı gider.

Profesyonel hizmet firması: danışmanlık, mühendislik veya hukuk bürosu gibi. Burada online teklif, belge paylaşımı ve proje durum ekranı öne çıkar. Müşteri dosyalarını e-postayla göndermek yerine güvenli bir alana yükler.

Her senaryoda ortak nokta şudur: müşterinin en sık sorduğu soruyu siteye taşıdığınızda hem müşteri hem ekip rahatlıyor.

Dönüşüm projelerinde en sık yapılan hatalar nelerdir?

Yıllar içinde aynı hataların farklı şirketlerde tekrarlandığını gördüm. Bunları bilmek, bütçenizin önemli bir kısmını korur.

• Süreci düzeltmeden dijitalleştirmek: kötü bir süreci otomatikleştirirseniz, hatayı daha hızlı üretirsiniz.
• Her şeyi ilk sürüme sığdırmak: aylarca süren geliştirme, kullanıcı geri bildirimi olmadan yanlış yöne gider.
• Müşteriye sormamak: portalın hangi işlevini kullanacağını müşteriye sormadan tasarlamak.
• Sahipsiz içerik: güncellenmeyen fiyat ve belgeler, müşteriyi tekrar telefona yönlendirir.
• Entegrasyonu hafife almak: ERP tarafındaki kısıtları geç öğrenmek takvimi uzatır.
• Ölçmeden başlamak: başlangıç verisi olmadan kazanımı gösteremezsiniz.

Bu hataların hiçbiri teknik değil; hepsi planlama ve sahiplenme hatası. Bu yüzden projenin ilk haftasını kod yazmaya değil, süreçleri kâğıda dökmeye ayırıyorum.

Bir de gözden kaçan küçük bir hata var: test kullanıcılarını yalnızca şirket içinden seçmek. Çalışanlarınız süreci ezbere bildiği için eksik bir adımı fark etmez. Oysa iki üç gerçek müşteriyle yapacağınız yarım saatlik deneme, ekranlardaki kafa karıştıran noktaları hemen ortaya çıkarır. Bu yüzden canlıya çıkmadan önce mutlaka birkaç sadık müşteriden geri bildirim alıyorum.

Bütçeyi aşamalara nasıl bölmelisiniz?

Dönüşüm bütçesini tek kalem olarak onaylatmak zordur ve risklidir. Bunun yerine her aşamayı ayrı bir karar noktası olarak ele almanızı öneririm. Bir aşama beklenen sonucu verirse bir sonrakine geçersiniz.

Bu yaklaşım iki fayda sağlıyor. Birincisi, yönetim her aşamanın sonunda somut bir kazanım görüyor. İkincisi, ilk aşamadan gelen kullanım verisi, sonraki aşamanın kapsamını daha doğru belirlemenizi sağlıyor.

Bütçeyi planlarken yalnızca geliştirme maliyetini değil, süregelen maliyetleri de hesaba katın: barındırma, lisanslar, bakım, güvenlik güncellemeleri ve içerik güncellemesi için ayrılan iç zaman. Sahada gördüğüm en büyük sürpriz, bu yıllık kalemlerin ilk kurulum kadar önemli olmasıdır.

Örnek hesap olarak şöyle düşünebilirsiniz: bir çalışan günde bir saatini tekrar eden fatura kopyası taleplerine ayırıyorsa, bu yılda yaklaşık 250 saat eder. Belge portalının getirisini bu saatin şirkete maliyetiyle karşılaştırarak kabaca tahmin edebilirsiniz.

Dijital dönüşümde web sitesinin rolünü kim yönetmeli?

Bu soru çoğu zaman sorulmuyor ama projenin kaderini belirliyor. Site pazarlama departmanına, portal bilgi işleme, süreçler operasyona ait olduğunda kimse bütünü görmüyor.

Benim önerim, yönetim kurulundan veya genel müdürden yetki alan tek bir proje sahibidir. Bu kişi teknik uzman olmak zorunda değil; ancak departmanlar arasında karar alabilmeli. Yanına pazarlama, operasyon, satış ve bilgi işlem temsilcilerinden oluşan küçük bir çekirdek ekip koyarsınız.

Dış destek aldığınızda da aynı kural geçerli. Tasarım bir firmada, yazılım başka firmada, entegrasyon üçüncü bir firmada olursa sorumluluk dağılır. Bu yüzden web tasarım projelerimde entegrasyon ve süreç tarafını da baştan kapsama alıyorum.

Kısacası dönüşüm bir yazılım projesi değil, bir iş projesidir. Site bu işin görünen yüzüdür; ama arkasındaki kararları insanlar verir.

Nereden başlamalı ve bir sonraki adım ne olmalı?

Bu yazıyı okuduktan sonra yapacağınız ilk iş basit: ekibinizle bir saat oturun ve müşterilerin en sık sorduğu on soruyu, en sık istediği beş belgeyi ve en çok zaman alan üç süreci yazın. Bu liste, yol haritanızın ilk sayfasıdır.

Ardından her maddeyi hacim, kural netliği ve hata maliyetine göre puanlayın. En yüksek puanlı iki işi Aşama 1 ve Aşama 2'ye koyun. Böylece birkaç ay içinde görünür bir kazanım elde edersiniz ve sonraki aşamalar için yönetim desteği kazanırsınız.

Unutmayın, McKinsey'in B2B Pulse araştırması alıcıların kabaca üçte birinin self servisi, üçte birinin uzaktan görüşmeyi, üçte birinin yüz yüze görüşmeyi tercih ettiğini gösteriyor. Yani hedef satış ekibini kaldırmak değil; müşteriye seçme hakkı vermek ve ekibinizi rutin işten kurtarmaktır.

Kendi şirketiniz için bu yol haritasını birlikte çıkarmak isterseniz iletişim sayfamdan bana ulaşabilirsiniz. İlk görüşmede süreç envanterinize bakar, hangi aşamadan başlamanın mantıklı olduğunu konuşuruz.