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.

Önce ihtiyaçları dört gruba ayırın

Dar ekranda tabloyu yana kaydırabilirsiniz.

İş türüÖrnekKapsamı belirleyen soru
Günlük operasyonÜrün bilgisini düzeltmek, sipariş istisnasını takip etmekMarka içinde kim yapabiliyor, hangi durumda dış destek gerekiyor?
Tanımlı geliştirmeÜrün sayfasına yönetilebilir bir bilgi bölümü eklemekBeklenen davranış ve teslim sınırı ne?
Teknik bakım / uyumluluk kontrolüTema sürümünü, özel kodu ve ilgili uygulamayı birlikte değerlendirmekNeler değişiyor, hangi akışlar yeniden kontrol edilecek?
Olay / sorun incelemesiSepete eklemede beklenmeyen hata veya sağlayıcıdan dönmeyen durumEtki 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.

Destek dosyanızı iş, sıklık ve sorumlulukla kurun

Dar ekranda tabloyu yana kaydırabilirsiniz.

İhtiyaç / örnekSıklık veya tetikleyiciMarka sorumlusuDış destekten beklenenKapanış kanıtıÇalışma türü
Ürün açıklaması güncellemeYeni bilgi onaylandığındaÜrün/içerik sahibiYalnız yönetim engeli varsa yardımDoğ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 sahibiTasarım, uygulama, kontrol, aktarımOnaylı senaryolar ve kullanım notuProje
Tema sürümü değerlendirmeİlgili sürüm veya uyumluluk ihtiyacıYayın karar yetkilisiDeğ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 hataSorun bildirildiğindeOlayı ve işletme etkisini bildirenİnceleme, sorumluya devir, kapsam içi müdahaleAynı 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.