Ana içeriğe geç

Web sitesi bakım teklifinde kapsam nasıl netleştirilir?

Yazar: · SRN Dijital Kurucusu ve Full Stack Developer
İlk yayın: .

SRN Dijital logosu ve Bakım mı, yeni özellik mi? başlığı; Kapsam, Öncelik, Teslim alt başlığı. Temsili kurumsal site ekranında Menü hatası ve Yeni form açıklamaları; gerçek müşteri teslim ekranı değildir.

Web sitenizde mobil menü çalışmıyor; aynı zamanda yeni bir teklif formu eklemek istiyorsunuz. İki talep aynı mesajda iletilse de aynı işi tarif etmez. Bakım teklifini değerlendirirken mevcut hatanın giderilmesini, düzenli güncellemeyi ve yeni özellik geliştirmeyi ayırmak gerekir.

“Aylık bakım var” ifadesi, hangi işlemin ne zaman ve hangi koşullarla yapılacağını tek başına açıklamaz. İşletmenin ihtiyacı yalnız bir sorunun çözülmesi olabilir; başka bir projede düzenli kontrol, içerik desteği ve entegrasyon takibi gerekebilir. Doğru kapsam, sitenin gerçek durumu ve beklenen değişiklikler incelendikten sonra belirlenir.

Önce talepleri üç ayrı gruba ayırın

Mevcut bir işlevin beklenen şekilde çalışmaması hata kaydıdır. Metin veya görsel güncellemesi içerik işi olabilir. Yeni bir üyelik ekranı, rapor veya entegrasyon ise geliştirme kapsamı oluşturabilir. Bu ayrım her projede teknik incelemeyle doğrulanmalıdır; küçük görünen bir düğme değişikliği arka planda farklı sistemleri etkileyebilir.

Teklif görüşmesine şu şekilde hazırlanabilirsiniz:

Örneğin var olan formun gönderilememesi ile forma dosya yükleme eklenmesi farklı taleplerdir. Birinin bakım paketinde bulunması diğerinin de otomatik olarak dahil olduğunu göstermez. Mevcut web sitesi hata düzeltme görüşmesinde bu farkı somut örneklerle yazın.

“Dahil” denilen işin sınırını görünür kılın

Bakım listesinde yalnız “güncelleme, destek, yedek” başlıkları bulunması yeterli olmayabilir. Hangi yazılımın güncelleneceği, hangi ekranların kontrol edileceği ve ek iş çıktığında nasıl değerlendirileceği açıklanmalıdır. İçerik düzenleme, tasarım değişikliği veya üçüncü taraf bağlantısı aynı kapsamda olmayabilir.

WordPress'in resmi güncelleme belgesi, işlem öncesi yedeği ve güncelleme adımlarını ayrı ele alır. Bu, bir platforma ait teknik dayanak örneğidir. Özel yazılımın dağıtım ve veri yapısı farklı olabilir; WordPress işlemleri bütün sitelere aynen uygulanmamalıdır.

Kullandığınız tema, eklenti veya hizmetin lisans yenilemesini kimin takip edeceğini de sorun. Hosting, alan adı, e-posta ve dış servisler için sorumlular ayrı olabilir. Bu kalemlerin bakım teklifinde açıkça yer almaması, ücretsiz veya otomatik olarak dahil oldukları anlamına gelmez.

İlk yanıt ile sorunun çözümünü ayırın

Bir talebin alındığının bildirilmesi, teşhisin tamamlandığı veya düzeltmenin yayına çıktığı anlamına gelmez. Destek saatlerini, hangi kanaldan kayıt açılacağını ve önceliklendirme biçimini görüşün. “Acil” ifadesinin neyi kapsadığı iki taraf için anlaşılır olmalıdır.

Sipariş akışının durması, bir sayfadaki yazım hatası ve yeni bir kampanya alanı farklı önceliklerde değerlendirilebilir. Bu örneklerden sabit çözüm süresi çıkarılamaz. Sağlayıcı kesintisi, erişim eksikliği veya veri onarımı gerekiyorsa süre teknik incelemeye bağlıdır. İncelenmemiş bir sistem için kesin saat veya kesintisizlik sözü vermek doğru bir başlangıç değildir.

İşletme açısından yararlı soru şudur: Talep kaydında mevcut durum, sıradaki adım ve beklenen bilgi görülebiliyor mu? Yalnız “ilgileniyoruz” cevabı yerine hangi aşamada olunduğunu bilmek, iş takibini kolaylaştırır.

Yedek ve geri dönüş sorumluluğunu tekliften ayırmayın

Hangi dosyaların ve verinin korunacağı, yedek tarihinin nasıl izleneceği ve gerektiğinde geri dönüşü kimin yürüteceği belirtilmelidir. WordPress'in resmi yedekleme belgesi dosyalar ile veritabanını ayrı bileşenler olarak açıklar. Başka altyapılarda da kapsam, gerçek mimariye göre incelenir.

Yedek bulunduğunu söylemek, geri yükleme yolunun sınandığını kanıtlamaz. Canlı sistem yeni sipariş veya talep alıyorsa eski sürüme dönüşün yeni kayıtları nasıl etkileyeceği ayrıca değerlendirilir. Bakım teklifinde bu sorunun kime ait olduğunun görünmesi gerekir; yalnız arşiv dosyası teslim etmek bütün sorumlulukları kapatmaz.

Gerçek bakım deneyimi nasıl değerlendirilir?

SRN Dijital'in Adrasya/MOTR CRM vaka kaydı, stok ve fatura akışında bakım, canlı sistem yedeği ve onarım öncesi veri kayıtlarını anlatır. Teknik kapsam, müdahaleden önceki durumun korunmasına ve belirli iş akışının onarımına örnektir.

Bu kayıt bir WordPress projesi, her bakım talebinin aynı sürede çözüleceği veya ölçülmüş satış artışı kanıtı değildir. Sağlayıcının örneğini kendi altyapınıza yakınlığı, müdahale sınırı ve teslim kaydı üzerinden değerlendirin. Genel portföy sayısı, sorununuzun teşhis edildiği anlamına gelmez.

Teslim ve sonraki değişiklikler nasıl takip edilmeli?

Hata kaydının kapanması için beklenen davranışı ve kontrol edilen ekranları yazın. Mobil ve masaüstü görünüm, ilgili bağlantı veya formun gerçekten çalışması farklı kontrol noktalarıdır. Bir düğmenin görünmesi, mesajın alıcıya ulaştığını tek başına kanıtlamaz. Güvenli test yapılamadıysa bu sınır açıkça kayıtlı olmalıdır.

Yapılan değişiklik, yayın zamanı ve kalan işler bakım raporunda bulunabilir. Sonradan gelen yeni özellik isteği, mevcut hata kaydına sessizce eklenmek yerine ayrıca değerlendirilmelidir. Kurumsal web tasarım yenilemesi gerekiyorsa da bunun gerekçesi, korunacak içerik ve taşınacak veriyle birlikte açıklanmalıdır.

İzmir merkezli SRN Dijital, Türkiye geneline mevcut site desteği ve özel yazılım hizmeti verir. Site adresinizi, sorun listesini ve istediğiniz yeni özellikleri ayrı yazarak bakım kapsamını birlikte değerlendirelim. İlk mesajda parola, ödeme bilgisi veya müşterilerinize ait özel kayıt paylaşmanız gerekmez. Kesin bedel ve takvim inceleme sonrasında netleşir.

Kaynaklar

Kaynak kontrolü: 20 Ekim 2026. Kapsam ve takip soruları SRN Dijital'in editoryal önerisidir; kesin süre, kesintisizlik veya müşteri kazanımı garantisi değildir.

Kısa cevap: Web sitesi bakım teklifinde neler yazmalı?

Mevcut hataları, rutin kontrolleri, içerik işlerini ve yeni özellikleri ayırın. Dahil olan işlemleri, erişim ve lisans sorumlularını, destek saatlerini, yedek/geri dönüş ve kabul yöntemini netleştirin. İlk yanıtı çözüm sanmayın; tamamlanan değişikliği ve kalan işleri gerçek kontrol kaydıyla takip edin.