Shopify mağazanız için destek planlarken işi bitiren koşula ve tekrar sıklığına bakın. Tanımlı bir sayfa veya işlevin hazırlanması, kontrol edilmesi ve teslimi tek proje olarak ele alınabilir. İşin tamamlandığını gösterecek davranış ve kontrollere “kabul koşulları” denir. Tekrarlayan ihtiyaçlar ise görev, ayrılacak çalışma kapasitesi, öncelik ve gözden geçirme düzeni tanımlanmış bir çalışma gerektirebilir.
“Bakım var” cümlesi bu kapsamı açıklamaz. Günlük ürün girişi, tema güncellemesi, uygulama arızası ve yeni bir kampanya sayfası farklı sorumluluklar doğurur. Hangisini satın aldığınızı ve hangi işin marka ekibinde kaldığını yazmalısınız. Aşağıdaki tabloyla kendi ihtiyaçlarınızdan bir destek kapsamı dosyası oluşturabilirsiniz.
Önce ihtiyaçları dört gruba ayırın
Geçmişte yaşadığınız ve yakında beklediğiniz işleri listeleyin. Her satırda sorunu veya ihtiyacı örnekle gösterin. İşi hemen “aylık destek” diye adlandırmak yerine hangi gruba ait olduğunu görün.
Dar ekranda tabloyu yana kaydırabilirsiniz.
| İş türü | Örnek | Kapsamı belirleyen soru |
|---|---|---|
| Günlük operasyon | Ürün bilgisini düzeltmek, sipariş istisnasını takip etmek | Marka içinde kim yapabiliyor, hangi durumda dış destek gerekiyor? |
| Tanımlı geliştirme | Ürün sayfasına yönetilebilir bir bilgi bölümü eklemek | Beklenen davranış ve teslim sınırı ne? |
| Teknik bakım / uyumluluk kontrolü | Tema sürümünü, özel kodu ve ilgili uygulamayı birlikte değerlendirmek | Neler değişiyor, hangi akışlar yeniden kontrol edilecek? |
| Olay / sorun incelemesi | Sepete eklemede beklenmeyen hata veya sağlayıcıdan dönmeyen durum | Etki nedir, hangi kayıt var, teknik sahibi kim? |
İlk grup dışarıya verilmek zorunda değildir. Ekibin günlük yapabildiği işleri, belirli teknik ihtiyaçlarla karıştırmayın. Son grupta da arızanın kaynağı baştan belli olmayabilir; ilk teslim bazen araştırma bulgusu ve sonraki adım olur.
Hangi işler tek proje olarak planlanabilir?
Tek proje için başlangıç durumu, teslim ve kabul noktası tanımlanabilir olmalı. Örneğin seçilmiş ürünlerde kullanılacak yeni bir tema bölümü; tasarım, uygulama, örnek içerik, mobil kontrol ve kullanım aktarımıyla sınırlandırılabilir.
Kapsamda kaç sayfa veya şablon olduğu, içerikleri kimin hazırladığı ve hangi uygulamalara dokunulduğu yazılmalı. Yeni bir ihtiyacın ortaya çıkması, tamamlanmış teslimin kendiliğinden genişlemesi anlamına gelmez. Eklenecek işin kapsam, bedel ve takvim etkisi uygulamadan önce değerlendirilir.
Teknik neden bilinmiyorsa çözüm projesinden önce inceleme kapsamı belirlenebilir. “Hatanın nedenini araştırmak ve bulguyu sunmak” ile “kaynağı ne olursa olsun her hatayı gidermek” aynı taahhüt değildir. Sağlayıcıya bağlı bir sorun saptandığında kimin destek kaydı açacağı da görünür olmalı.
Müdahalenin temayı yenilemeyi gerektirip gerektirmediği henüz belli değilse tema yenileme ve geliştirme rehberini kullanın. Burada karar, teknik çözümün ayrıntısından önce işin nasıl kapsamlandırılacağıdır.
Düzenli çalışma hangi koşullarda anlamlı olabilir?
Benzer ihtiyaçlar tekrar ediyor, her seferinde yeniden bağlam aktarımı yapılıyor veya yakın dönemde birbiriyle ilişkili çok sayıda değişiklik bekleniyorsa düzenli bir çalışma değerlendirilebilir. Bunun için en azından tekrar eden işlerin ve karar verecek kişinin belli olması gerekir.
Geçmiş işlerinize bakın: Hangi talepler geldi? Hangisi gerçekten uygulandı? Ne kadarı ürün içeriği, ne kadarı teknik değişiklikti? Görüşme ve onay bekleyen işler neden kaldı? Kayıt yoksa bir süre gelen ihtiyaçları toplamaya başlayın; henüz kullanılacağı bilinmeyen kapasiteyi zorunlu gider olarak kabul etmeyin.
Düzenli çalışmada bir iş listesi, yeni talep alma yöntemi ve öncelik kararı olmalı. Anlaşılan kapasiteye hangi araştırma, görüşme, test ve yayın işlerinin dahil olduğu açıklanmalıdır. Her ayın aynı sayıda değişiklik üreteceğini veya her talebin aynı eforu gerektireceğini varsaymayın.
Çalışmanın belirli dönemlerde yeniden değerlendirilmesini isteyin: Tekrarlayan ihtiyaç azaldı mı? Marka ekibi bazı işleri devraldı mı? Daha büyük bir değişiklik ayrı proje gerektiriyor mu? Sürekli çalışma, kapsamın sürekli belirsiz kalması anlamına gelmemeli.
Destek dosyanızı iş, sıklık ve sorumlulukla kurun
Çalışma tablolarını ayrı kullanmak için Shopify uzman ve proje çalışma dosyasını açıp kopyalayabilirsiniz.
Bu tabloyu kendi mağazanız için doldurun. “Gerektiğinde” yazdığınız satırda, gereğin hangi olayla oluştuğunu da belirtin. Bir kişi ihtiyacı bildirebilir, başka bir kişi uygulayabilir ve marka tarafındaki yetkili sonucu kabul edebilir.
Dar ekranda tabloyu yana kaydırabilirsiniz.
| İhtiyaç / örnek | Sıklık veya tetikleyici | Marka sorumlusu | Dış destekten beklenen | Kapanış kanıtı | Çalışma türü |
|---|---|---|---|---|---|
| Ürün açıklaması güncelleme | Yeni bilgi onaylandığında | Ürün/içerik sahibi | Yalnız yönetim engeli varsa yardım | Doğru içerik ve sayfa kontrolü | İç operasyon / sınırlı iş |
| Yeni ürün bilgi bölümü | Tanımlı yeni ihtiyaç | İçerik ve kabul sahibi | Tasarım, uygulama, kontrol, aktarım | Onaylı senaryolar ve kullanım notu | Proje |
| Tema sürümü değerlendirme | İlgili sürüm veya uyumluluk ihtiyacı | Yayın karar yetkilisi | Değişiklik ve aktarım kapsamı | Kontrol kaydı ve yayın kararı | Sınırlı proje / tekrarına göre destek |
| Alışverişi engelleyen hata | Sorun bildirildiğinde | Olayı ve işletme etkisini bildiren | İnceleme, sorumluya devir, kapsam içi müdahale | Aynı senaryonun yeniden kontrolü | Önceden tanımlanmış olay süreci |
| Kendi ihtiyacınız | … | … | … | … | … |
Örnek satırlar çalışma modeli göstermek içindir; bütün mağazalar veya hizmet sağlayıcılar için standart kapsam değildir. İşin sahibi ve kapanış kanıtı boşsa yalnız “düzenli destek” seçmiş olmak boşluğu doldurmaz.
Hata, yeni istek ve sağlayıcı sorunu nasıl ayrılır?
Bir iş, üzerinde anlaşılan davranışı sağlamıyorsa kabul koşulu ve teslim kaydıyla birlikte inceleyin. Sonradan istenen farklı davranış ise yeni ihtiyaç olabilir. Ayrımı yalnız mesajın “çalışmıyor” veya “küçük değişiklik” diye adlandırılmasıyla yapmayın.
Hata düzeltme kapsamı ve varsa ilgili dönem sözleşmede ayrıca tanımlanır. Bu rehber bütün sağlayıcılar için ortak bir garanti süresi belirlemez. Değişiklik sonrasında başka bir uygulama veya tema sürümünün davranışı etkilemesi de ayrı araştırma gerektirebilir.
Ödeme, kargo veya uygulama sağlayıcısının sorumluluğundaki bir olayda destek ekibinin rolünü yazın: kayıt toplamak, ilgili sağlayıcıya iletmek, marka ekibini bilgilendirmek veya kendi kapsamındaki düzenlemeyi yapmak. Sağlayıcının çözüm zamanını kontrol edemeyen taraf adına kesin çözüm süresi üretmeyin. Ayrıntılı operasyon adımları için mevcut ödeme ve kargo rehberleri kullanılabilir.
Örnek üzerinden düşünelimTemsili örnek: bir yeni bölüm ve tekrar eden kampanya değişiklikleri
Varsayımsal örnek · Gerçek müşteri veya satış sonucu değildir.
Bir markanın ürün sayfasına yeni bir ölçü bölümü ekletmek istediğini, ayrıca kampanya metinlerini düzenli değiştirdiğini düşünün. Ölçü bölümü tanımlı bir proje olabilir. Kampanya metinleri marka ekibinin yönetebileceği alanlara aktarılırsa her içerik değişikliği için teknik destek gerekmeyebilir.
Temanın izin vermediği yeni kampanya işlevleri tekrar ediyorsa bunlar ayrı bir iş listesiyle değerlendirilebilir. Bu örnek gerçek mağaza incelemesi değildir; tekrar eden içerik işinin neden otomatik olarak düzenli geliştirme ihtiyacı sayılmaması gerektiğini gösterir.
Yanıt, araştırma ve çözüm aşamalarını ayrı konuşun
Destek talebine cevap verilmesi, sorunun kaynağının bulunması ve kalıcı olarak çözülmesi farklı aşamalardır. Çalışma saatleri, talep kanalı, etki sınıfları, kimin öncelik vereceği ve kapsam dışındaki durumda nasıl ilerlenileceği yazılabilir. Bunlar taraflar arasında kararlaştırılmalıdır.
Alışverişi tamamen engelleyen bir sorunla küçük bir görsel isteğin aynı sırada beklememesi için etki tanımı yapın. Bir hata bildiriminde sayfa, cihaz, adımlar, beklenen ve görülen sonuç ile ilgili kayıt bulunsun. Müşteriye ait bilgileri yalnız gerektiği kadar ve yetkili kişilerle paylaşın.
Planladığınız dönemde sorunu kim fark edecek? Destek ekibine kim bildirecek? İlk yanıt neyi kapsayacak? İnceleme sonrası ek iş gerekiyorsa kimin onayı alınacak? Kesintisiz izleme veya belirli sürede çözüm, ayrıca anlaşılmadan kapsamda kabul edilmemeli.
Tema güncellemesi ve geri dönüşü somutlaştırın
Shopify'ın tema güncelleme belgesi, özel kodun yeni sürüme aktarılmasının çatışmalara bağlı olduğunu ve uygulama uyumluluğunun kontrol edilmesi gerektiğini açıklar. Theme Store dışından alınmış temalar standart güncelleme yolunu kullanamayabilir. Güncelleme işinin kapsamı kullanılan temaya göre belirlenir.
Tema kopyası bütün mağazanın yedeği değildir. Tema indirmesi ürün, koleksiyon, menü, sayfa ve diğer mağaza verilerini içermez. Mağaza yedekleme açıklaması farklı verileri ayrı ele alır; geri yükleme yolları da aynı değildir.
Bu yüzden destek dosyasında “yedek alınacak” ifadesini açın: Nelerin kopyası tutulacak, kim erişecek, hangi değişiklik geri alınabilecek ve hangisi başka bir işlem gerektirecek? Kullanılacak yöntemin geri yükleme kontrolünü de kapsamlandırın. Bir dosyanın varlığı, geri dönüşün denenmiş olduğu anlamına gelmez.
Tema düzenini taslakta hazırlarken ürün, menü veya uygulama ayarı gibi ortak mağaza değişikliklerini ayrıca işaretleyin. Yayın öncesi geri dönüş kararı, bu alanların etkisini de dikkate almalı.
Çalışma kapsamına şu alanları ekleyin
- Amaç, mevcut durum ve kapsama giren işler.
- Kapsam dışı işler ve başka sağlayıcılara bağlı adımlar.
- Talep alma, öncelik verme ve ek iş onay yöntemi.
- Marka girdileri, uygulayan kişi ve kabul yetkilisi.
- Kullanılacak kapasitenin veya teslimlerin nasıl takip edileceği.
- Kontrol, yayın, geri dönüş ve değişiklik kaydı.
- Platform, tema, uygulama giderleri ile hizmet bedelinin ayrımı.
- Çalışma sona erdiğinde açık işler, dokümanlar ve erişimlerin devri.
Bu alanlar bir destek kapsamı dosyası oluşturur. Ücret ve düzenli araç giderlerini ayrıca görmek için kurulum maliyeti rehberinden yararlanabilirsiniz. Destek için ayırdığınız bütçeyi yalnız talep sayısıyla değil, kapanan işler ve devralabildiğiniz sorumluluklarla değerlendirin.
İhtiyaç listenizi uygun çalışma görüşmesine taşıyın
Marka içinde kalacak işler için yayın sonrası görev planını, teknik taleplerin sırası için geliştirme önceliklendirme rehberini kullanabilirsiniz.
Önce kendi tablonuzda hangi işlerin içeride yürütülebileceğini ve hangilerinin teknik destek gerektirdiğini işaretleyin. Tek bir tanımlı ihtiyaç varsa proje kapsamıyla başlayabilirsiniz. Tekrar eden işler varsa sıklıklarını ve bugünkü işleyişi gösterin.
D2C Studio'nun Shopify tasarım ve geliştirme hizmeti belirli sayfa, tema ve işlev ihtiyaçlarını kapsamlandırır. Görüşmeye hazır olduğunuzda mağaza adresinizi, teknik destek gerektiren iş örneklerinizi ve sorumlulukta açık kalan alanları geliştirme başvurusuna ekleyebilirsiniz. İlk projenin teslimleri ile sonrasında gerekebilecek işleri ayrı ayrı tarif edin.


