Agentic Commerce Hazırlık Raporu: ticaret altyapısının dönüşümü

Raporun kapsamı

Bu rapor, işletmelerin yapay zekâ ajanlarıyla yürüyen ticarete nasıl hazırlanabileceğini strateji, veri, teknoloji, müşteri deneyimi ve işletim boyutlarıyla ele alır. E-ticaret yöneticileri, teknoloji ve ürün ekipleri, finans ve operasyon sorumluları ile uygulama ortakları için hazırlanmıştır.

Webtures yaklaşımının merkezinde üç inceleme ekseni bulunur: ürün keşfi, veri doğruluğu ve güncelliği, izin verilen işlemin güvenilir biçimde yürütülmesi. Raporda bu eksenler dört ticari yetenek ve sekiz denetim alanıyla açıklanır. Teknik bulgular, görev testleri ve ekonomik değerlendirme aynı uygulama planında birleştirilir.

Belge bir hazırlık ve dönüşüm çerçevesidir. Tamamlanmış ulusal saha ölçümü, müşteri sıralaması veya gerçek ödeme testi sonuçları içermez. Kontrol listeleri, pilot örneklemi, görev kartları ve maliyet hesapları ilgili yerlerde uygulama önerisi veya temsili örnek olarak tanımlanmıştır. Platformlara ilişkin değerlendirmeler araştırma tarihindeki koşullarla sınırlıdır; canlı uygulamadan önce hesap ve işlem kapsamı yeniden doğrulanmalıdır.

Yönetici okuyucu ilk sekiz bölümle stratejik çerçeveyi, uygulama ekipleri teknik ve yöntem bölümleriyle çalışma düzenini, yatırım kararını veren ekipler son sekiz bölümle ekonomik ve kurumsal modeli izleyebilir. Dört uygulama eki, değerlendirmeyi somut kontrollere ve görev kayıtlarına dönüştürür.

1 Yönetici değerlendirmesi

Agentic Commerce, müşterinin ihtiyacını ifade ettiği an ile işletmenin bu ihtiyacı karşılamak için gerçekleştirdiği işlemler arasındaki ilişkinin yeniden tasarlanmasını gerektiriyor. Yapay zekâ sistemleri ürün arayabiliyor, seçenekleri karşılaştırabiliyor, teklif hazırlayabiliyor ve uygun koşullarda işlem araçlarını kullanabiliyor. İşletmeler için asıl karar, bu görevlerin hangisini hangi doğruluk ve yetki sınırları içinde destekleyecekleri.

Webtures olarak hazırlığı üç temel soru üzerinden ele alıyoruz. Ürün müşterinin ihtiyacına göre bulunabiliyor mu? Karar için kullanılan bilgi doğru, yeterli ve güncel mi? İzin verilen işlem güvenilir biçimde tamamlanabiliyor veya gerektiğinde kullanıcıya devredilebiliyor mu? Bu sorular, görünürlüğü ticaret altyapısıyla ilişkilendirir ve araştırmanın uygulanabilir sonucunu belirler.

Bir markanın AI yanıtlarında daha çok görünmesi değerli olabilir. Ancak görünürlük, doğru varyantın seçildiğini, teslimat sözünün karşılanacağını veya ödeme yetkisinin bulunduğunu kanıtlamaz. Benzer biçimde bir API’nin çalışması, müşterinin o kanalı benimseyeceğini göstermez. Hazırlık programı keşif, veri, işlem ve ticari sonuçları ayrı ölçmeli; aralarındaki bağlantıyı kanıt üzerinden kurmalıdır.

Bu raporun temel önerisi, kapsamı dar fakat ticari açıdan anlamlı görevlerle başlamaktır. Önce bir ürün grubu, bir müşteri ihtiyacı ve bir son işlem seçilir. Sonra başlangıç durumu gözlenir, hatanın kaynağı belirlenir, ilgili ekip değişikliği uygular ve aynı görev yeniden değerlendirilir. Böylece yatırım kararı genel bir teknoloji beklentisinden, işletmenin kendi sistemlerinde elde ettiği kanıta taşınır.

Yönetim açısından beş karar öne çıkmaktadır. Birincisi, hangi ticari görevin iyileştirilmesinin öncelikli olduğudur. İkincisi, ürün ve teklif bilgisinde hangi sistemin belirleyici kabul edileceğidir. Üçüncüsü, ajanın hangi koşullarda işlem yapabileceği ve nerede duracağıdır. Dördüncüsü, teknik başarı ile ekonomik katkının nasıl ayrılacağıdır. Beşincisi, katalog ve platform değiştikçe güvenilirliğin nasıl korunacağıdır.

Bu yaklaşımın Webtures için karşılığı, ticaret altyapısının dönüşümünü uygulamaya taşıyan uzmanlık modelidir. Değer; izinli teknik denetimi, kontrollü görev testlerini, düzeltme planını ve yeniden doğrulamayı birbirine bağlamaktan doğar. Katalog, ürün deneyimi, veri mühendisliği, entegrasyon ve ticari operasyon ekipleri aynı müşteri görevi üzerinde çalışır.

Bugünden yapılabilecek işler gelecekteki kanal açılışlarını beklememelidir. Ürün kimliğinin tutarlı hale gelmesi, fiyatın doğru aktarılması, teslimat koşullarının açıklanması ve müşterinin onayladığı sepetin korunması mevcut müşteri deneyimine de katkı sağlar. Daha ileri ödeme ve otonomi yetenekleri, bu temelin üzerine hesap, ülke ve sağlayıcı uygunluğu doğrulandıkça eklenir.

Rapor boyunca önerilen kontrol listeleri, örnek görevler ve pilot sayıları bir çalışma tasarımı olarak sunulmaktadır. Bunlar tamamlanmış bir saha araştırmasının bulguları değildir. Hazırlık düzeyine ilişkin bir işletme kararı ancak ilgili kapsamda elde edilen kanıtla verilebilir.

2 Agentic Commerce kavramının kapsamı

Agentic Commerce, yapay zekâ sistemlerinin kullanıcı adına ticari araştırma, seçim, işlem hazırlama ve işlem yürütme görevlerine katılmasıdır. Kullanıcının bütün kararlarını bir sisteme devretmesi gerekmez. Bir ajan uygun ürünleri daraltabilir, kullanıcı seçimini bekleyebilir ve ardından sepeti hazırlayabilir. Başka bir akışta önceden belirlenmiş bütçe, satıcı ve ürün sınırları içinde daha fazla işlem yetkisi bulunabilir.

Bu kapsam, bir ürün sorusunu yanıtlayan sohbet uygulamasıyla tam olarak örtüşmez. Sohbet uygulaması bilgi verebilir; ajan ise araçlarla çalışarak dış sistemde bir durum değişikliği oluşturabilir. Aradaki fark arayüzün görünüşünden çok, sistemin ne yapmaya yetkili olduğu ve yaptığı işlemin nasıl doğrulandığıdır. Bir sohbet penceresi ajan içerebilir; bir ajan da sohbet penceresi olmadan çalışabilir.

Otonomi derecesi görev bazında tanımlanmalıdır. Ürün araştırmasında geniş hareket alanına sahip bir sistemin ödeme sırasında mutlaka kullanıcıya dönmesi mümkündür. Teslimat adresini değiştirme, yeni bir ödeme aracı ekleme veya daha pahalı bir alternatif seçme ayrı yetki gerektirebilir. Bu nedenle tek bir “otonom” etiketi, bütün satın alma yolculuğunu açıklamak için yetersizdir.

Alıcı ajanı ile satıcı ajanının çıkarları da aynı değildir. Alıcı taraf kullanıcının ihtiyacını, bütçesini ve tercihlerini temsil eder. Satıcı taraf ürün, stok, teklif ve hizmet koşullarını sunar. Aracı platform keşif ve etkileşim alanını yönetebilir. Başarılı bir mimari bu rolleri birbirine karıştırmadan, hangi bilginin kimden geldiğini ve hangi işlemin kimin yetkisiyle yapıldığını kaydeder.

Bu ayrım, kurumun yanlış başarı tanımı kullanmasını önler. Araştırma görevi için ürün bulmak yeterli olabilir. Sepet hazırlama görevi için ödemenin yapılmaması beklenen davranıştır. Kullanıcının bütçesi aşılmışsa satın almayı durdurmak, sistemin yetkisini doğru uyguladığını gösterir. Buna karşılık satın alma görevi açıkça yetkilendirilmişse yalnızca seçenek sunmak görevin tamamlandığı anlamına gelmez.

Hazırlığın kapsamı satın almanın sonuna kadar uzanır. Siparişin durumu, teslimat değişikliği, iptal ve iade gibi süreçler de kullanıcı ihtiyacının parçasıdır. Ticari ilişkiyi yalnızca ödeme anına indirgeyen tasarım, doğru sipariş oluşsa bile satış sonrası deneyimde sorun üretebilir.

3 Müşteri yolculuğunun yeniden düzenlenmesi

Geleneksel e-ticarette müşteri ürün sayfalarını inceler, filtreleri kullanır, seçenekleri karşılaştırır ve satın alma koşullarını kendisi bir araya getirir. AI destekli yolculukta bu işlerin bir kısmı bir asistana devredilebilir. Kullanıcı, farklı sitelerde aynı bilgiyi tekrar aramak yerine ihtiyacını, bütçesini ve kabul etmediği koşulları açıklar. Araştırma ve karşılaştırma yükü kısmen sisteme geçer.

Bu değişim doğrusal ve tek yönlü değildir. Müşteri bir asistanda araştırma yapıp mağazada ürünü deneyebilir; bir web sayfasında keşfettiği ürünü asistana karşılaştırabilir; öneriyi sohbet içinde alıp ödemeyi satıcının sitesinde tamamlayabilir. İşletmenin yalnızca tek bir arayüzdeki başarıyı ölçmesi, yolculuğun diğer bölümlerindeki kayıpları görünmez bırakabilir.

İhtiyaç ifadesi yeni yolculuğun önemli bir veri kaynağıdır. “İyi bir kulaklık” gibi belirsiz taleple “gürültülü ofiste görüşme yapabileceğim, mevcut bilgisayarımla uyumlu ve iki gün içinde teslim edilecek kulaklık” aynı sorgu değildir. İkinci talep teknik uygunluk, teslimat ve kullanım bağlamını birlikte içerir. Katalog bu ayrıntıları taşımıyorsa sistemin daha uzun açıklama üretmesi bilgi eksikliğini çözmez.

Karşılaştırmanın dayandığı bilgi de genişler. Fiyatın yanında uyumluluk, stok, ürün durumu, garanti, satıcı geçmişi, teslimat seçenekleri ve iade koşulları önem kazanabilir. Hangi ölçütün belirleyici olduğu kullanıcıya göre değişir. Ajanların her zaman en ucuz ürünü seçeceğini varsaymak, müşterinin kalite, hizmet veya risk tercihini göz ardı eder.

İşletme için yeni temas noktaları ürün feed’i, izinli katalog API’si, araç yanıtı, teklif kaydı ve kullanıcıya devir ekranı olabilir. Bunların her biri müşteri deneyimi üretir. Anlaşılır bir ürün açıklaması kadar, bir hata yanıtının doğru biçimde “stok yok” veya “teslimat adresi gerekli” demesi de görevin devam etmesini etkiler.

Yolculuğu tasarlarken üç tür kayıp ayrılmalıdır. Bilgi kaybında müşteri veya ajan gerekli niteliği öğrenemez. Bağlam kaybında seçilen ürün, varyant veya şartlar kanallar arasında taşınamaz. Yetki kaybında sistem doğru işlemi yapabilecek olsa bile geçerli izin bulunmadığı için ilerleyemez. Her kayıp farklı bir müdahale gerektirir.

Birinci sorun ürün veri ekibinin, ikinci sorun deneyim ve entegrasyon ekiplerinin, üçüncü sorun ise kimlik ve ödeme tasarımının gündemidir. Webtures’ın araştırma yaklaşımı, genel bir dönüşüm oranını bu daha açıklayıcı parçalara ayırarak hangi değişikliğin neden gerekli olduğunu göstermelidir.

İnsan deneyimi önemini korur. Kullanıcı seçimi denetlemek, bir koşulu değiştirmek veya işlemi devralmak isteyebilir. Ajanla başlayan yolculuğun insana anlaşılır biçimde devam edebilmesi, farklı kullanım biçimlerini aynı ticaret altyapısında bir arada tutar.

4 Ticari değerin ve marka tercihinin değişen temeli

Agentic Commerce yatırımı yalnızca yeni bir trafik kaynağı edinme kararı değildir. İşletmenin ürününü nasıl tanımladığı, ticari sözünü nasıl verdiği ve bu sözü nasıl yerine getirdiği daha doğrudan karşılaştırılabilir hale gelebilir. Veri kalitesi ve operasyonel güvenilirlik, pazarlama anlatısıyla birlikte değerlendirilmelidir.

Marka değerinin ortadan kalktığı varsayımı bu dönüşümü açıklamakta yetersizdir. Müşteriler belirli markaları kalite, servis, tasarım, geçmiş deneyim veya güven nedeniyle tercih edebilir. Kullanıcının ajanına ilettiği marka tercihi de kararın bir parçasıdır. Bununla birlikte markanın hangi ihtiyaca neden uygun olduğunu açık ve doğrulanabilir biçimde anlatması daha fazla önem kazanır.

Örneğin uzun garanti, hızlı servis veya kolay iade önemli bir değer önerisiyse bu söz yalnızca kampanya metninde kalmamalıdır. Hangi ürünleri, hangi bölgeleri ve hangi koşulları kapsadığı anlaşılmalıdır. Ajanın bu bilgiyi kullanıcı talebiyle ilişkilendirebilmesi için içerik, veri ve operasyon arasındaki tutarlılık gerekir.

İşletmenin kendi verisinde bulunmayan bir üstünlüğü ajanın güvenilir biçimde açıklaması beklenemez. Benzer şekilde yapılandırılmış veri içine eklenen doğrulanmamış bir özellik, ürünü gerçekten o özelliğe sahip hale getirmez. Verinin düzenli sunulması ile iddianın doğruluğu ayrı konulardır. Araştırma her ikisini birlikte ele almalıdır.

Ticari değerin üç düzeyi vardır. Operasyonel değer, yanlış ürün ve hatalı sepet gibi sorunların azalmasıdır. Müşteri değeri, doğru seçeneğe daha az sürtünmeyle ulaşılmasıdır. Finansal değer ise bunların satış, katkı, iade veya destek maliyetine etkisidir. İlk iki düzeydeki iyileşme otomatik olarak üçüncü düzeyde aynı büyüklükte sonuç üretmez.

Pazar tahminleri bu nedenle yatırımın tek gerekçesi olmamalıdır. AI tarafından araştırılan satış, AI yönlendirmesiyle başlayan ziyaret, sohbet içinde tamamlanan ödeme ve tam otonom sipariş farklı büyüklüklerdir. Farklı tanımlarla üretilen tahminleri tek grafikte aynı pazarın ölçümü gibi sunmak yanıltıcıdır. Yönetimin esas izlemesi gereken, seçilen görevin kendi işinde hangi sonucu değiştirdiğidir.

Webtures için araştırma değeri, büyük bir gelecek rakamını tekrar etmekten çok bu bağlantıyı kurmaktır. Hangi veri kusuru müşteri seçimini bozuyor? Hangi işlem engeli destek maliyetini artırıyor? Hangi yetenek daha geniş kanallara geçiş için gerekli? Bu sorular ticari önem ile teknik önem arasında ortak bir dil oluşturur.

Bir diğer değer alanı teknoloji seçme esnekliğidir. Ürün verisinin kanallardan bağımsız tutulması, işlem mantığının açık sözleşmelerle sunulması ve kayıtların taşınabilir olması tek bir platforma bağımlılığı azaltabilir. Bu esneklik bir anda bütün kanallara bağlanmakla değil, çekirdek ticari kuralları kontrol altında tutmakla sağlanır.

5 Platformlara göre keşif ve işlem yolları

Agentic Commerce tek bir ürün veya tek bir satış kanalı değildir. Aynı platform içinde ürün araştırması, mağazaya yönlendirme ve doğrudan checkout farklı uygunluk koşullarına sahip olabilir. Bir özelliğin kamuya duyurulması, her satıcı hesabında ve her ülkede etkin olduğu anlamına gelmez. Hazırlık kararı hesap ve görev düzeyinde verilmelidir.

OpenAI ürün keşfi için sunulan katalog bağlantıları ile checkout etkinleştirmesi ayrı değerlendirilmelidir. Ürün feed’inin işlenmesi, satıcının bütün satın alma akışlarına kabul edildiğini göstermez. Shopify üzerinden ChatGPT’de başlayan bir alışveriş, satıcının kendi checkout’unda devam edebilir. Bu durumda kritik test, ürün ve sepet bağlamının doğru taşınmasıdır.

Google UCP uygulamasında da açık teknik spesifikasyon ile Google yüzeylerindeki canlı destek aynı kapsam değildir. Platformun satıcı kabulü, hesap hazırlığı, ürün uygunluğu ve teknik onayı ayrıca gerekir. Bir geliştirici dokümanındaki yetenek, belirli bir müşteri hesabında sınanmadan hazır kabul edilmemelidir.

Shopify’ın Google AI Mode ve Gemini doğrudan checkout belgesindeki ABD merkezli mağaza ve ABD müşterisine satış koşulları, Türkiye merkezli satıcıya aynı akışın vaat edilemeyeceğini gösterir. Keşif ve mağazaya yönlendirme farklı bir yol olarak değerlendirilebilir. Bu nedenle ülke kapsamı tek bir “destekleniyor” işaretiyle gösterilmemelidir.

Bir kanal için en az beş ayrı kayıt tutulmalıdır: satıcının kuruluş ve hesap ülkesi, alıcının bulunduğu ülke, teslimat bölgesi, ürün kategorisi ve hedef işlem. Buna hesap kabul durumu ve kullanılan sürüm eklenir. Ödeme sağlayıcısının ve para biriminin uygunluğu da ticari akışın ayrı bileşenleridir.

Tarayıcı ajanları, API kullanan ajanlar ve satıcıya özel entegrasyonlar aynı şekilde ölçülmez. Bazı akışlar ekran görüntüsü veya erişilebilirlik bilgisiyle çalışabilir. Bazıları yapılandırılmış araç yanıtına dayanır. Bu nedenle “ajanlar web arayüzünü kullanmaz” veya “bir protokol bütün arayüz sorunlarını çözer” varsayımları tasarım kararına temel olmamalıdır.

Platform değişiklikleri için düzenli gözden geçirme gerekir. Yeni bir özellik, mevcut müşteriye hemen açılmak yerine test kapsamına alınır. Eski bir özelliğin kaldırılması veya uygunluk şartlarının değişmesi de müşteri görevlerini etkileyebilir. Kanal envanteri, bir kez hazırlanan tanıtım tablosu değil, işletilen teknik kayıt olmalıdır.

6 Dört ticari yeteneği birlikte değerlendirmek

Webtures yaklaşımında hazırlığın dışarıdan anlaşılır anlatımı dört yetenek üzerinden kurulabilir: keşfedilebilirlik, anlaşılabilirlik, güvenilirlik ve işlem yapılabilirlik. Bu yapı bir sertifikasyon standardı değildir. Yönetimin karmaşık teknik bulguları müşteri yolculuğuyla ilişkilendirmesini sağlayan bir değerlendirme çerçevesidir.

Keşfedilebilirlik, ürün veya satıcının ilgili talepte erişilebilir bir seçenek haline gelmesidir. Ürünün bir feed’de bulunması, ihtiyaç temelli bir araştırmada mutlaka seçileceği anlamına gelmez. Kanalın ürün bilgisine erişmesi, doğru ürünü eşleştirmesi ve ilgili seçenekler arasında değerlendirmesi ayrı gözlemler olarak tutulmalıdır.

Anlaşılabilirlik, ürünün kullanıcı koşullarıyla doğru ilişkilendirilmesidir. Model, ürünün ne olduğunu, hangi varyantın satıldığını ve hangi kısıtları taşıdığını ayırt edebilmelidir. Eksik bilgi üretken bir cevapla tamamlanmamalıdır. Belirsizlik halinde açıklama istemek, yanlış kesinlik üretmekten daha doğru bir sonuçtur.

Güvenilirlik, kullanılan bilginin yetkili kayıtla ve işlem anındaki koşullarla tutarlı olmasıdır. Sayfada görünen fiyatın feed’deki fiyatla aynı olması tek başına yeterli değildir; iki değer de güncelliğini yitirmiş olabilir. Doğruluk, güncellik ve ticari uygulanabilirlik birlikte ele alınmalıdır.

İşlem yapılabilirlik, izin verilen hedefin gerçekten oluşturulmasıdır. Bu hedef karşılaştırma listesi, teklif talebi, test sepeti, onaylı sipariş veya belirli bir satış sonrası işlem olabilir. Görevden beklenmeyen daha ileri bir eylem, başarılı otomasyon diye değerlendirilmez. Fazladan yetki kullanmak bir kalite kusurudur.

Bu yetenekler mantıksal olarak ilişkilidir fakat bütün müşteriler için tek yönlü bir merdiven oluşturmaz. Bir marka sınırlı bir kurumsal kanalda güvenilir sipariş API’sine sahip olabilirken genel AI keşfinde zayıf olabilir. Başka bir marka sık önerilebilir fakat stok verisi tutarsız olabilir. Her ikisine aynı “orta seviye” etiketi vermek gerekli uygulamayı belirsizleştirir.

Dört yeteneğin her biri için kapsam ve kanıt gösterilmelidir. Keşif hangi dil ve sorgularda değerlendirildi? Anlaşılabilirlik kaç varyantta kontrol edildi? Güncellik hangi alanlarda ölçüldü? İşlem hangi ortamda hangi sonuca kadar yürütüldü? Bu sorular, sunumdaki olumlu bir anlatımı denetlenebilir bir rapora dönüştürür.

Yönetim ekranında dört yeteneğin yanında açık engeller, test tarihi ve sonraki adım bulunmalıdır. Bir alanın yeterli görülmesi, diğerlerinin de hazır olduğu izlenimini vermemelidir. Raporun ticari değeri, tek bakışta hangi ilerlemenin mümkün olduğunu ve hangi koşulun önce çözülmesi gerektiğini gösterebilmesidir.

7 Sekiz denetim alanıyla teknik derinlik

Dört ticari yeteneğin altında daha ayrıntılı bir teknik ve operasyonel değerlendirme gerekir. Bu raporda önerdiğimiz çalışma modeli sekiz denetim alanını birlikte kullanır. Bu alanlar aynı puanın alt başlıkları olmak zorunda değildir; her biri farklı bir sorumluyu, kanıtı ve düzeltme türünü tanımlar.

Kanal ve yetki uygunluğu, işletmenin hedeflenen işlemi ilgili platformda yapıp yapamayacağını inceler. Ürün keşfi ve kimliği, kullanıcı talebinin doğru satıcı, ürün ailesi ve varyantla eşleşmesine bakar. Veri doğruluğu ve güncelliği, bu eşleşmede kullanılan bilgilerin güvenilirliğini değerlendirir. Teklif ve ticari koşullar, fiyatın ve teslimat sözünün gerçekten uygulanabilir olmasını ele alır.

Görev ve işlem yürütme alanı, tanımlanan hedefin sistem kayıtlarında oluşup oluşmadığını kontrol eder. Güvenlik ve kullanıcı kontrolü, yetkinin sınırlarını ve gerektiğinde durma davranışını inceler. Ölçüm ve uzlaştırma, görülen sonucun ödeme ve sipariş gibi yetkili kayıtlarla eşleşmesini sağlar. İşletim ve iyileştirme ise değişikliklerden sonra kalitenin sürdürülmesini kapsar.

Bu ayrım, sorunun yanlış ekibe yönlendirilmesini azaltır. Ürün verisinde bulunmayan bir özellik için deneyim ekibinden daha açıklayıcı hata metni istemek tek başına çözüm değildir. Ödeme yetkisi bulunmayan bir akışı daha hızlı hale getirmek de işlem yapılabilirliği artırmaz. Önce sorunun ait olduğu alan ve bağımlılıklar belirlenmelidir.

Bir bulgu birden fazla alanı etkileyebilir. Yanlış stok hem veri güncelliği hem sepet yürütme sorunudur. Bu durumda tekil bulgu kaydı korunmalı, ilgili alanlara bağlantı verilmelidir. Aynı kusuru farklı başlıklarda yeniden saymak toplam riskin olduğundan büyük görünmesine neden olabilir.

Sekiz alanın değerlendirmesi, kanıt düzeyiyle birlikte sunulur. Belgeden görülen bir yetenek ile sandbox’ta çalışan bir akış aynı kesinlikte değildir. Üretim ortamında sınırlı bir ürün kümesinde doğrulama yapılması da bütün katalog için genellenemez. Teknik derinlik, kapsamı büyütmek kadar sonucu doğru sınırlandırmayı gerektirir.

8 İlk uygulama görevini seçmek

Başlangıç görevi, hem ticari değer üretebilecek hem sonucu doğrulanabilecek bir ihtiyaçtan seçilmelidir. Çok geniş bir görev ilk pilotta farklı hata nedenlerini birbirine karıştırır. Aşırı basit bir görev ise başarıyla çalışsa bile yatırım kararına katkı sağlamaz. Uygun denge, sınırlı kapsam içinde gerçek iş karmaşıklığını korumaktır.

Görev seçiminde müşteri ihtiyacının sıklığı, yanlış sonucun etkisi, verinin erişilebilirliği, mevcut entegrasyonlar ve doğrulama maliyeti birlikte değerlendirilir. Ürün özellikleri iyi tanımlanmış bir kategoride doğru varyantla sepet hazırlamak iyi bir başlangıç olabilir. Karmaşık B2B satışta hedef doğrudan sipariş yerine teknik koşulları tamamlanmış teklif talebi olabilir.

Örneğin uyumluluk bilgisi bulunan elektronik aksesuarlar için pilot, belirli bir bilgisayar modeline uygun seçenekleri bulup toplam bütçe içinde test sepeti hazırlamak olarak tanımlanabilir. Kullanıcının cihaz modeli belirsizse soru sormak beklenen davranıştır. Sistem yalnızca ürün adında benzer sözcük geçtiği için aksesuarı uyumlu kabul etmemelidir.

Giyim kategorisinde başlangıç, beden ve renk varyantının doğru seçilmesiyle iade koşullarının anlaşılmasına odaklanabilir. Görevin amacı ürünün kullanıcıya fiziksel olarak tam uyacağını garanti etmek değildir. Ürün verisinden çıkarılabilecek sonuçla kişinin deneyimine bağlı belirsizlik ayrı tutulmalıdır.

İlk kapsamda ödeme işlemini sona bırakmak bazı kurumlarda uygun olabilir. Bunun gerekçesi teknolojiyi ertelemek değil, daha önceki veri ve teklif sorunlarını düşük etkiyle ortaya çıkarmaktır. Ödeme yeteneği ana ticari hedefse ödeme sağlayıcısının test ortamı ve müşteri onayıyla kapsam baştan buna göre hazırlanır.

Pilotun kabul koşulları sonuç görülmeden yazılmalıdır. Hangi hata akışı durduracak? Hangi belirsizlikte kullanıcıya dönülecek? Hangi kayıt başarı kanıtı olacak? En fazla kaç deneme yapılacak? Birim maliyetin hangi sınırda değerlendirilmesi gerekecek? Bu sorulara verilen yanıtlar daha sonra karşılaştırma yapmayı mümkün kılar.

İlk görevin başarılı olması kapsamın hemen bütün kataloğa açılmasını gerektirmez. Yeni ürün türü, ülke, kampanya veya ödeme yöntemi yeni koşul ekler. Genişleme, benzerlik varsayımıyla değil ek testlerle desteklenmelidir. Böylece kurum küçük bir başlangıçtan öğrenir, ancak küçük örneklemin sonucunu büyük bir hazırlık iddiasına dönüştürmez.

Webtures’ın rolü, seçilen görevin müşteri ihtiyacıyla teknik çalışma arasında anlaşılır bir bağ kurmasını sağlamaktır. Bu bağ net olduğunda denetim kapsamı, uygulama bütçesi ve başarı değerlendirmesi aynı hedefe yönelir.

9 Mimari ve sistem sınırları

Agentic Commerce hazırlığında mimari, müşterinin talebinin kurum içinde hangi sistemlerden geçerek ticari sonuca dönüştüğünü açıklamalıdır. Ürün hakkında bilgi veren sistem, satılabilir stoğu belirleyen sistem ve siparişi kabul eden sistem farklı olabilir. Bu ayrım görünür olmadığında, ajan doğru görünen bir yanıtı yanlış bir işlemle tamamlayabilir. Bu raporda önerdiğimiz inceleme, teknoloji adlarından önce bu karar noktalarının ve sorumlulukların haritalanmasıyla başlar.

Bir işletmede ürünün teknik özellikleri ürün bilgi yönetiminde, fiyatı kampanya motorunda, stok durumu depo yönetiminde, teslimat tahmini lojistik servisinde tutulabilir. Bütün alanları tek bir veritabanına taşımak her zaman gerekli veya uygulanabilir değildir. Esas ihtiyaç, her alan için yetkili kaynağın belirlenmesi ve çelişki halinde hangi kaydın esas alınacağının açıklanmasıdır. “Tek doğruluk kaynağı” yaklaşımı bu nedenle tek yazılım satın alma kararı olarak değil, veri sahipliği ve karar düzeni olarak ele alınmalıdır.

Önerilen mimaride keşif, değerlendirme ve işlem katmanları birbirine bağlı fakat ayrı yetkilere sahiptir. Keşif katmanı ürünün bulunmasını ve anlaşılmasını sağlar. Değerlendirme katmanı adres, miktar, müşteri uygunluğu ve zaman gibi koşullarla geçerli bir teklif üretir. İşlem katmanı ise izin verilen değişikliği yürütür. Katalog okuyan bir araç, aynı erişim anahtarıyla kampanya değiştirememeli veya sipariş iptal edememelidir. Bu ayrım, işlevleri geliştirmeyi ve hatanın etkisini sınırlamayı kolaylaştırır.

Arayüz ve API yolları birlikte değerlendirilmelidir. Bazı ajanlar mağazayı tarayıcı üzerinden kullanırken bazıları yapılandırılmış araçlara erişebilir; başka akışlar müşteriyi mevcut checkout'a devreder. Kurumun yalnızca bir yolu desteklemesi mümkündür. Raporda hangi yolun hangi müşteri görevini karşıladığı yazılmalıdır. API bulunması tarayıcı deneyimini önemsizleştirmez; iyi bir arayüz de dış sistemler için işlem API'si bulunduğunu göstermez. Her yolun veri kaynağı ve ticari sonuçları tutarlı olmalıdır.

Entegrasyon katmanı mevcut sistemlerle ajan arasında kontrollü bir çeviri görevi üstlenebilir. Dışarıya sunulan ürün sorgulama veya sepet hazırlama işlemi, içeride birden fazla servisi çağırabilir. Bu katmanda veri dönüştürme, kimlik eşleme, izin kontrolü ve hata sınıflandırması açık tanımlanmalıdır. Ajanın serbest metinli cevabı doğrudan fiyat veya stok kaydına dönüştürülmemelidir. Ticari kuralların uygulanması, işletmenin denetlenebilir uygulama mantığında kalmalıdır.

Sistem sınırlarının bir diğer boyutu müşteriye ve iş ortaklarına ait verilerdir. Katalog servisinin tüm müşterilerin geçmiş alışverişlerini bilmesi gerekmeyebilir. Kişiselleştirme için gereken bilgi, ilgili görevin amacı ve erişim kapsamıyla sınırlandırılmalıdır. Test ortamının üretim veritabanına yazma ihtimali, ortak kullanılan erişim anahtarları ve birbirine karışan müşteri hesapları mimari incelemede özellikle görünür hale getirilmelidir. Erişim hakkı, yalnızca bağlantının teknik olarak kurulabildiği gerekçesiyle genişletilmemelidir.

Webtures'ın önerdiği mimari teslimat, kısa bir sistem haritasını veri sahipleri ve işlem sınırlarıyla birleştirir. Her kritik bağlantı için giriş, çıktı, yetkili sistem, hata halinde davranış ve sorumlu ekip belirtilir. Eksik bağlantı ile bilinçli biçimde kapalı tutulan bağlantı aynı sorun gibi raporlanmaz. Böylece geliştirme programı bütün altyapıyı değiştirme baskısı yaratmadan, ilk müşteri görevinin güvenilir çalışması için gereken değişikliklere odaklanabilir.

10 Ajan erişimi ve doğrulanabilir kimlik

Ajan erişimi, gelen bütün otomatik isteklere izin vermek anlamına gelmez. İşletmenin hangi içeriğini hangi amaçla erişilebilir kılacağı, hangi işlemler için kimlik ve ek yetki arayacağı belirlenmelidir. Arama amacıyla içerik toplayan sistem, kullanıcı talebiyle bir sayfa açan araç ve sipariş vermek isteyen ajan farklı davranışlar gösterir. Webtures'ın önerdiği erişim denetimi, bunları tek bir “AI bot” grubunda toplamak yerine işlev ve izin üzerinden ayırır.

İlk kontrol katmanları alan adı, ağ, içerik dağıtım ağı, web uygulama güvenlik duvarı ve uygulamanın kendisidir. Ürün sayfası herkese açık olsa bile belirli istekler ek doğrulama ekranında kalabilir veya hız sınırına takılabilir. Bulguda engelin hangi katmanda oluştuğu yazılmalıdır. Bir sayfanın belirli bir araçla açılmaması, bütün yapay zekâ sistemlerinin o markaya erişemediğini göstermez. İzinli farklı erişim yolları ayrı ayrı incelenmelidir.

Robots.txt tarama tercihlerini ifade eder; özel bilgiye erişim yetkisi veren bir güvenlik mekanizması değildir. Ticari işlem yetkisi de bu dosyada yönetilmez. Google-Extended ayrıca bağımsız bir HTTP istek kullanıcı aracısı değildir; belirli içerik kullanım tercihlerini yöneten bir robots.txt ürün belirtecidir. Sunucu günlüklerinde Google-Extended adlı ayrı bir bot aramak veya bu belirteci açmayı Google Arama görünürlüğünün koşulu saymak doğru değildir. Google Arama için ilgili tarama ve indeksleme kontrolleri kendi kapsamlarıyla değerlendirilmelidir.

İstek üzerinde bir bot adı yazması, o isteğin gerçekten belirtilen sağlayıcıdan geldiğini kanıtlamaz. Sağlayıcının desteklediği doğrulama yöntemine göre yayımlanmış ağ bilgileri, uygun DNS doğrulaması veya kriptografik istek imzaları değerlendirilebilir. Doğrulama yöntemi ve son kontrol tarihi kayda alınmalıdır. Kimliği doğrulanmış bir ajan dahi her işlem için yetkili olmayabilir. İstek sahibinin tanınması ile müşterinin hesabında işlem yapabilmesi iki ayrı karar olarak tutulmalıdır.

Kriptografik imza kullanan yaklaşımlar, desteklenen entegrasyonlarda istek kökeni ve bütünlüğü için ek kanıt sağlayabilir. Buna karşılık imzalı her isteği otomatik olarak güvenli kabul etmek yeterli değildir. Anahtarın geçerliliği, imzanın kapsadığı alanlar, zaman koşulları ve uygulamanın yetki sınırları kontrol edilmelidir. Kullanılan sağlayıcının ürün durumu ve desteklediği standart sürümü ayrıca doğrulanır. Henüz taslak durumundaki bir yaklaşım, tüm internetin ortak ve zorunlu kimlik altyapısı gibi sunulmamalıdır.

Güvenlik duvarını bütünüyle kapatmak yerine, iş amacıyla gerekli uç noktalar için kontrollü politikalar önerilir. Salt okunur katalog erişimi ile sepet oluşturan veya hesap bilgisi isteyen çağrılar aynı limitleri paylaşmak zorunda değildir. Trafik artışında sınırlandırma, anlaşılır hata yanıtı ve makul yeniden deneme davranışı tasarlanmalıdır. Güvenlik önlemi nedeniyle kullanıcıya devir gerekiyorsa bu, her durumda teknik başarısızlık sayılmaz; beklenen akışın bir parçası olabilir.

Denetimin çıktısı, izin verilen amaçları ve yöntemleri gösteren bir erişim kaydı olmalıdır. Bu kayıtta doğrulanmış erişim, yalnızca gözlenmiş trafik, reddedilmiş istek ve kapsam dışında bırakılan yol ayrılır. Müşteri hesabı, yönetim arayüzü ve ödeme işlemleri için gerekli izinler ayrıca belirtilir. Böylece görünürlük hedefi, kurumun veri güvenliği ve hizmet sürekliliğiyle birlikte yönetilir.

11 Semantik HTML ve erişilebilir deneyim

Tarayıcı üzerinden çalışan ajanlar için web sayfasının anlamı, yalnızca ekrandaki görüntüden oluşmaz. Başlıklar, alan adları, düğmelerin işlevleri, seçili seçenekler ve hata mesajları görev akışının anlaşılmasını etkiler. İnsanların kullandığı arayüzün açık ve tutarlı olması, ajanların da daha doğru çalışmasına yardımcı olabilir. Ancak erişilebilirlik düzeyini doğrudan bütün ajanlarla uyumluluk garantisi gibi sunmak doğru değildir; gerçek görev başarısı ayrıca test edilmelidir.

Semantik HTML, bir kontrolün ne yaptığını yapısında açıklar. Bir işlem düğmesinin gerçek düğme öğesi olması, form alanlarının anlaşılır etiketler taşıması ve seçenek gruplarının ilişkisinin belirtilmesi sağlam bir başlangıçtır. ARIA rolleri gerekli yerlerde anlamı tamamlayabilir; fakat tek başına klavye davranışı veya doğru etkileşim oluşturmaz. Görsel olarak düğmeye benzeyen bir öğeye yalnızca rol eklemek, onu kendiliğinden güvenilir bir işlem kontrolüne dönüştürmez.

Webtures'ın önerdiği inceleme görünür etiket ile erişilebilir adın aynı görevi anlatıp anlatmadığını kontrol eder. “Devam” düğmesinin ödeme başlatması, seçili bedenin yalnızca renkle belirtilmesi veya hata mesajının formdan uzakta kalması görev yorumunu zorlaştırabilir. Form alanları, zorunluluk bilgisi ve düzeltme mesajları birlikte ele alınmalıdır. Dinamik değişikliklerin kullanıcıya ve ilgili yardımcı teknolojilere doğru biçimde bildirilmesi de kontrol kapsamına alınır.

Temsili bir ayakkabı mağazasında kullanıcı 43 numarayı seçtiğinde düğmenin rengi değişiyor, ancak sayfanın erişilebilir durumunda önceki numara kalıyor olsun. Ajan sonraki adımda yanlış varyantı sepete ekleyebilir. Bu örnekte çözüm, ajana daha uzun talimat vermekle sınırlı değildir. Seçimin programatik durumunun, görünen ürün bilgisinin ve sepet isteğinin aynı varyantı göstermesi gerekir. Test hem seçimi hem oluşan sepet satırını kontrol etmelidir; yalnızca düğmeye tıklanması başarı sayılmamalıdır.

JavaScript kullanımı kendi başına bir kusur değildir. Asıl soru, hedef erişim yolunun kritik bilgiyi hangi koşullarda okuyabildiğidir. Sunucu tarafında HTML üretimi veya ön üretim bazı içeriklerin ilk yanıtta bulunmasını kolaylaştırabilir. Bununla birlikte sunucu tarafında üretim, eski fiyatı güncel hale getirmez ve her mağazada zorunlu çözüm değildir. İlk belge, işlenmiş sayfa ve kullanıcı etkileşimi sonrasındaki durum ayrı incelenmeli; tercih, ölçülen soruna göre yapılmalıdır.

Sayfa kararlılığı da işlem güvenilirliğinin bir parçasıdır. Yükleme sırasında yer değiştiren kontroller, beklenmedik açılır pencereler, otomatik kaydırmalar ve belirsiz bekleme durumları hem insanları hem tarayıcı ajanlarını etkileyebilir. Ticari akışın gerekli onayları korunurken gereksiz kesintiler azaltılmalıdır. Misafir alışverişi iş modeline uygunsa değerlendirilebilir; fakat zorunlu kimlik doğrulamasının yalnızca ajan daha kolay ilerlesin diye kaldırılması önerilmemelidir.

Arayüz denetimi masaüstü görüntüsüyle bitmemelidir. Hedef akışın çalıştığı mobil görünüm, uygulama içi tarayıcı, dil ve oturum durumu da kapsamda tanımlanır. Ödeme sağlayıcısına devirde ürün, toplam ve kullanıcıya sunulan bilgiler korunmalıdır. Her geliştirme için kabul ölçütü somut olmalıdır: kontrolün adı anlaşılır, seçilen varyant doğru, hata düzeltilebilir ve kullanıcı gerekli noktada kontrolü geri alabilir. Görsel yenileme ile işlevsel iyileştirme bu ölçütlerle ayrılır.

12 Ürün kimliği varyant ve katalog

Ajanın doğru ürünü bulması, benzer başlıklı bir sayfaya ulaşmasından daha güçlü bir koşuldur. Ürün ailesi, satın alınabilir varyant, satıcının teklifi ve teslimat seçeneği birbirinden ayrılmalıdır. Aynı modelin farklı kapasitesi veya ambalaj adedi farklı bir ticari nesne olabilir. Hazırlık değerlendirmesinde katalog, içerik listesi olarak değil; müşterinin talebini satın alınabilir ürüne bağlayan kimlik düzeni olarak incelenmelidir.

İlk çalışma ürün kimlikleri arasındaki eşlemedir. Kurum içi kayıt, mağaza SKU'su, üretici kodu, varsa GTIN, feed kimliği ve checkout satırında kullanılan kimlik birlikte ele alınır. Bu değerlerin aynı olması zorunlu değildir; fakat aralarındaki dönüşüm açık ve izlenebilir olmalıdır. Ürün silinip yeniden oluşturulduğunda eski bağlantıların ne göstereceği, başka ürünlere yanlış eşleme olup olmayacağı ve geçmiş siparişlerin nasıl korunacağı belirlenmelidir.

Varyant modeli yalnızca renk ve bedenden oluşmaz. Kapasite, bağlantı tipi, materyal, paket miktarı veya belirli bir teknik özellik satın alma kararını değiştirebilir. Satın alınamayan bir seçenek ile geçici olarak stokta olmayan bir seçenek farklı durumlardır. Bir ürün ailesinin stokta olması, bütün varyantlarının alınabileceği anlamına gelmez. Veri modelinin bu ayrımları açıkça taşıması, ajanın belirsizliği kendi varsayımlarıyla doldurmasını azaltır.

Her ürüne GTIN, MPN ve SKU alanlarının tamamını zorla doldurmak doğru değildir. Üretici tarafından verilmiş gerçek kimlikler kullanılmalı; olmayan küresel kimlikler uydurulmamalıdır. El yapımı veya özel üretim gibi bazı ürünlerde küresel ürün tanımlayıcısı bulunmayabilir. Hedef kanalın bu durum için öngördüğü alan ve kurallar uygulanır. Ürün kimliğini doğrulayamamakla ürünün gerçekte böyle bir kimliğe sahip olmaması aynı veri durumu sayılmamalıdır.

Temsili bir aksesuar kataloğunda aynı adaptörün tekli ve üçlü paketleri benzer adlarla yayımlanmış olsun. Ajan en düşük görünen fiyatı seçerken paket miktarını okumazsa birim fiyat karşılaştırması hatalı olur. Çözüm, paket bilgisini yalnızca açıklama sonuna eklemek değildir. Satılabilir kaydın miktarı, birimi, fiyatı ve paket içeriği birlikte tanımlanmalı; sepet satırının aynı ürünü temsil ettiği doğrulanmalıdır. Üçlü paket kimliği tekli ürünün kimliğiyle gelişigüzel değiştirilmemelidir.

Katalog niteliği, alanların doluluk oranıyla tek başına ölçülemez. Yanlış veya tahmin edilmiş bilgiyle doldurulan alan, boş bırakılmış alandan daha ağır sonuç yaratabilir. Bir ürün özelliğinin dayanağı, kapsamı ve doğrulama durumu tutulmalıdır. Uyumluluk bilgileri kategoriye göre tasarlanır: elektronik üründe cihaz modeli, tekstilde ölçü standardı, yedek parçada üretim yılı aralığı önem kazanabilir. Doğal dildeki kullanım açıklamaları, bu nesnel niteliklerle tutarlı kalmalıdır.

Webtures'ın önerdiği katalog teslimi, kimlik eşleme tablosunu kritik nitelik sözlüğüyle birleştirir. Önce satın alma kararını değiştiren alanlar tamamlanır; ardından açıklayıcı zenginleştirme değerlendirilir. Ürünler yalnızca satış hacmine göre seçilmez; varyant karmaşıklığı, stok değişkenliği ve yanlış eşleşmenin maliyeti de örnekleme dahil edilir. Böylece katalog çalışması binlerce kaydı yüzeysel olarak düzenlemek yerine, görev başarısını etkileyen yapısal eksikleri ortaya çıkarır.

13 Yapılandırılmış veri ve içerik

Yapılandırılmış veri, ürün ve ticari koşulların belirli bir sözlükle ifade edilmesini sağlar. İçeriğin yerine geçen ayrı bir gerçeklik değildir. Ürün sayfası, katalog ve yapılandırılmış veri aynı ticari bilgiyi anlatmalıdır. Kullanıcıya gösterilmeyen avantajları yalnızca makineye sunmak veya eski fiyatı şemada bırakmak güvenilirlik sorununa dönüşür. Webtures yaklaşımında amaç, daha fazla alan üretmekten önce doğru bilgiyi doğru nesneyle ilişkilendirmektir.

Varyantlı ürünlerde ProductGroup, aynı temel ürünün belirli özelliklerle ayrılan ürünlerini gruplamak için kullanılabilir. Bu grup hasVariant ilişkisiyle ayrı Product kayıtlarına bağlanabilir; ters ilişki de uygun biçimde kurulabilir. Satın alınabilir varyanta ilişkin teklif, fiyat ve bulunabilirlik kendi bağlamıyla ele alınır. Bütün varyantları ana Product altında gelişigüzel hasVariant alanına yerleştirmek, kullanılan yapının semantiğini doğru yansıtmaz. Sayfanın tek veya çok URL'li olması da uygulama tasarımını etkiler.

Offer, satıcının belirli ticari teklifini açıklarken ürünün kendisinden ayrılmalıdır. Fiyatın para birimi, geçerlilik koşulları, ürün durumu ve bulunabilirliği tutarlı olmalıdır. Kargo ve iade bilgileri işletme genelindeki politikaya veya uygun durumlarda ürünün özel koşullarına bağlanabilir. Her ürün için bütün politika metnini tekrar kopyalamak, sonraki değişikliklerde tutarsızlık üretebilir. Ortak kurallar ile ürün istisnalarının nasıl yönetildiği açık bir içerik ve veri kararıdır.

Şema sözlüğünde bir özelliğin bulunması, bütün arama ve alışveriş platformlarının o özelliği kullandığını göstermez. Google'ın desteklediği ürün gösterimi ile başka bir platformun feed sözleşmesi ayrı kontrol edilmelidir. Biçimsel doğrulayıcıdan geçmek de yanıt motorunda önerilme garantisi değildir. Teknik inceleme üç soruyu ayırır: yapı doğru mu, içindeki bilgi doğru mu ve hedef kanal bu bilgiyi hangi amaçla destekliyor? Bu ayrım yatırım önceliğini daha gerçekçi hale getirir.

İçerik tarafında ürünün hangi ihtiyacı karşıladığı, hangi koşullarda uygun olmadığı ve hangi bilginin belirsiz kaldığı açık yazılmalıdır. Birim, ölçü sistemi, model yılı, bakım koşulu veya paket dışı aksesuar gibi ayrıntılar satın alma hatalarını azaltabilir. Ajanların yalnızca şema okuyup doğal dili kullanmadığı varsayılmamalıdır. Açıklayıcı metin ve yapılandırılmış nitelikler birlikte çalışmalı; pazarlama ifadesi teknik garantiye dönüştürülmemelidir. Doğrulanmamış bir özellik için daha güçlü sıfatlar kullanmak veri eksikliğini çözmez.

Llms.txt veya ai.txt gibi dosyalar evrensel satın alma ön koşulu olarak tanımlanmamalıdır. Belirli sistemlerde dokümantasyon keşfine yardımcı bir yöntem seçilebilir; buna rağmen dosyanın varlığı bütün ajanların onu okuyacağını kanıtlamaz. Google Arama görünürlüğü için özel AI metin dosyaları gerekli değildir. Aynı nedenle, böyle bir dosyanın bulunmaması tek başına işletmeyi görünmez veya ticarete hazırlıksız ilan etmek için yeterli ölçüt oluşturmaz.

Bu alandaki uygulama planı, içerik sahibini ve güncelleme tetikleyicilerini de kapsamalıdır. Politika değiştiğinde hangi sayfaların, şemaların ve feed alanlarının değişeceği belirlenir. İçerik taslağını hazırlayan ekip ile ticari doğruluğu kabul eden ekip farklı olabilir. Değişiklik sonrasında yalnızca kodun doğrulanmasıyla yetinilmez; seçilmiş ürünler üzerinde görünür sayfa, makineye sunulan kayıt ve ilgili işlem sonucu birlikte incelenir. Böylece yapılandırılmış veri, bağımsız bir etiketleme işi olmaktan çıkar.

14 Feed ve kanal veri sözleşmeleri

Ürün feed'i, kurumun katalog bilgisini belirli bir platformun beklediği biçimde aktaran düzenli veri akışıdır. Feed hazırlamak ile bir satış kanalını açmak aynı işlem değildir. Ürünün keşfedilmesi, reklamda kullanılabilmesi ve doğrudan checkout'a katılabilmesi farklı uygunluk koşullarına bağlı olabilir. Webtures'ın önerdiği inceleme, her kanal için hangi verinin hangi amaçla gönderildiğini ve kabulün hangi aşamada doğrulandığını açıklayan bir veri sözleşmesiyle başlar.

Veri sözleşmesinde alanın adı kadar anlamı önemlidir. Fiyatın vergi dahil olup olmadığı, stok bilgisinin satışa ayrılabilir miktarı mı anlattığı, teslimat ülkesinin nasıl belirlendiği ve ürün bağlantısının hangi varyantı açtığı yazılmalıdır. Alanın eksik, boş, sıfır veya bilinmiyor olması farklı sonuçlar doğurabilir. Bu durumların dönüşüm kuralları açık değilse biçimsel olarak geçerli bir dosya ticari açıdan yanlış ürünler üretebilir.

Entegrasyonun başarısı, dosyanın karşı tarafa ulaşmasıyla bitmez. Aktarımın kabulü, kayıtların işlenmesi, ürünlerin uygun bulunması ve hedef yüzeyde kullanılabilmesi ayrı durumlardır. Kısmi hata halinde kaç ürünün etkilenmiş olduğu anlaşılmalıdır. Bir ürün kaldırıldığında eski kaydın ne zaman görünmez olacağı veya satışa kapatılacağı test edilir. Düzenli tam aktarım ile yalnızca değişen kayıtları aktarma yaklaşımının işletim maliyeti ve hata kurtarma yolu birlikte değerlendirilir.

Google'ın UCP uygulamasında ürünün checkout uygunluğu için ayrıca alan tanımlanması ve feed kimliğinin checkout kimliğiyle eşleşmesi gibi kurallar bulunur. OpenAI ürün feed'i de kendi alan sözleşmesi ve etkinleştirme süreçleriyle değerlendirilmelidir. Bir platform için hazırlanan dosyayı adlarını değiştirerek diğerine göndermek yeterli kabul edilmemelidir. Ortak bir kurum içi katalog modeli yararlıdır; fakat hedef kanala özgü dönüşümler ve koşullar ayrı yönetilmelidir.

Güvenli aktarımda erişim anahtarları, dosya paylaşım yetkileri ve kişisel veri kapsamı kontrol edilir. Kamuya açık ürün bilgisini taşımak için müşteri profillerinin veya sipariş geçmişinin feed'e eklenmesi gerekmez. Hata günlüklerinde hassas erişim bilgileri tutulmamalıdır. Ortak entegrasyon sağlayıcısı kullanılıyorsa sözleşme, veri sahipliği ve hizmet kesintisinde kurtarma yolu netleştirilir. Tedarikçi panelinde görülen “başarılı” durumu gerektiğinde bağımsız örnek kontrolle doğrulanır.

Feed işletimi içerik, kategori, teknoloji ve ticaret ekipleri arasında dağılabilir. Bu nedenle her veri akışında iş sahibi ile teknik sahibi ayrı yazılmalıdır. Yeni kategori, ülke veya ürün tipi eklenmesi mevcut sözleşmeyi etkileyebilir. Güncelleme planında kabul edilmeyen kayıtların yaşı, ürün kapsamı, son başarılı işleme zamanı ve açık hata sayısı izlenir. Böylece feed yönetimi dönemsel bir dosya gönderiminden, ticari bilgilerin doğru kanala güvenilir biçimde taşınmasına dönüşür.

15 Stok fiyat ve teslimatta güncellik

Güncellik, bütün sistemlerin her anda aynı değeri göstermesi şeklinde koşulsuz vaat edilmemelidir. Dağıtık ticaret altyapısında değişikliklerin aktarılması, işlenmesi ve önbelleklere yansıması zaman alabilir. Yönetilmesi gereken konu, hangi alanın ne kadar gecikmeye dayanabildiği ve işlem yapılmadan önce hangi bilginin yeniden doğrulandığıdır. Bu raporda önerdiğimiz yaklaşım, sıfır gecikme iddiası yerine ölçülebilir güncellik hedefleri ve güvenli işlem davranışı tanımlamaktır.

Ürün açıklaması ile kampanya fiyatının değişim hızı aynı değildir. Stok bilgisi de depo, rezervasyon, satılabilir miktar ve sevkiyat kapasitesi gibi farklı durumlar içerebilir. Bir ürünün fiziksel olarak depoda bulunması, belirli müşteriye belirtilen tarihte satılabileceğini tek başına göstermez. Veri sözleşmesi stok alanının iş anlamını açıklamalıdır. Tam stok miktarını kamuya açmak zorunlu kabul edilmemeli; görev için gereken bulunabilirlik bilgisi, ticari mahremiyet ve hedef kanalın gereksinimleri birlikte değerlendirilmelidir.

Temsili bir kampanyada fiyat saat 14.00'te değişirken feed'in sonraki işleme zamanı 14.10 olsun. Ajan bu aralıkta eski fiyatı görebilir. Bu durumun doğru yönetimi, bütün önbellekleri kapatmak veya eski fiyatla koşulsuz satış yapmaya devam etmek değildir. Güncel teklif işlem öncesinde yetkili sistemden alınmalı; fark kullanıcının onay sınırını değiştiriyorsa yeniden değerlendirilmelidir. Araştırma, gecikmenin süresini ve bu aralıkta sistemin nasıl davrandığını birlikte ölçmelidir.

Güncellik ölçümünde kaynak değişimi, aktarımın hazırlanması, platformun alması ve hedefte doğrulanması için ayrı zamanlar tutulabilir. Bu zamanlar aynı saat dilimi ve uygun saat eşitlemesiyle karşılaştırılmalıdır. Son dosya gönderim tarihi, her ürün alanının yenilendiği tarih değildir. Başarısız kayıtlar ortalama gecikme hesabında kaybolmamalıdır. Henüz hedefte görülmeyen değişiklik, sıfır saniyelik başarılı güncelleme gibi değil, açık bir yayılım kaydı olarak izlenmelidir.

Teslimat bilgisi adres, sipariş kesim saati, hazırlama süresi ve taşıyıcının hizmet alanıyla ilişkilidir. Bir sayfada ülke genelinde yazan süre, müşterinin kesin tarih koşulunu karşılamayabilir. Takvim günü ile iş günü farkı, resmî tatiller ve mağazadan teslim alma seçenekleri kendi kurallarıyla ele alınmalıdır. Taşıyıcı tahmini ile işletmenin garanti ettiği taahhüt ayrı ifade edilir. Veri doğrulanamıyorsa ajan kesin teslim sözü üretmek yerine belirsizliği açıklamalıdır.

Teknik çözüm, sorunun kaynağına göre seçilmelidir. Olay temelli güncelleme, düzenli aktarım, önbellek geçersizleştirme veya işlem öncesi sorgu farklı ihtiyaçları karşılayabilir. Her alanda en sık sorgulama yapmak maliyeti artırabilir ve kaynak sistemin kapasitesini zorlayabilir. Güncellik hedefi; veri değişim sıklığı, yanlış bilginin etkisi ve işletim maliyetiyle birlikte kararlaştırılmalıdır. İşlem öncesi doğrulama da tek başına stok rezervasyonunun veya sipariş kabulünün yerine geçirilmemelidir.

Raporda fiyat veya stok uyuşmazlığı gözlendiğinde doğrudan küresel bir “satıcı güvenilirlik puanı” cezası uygulandığı ileri sürülmemelidir. Böyle ortak ve tüm platformlarda geçerli bir mekanizma doğrulanmış değildir. Ölçülebilen sonuçlar esas alınır: teklifin reddi, yanlış sepet, yeniden onay ihtiyacı, müşteri desteği yükü veya iptal edilen işlem. Bu yaklaşım, veri kalitesi yatırımını varsayılan algoritmik cezalara değil, kurumun gözleyebildiği ticari sonuçlara bağlar.

16 Teknik uygulama ve sürüm yönetimi

Agentic Commerce entegrasyonları, değişen platform belgeleri ve kurum içi sistemler arasında çalışır. Bir kez bağlantı kurulmuş olması, aynı akışın kalıcı biçimde doğru çalışacağını göstermez. Ürün alanları, API sürümleri, hesap uygunluğu ve ticari kurallar zaman içinde değişebilir. Bu raporda önerdiğimiz uygulama düzeni, her önemli değişikliğin hangi müşteri görevini etkileyebileceğini izleyen bir sürüm ve kabul kaydı üzerine kurulmalıdır.

Başlangıç kaydında kullanılan protokol ve API sürümü, uygulama belgesinin kontrol tarihi, mağaza hesabının erişim durumu, test edilen ülkeler ve ürün tipleri bulunmalıdır. Kararlı sürüm, önizleme ve yol haritası birbirinden ayrılır. Açık bir protokol belgesini uygulamak, belirli tüketici platformunda canlıya çıkışın kabul edildiği anlamına gelmez. Teknik ekip bu ayrımı geliştirme planına yansıtmalı; ticari ekip de henüz onaylanmamış kanalı mevcut hizmet kapasitesi olarak sunmamalıdır.

Yetenek keşfi için kullanılan dosya ve uç noktalar ilgili standardın sürümüne göre doğrulanır. UCP'nin tanımladığı keşif yolu ile A2A Agent Card aynı belge değildir. Kurumun kendi oluşturduğu bir ticaret manifesti yararlı olabilir; ancak adı ve konumu bütün ajanların desteklediği evrensel standart gibi tanıtılmamalıdır. İlan edilen yeteneğin gerçekten çalışması ve çağıranın gerekli izne sahip olması, dosyanın erişilebilirliğinden ayrı kabul koşullarıdır.

Uygulamada ilk amaç mümkün olan bütün protokolleri aynı anda kurmak değildir. Öncelikli görev için gerekli en küçük güvenilir bağlantı seçilir. Bir projede katalog düzeltmesi ve sağlam mağaza devri yeterli olabilir; diğerinde izinli sepet araçları gerekir. Geliştirme işi, beklenen davranış, veri sözleşmesi, hata durumları ve kabul örnekleriyle tanımlanır. Sadece “ajan uyumu eklenecek” ifadesi, ekipler arasında sınanabilir bir teslimat oluşturmaz.

Sürüm değişiklikleri için biçim ve iş davranışı birlikte kontrol edilmelidir. Alan adı aynı kalırken anlamı değişebilir; daha önce isteğe bağlı alan zorunlu hale gelebilir. Uyarlama katmanı bu farkları açık biçimde yönetmelidir. Gerçek müşteri kayıtları yerine uygun sentetik veya izinli test verileriyle sözleşme testleri oluşturulabilir. Kritik ürün kimlikleri, toplam hesabı, erişim sınırları ve kullanıcıya devir her önemli değişiklikte yeniden doğrulanmalıdır.

Google Content API for Shopping geçişi bu disiplinin somut bir örneğidir. Araştırma tarihi itibarıyla eski Content API için sonlandırma süreci başlamış, Merchant API'ye geçiş yönlendirmesi yapılmıştır. Eski bir rehberde Content API adının bulunması yeni entegrasyona aynı API ile başlamayı haklı çıkarmaz. Mevcut bağlantıda kullanılan sürüm, sağlayıcının geçiş sorumluluğu ve güncel kapanış takvimi kontrol edilmelidir. Yeni çalışma planı güncel desteklenen arayüzü temel almalıdır.

Yayın öncesinde geri alma ve güvenli durdurma yolu hazırlanır. Sorun halinde yalnızca uygulama kodunu eski sürüme çevirmek yeterli olmayabilir; oluşturulmuş sepetler, bekleyen görevler ve değişmiş veri kayıtları da ele alınmalıdır. Kontrollü genişletme, sınırlı ürün veya hesap grubuyla başlayabilir. Canlıya geçiş sonrasında hata kayıtlarının sahibi, izleme sıklığı ve müdahale koşulları belli olmalıdır. Böylece teknik uygulama, teslim gününde tamamlanan bir entegrasyondan sürdürülebilir ticaret yeteneğine dönüşür.

17 Protokol seçimi ve birlikte çalışabilirlik

Agentic Commerce altyapısında protokol seçimi, müşterinin yapmak istediği görevden başlamalıdır. Bir markanın ürün araştırmasını kolaylaştırmak istemesiyle, kullanıcının önceden verdiği yetkiye dayanarak sipariş oluşturmak istemesi aynı entegrasyon ihtiyacını doğurmaz. İlk durumda katalog ve ürün sorgulama yeterli olabilir. İkinci durumda teklifin geçerliliği, ödeme yetkisi, sipariş kaydı ve istisna yönetimi de kapsama girer. En doğru mimari, mümkün olan bütün protokolleri ekleyen değil, hedef görevi gerekli kontrollerle tamamlayabilen mimaridir.

MCP, AI uygulamasının araç ve veri kaynaklarına erişimini düzenler. A2A, bağımsız ajanların görev ve mesaj alışverişini destekler. ACP ve UCP ticari etkileşimlerin ortak biçimde temsil edilmesine yönelir. AP2 ise ticari işlem ve ödeme yetkisinin doğrulanabilir biçimde taşınmasını ele alır. Bu yapılar aynı seviyede alternatifler değildir; bazı mimarilerde birlikte kullanılabilir. Bununla birlikte her satıcının hepsini kurması gerektiği sonucu çıkarılamaz. Standart bir API ile sınırları açık bir görev yürütmek, ihtiyacı karşılayan bir başlangıç olabilir.

Birlikte çalışabilirlik değerlendirmesi, belge düzeyinde ve çalışan sistem düzeyinde ayrı yapılmalıdır. Satıcının desteklediği sürüm ile platformun kullandığı sürüm uyuşmayabilir. Aynı protokol adı altında farklı yetenekler etkin olabilir. Bir sistem ürün sorgulayabilirken diğeri yalnızca checkout oturumu kabul edebilir. Özellik eşleşmesinin bulunmaması kullanıcıya açıklanabilir bir sonuç üretmeli; ajan desteklenmeyen işlemi başka bir uç noktaya tahmin ederek göndermemelidir.

UCP için işletme profilinin yayımlandığı keşif yolu /.well-known/ucp biçimindedir. Bu profil, desteklenen hizmetleri ve sürümleri anlamaya yarar. Dosyanın bulunması, ilan edilen her işlevin çalıştığı veya belirli bir tüketici platformunun satıcıyı kabul ettiği anlamına gelmez. Denetimde profil ile gerçek yanıtlar birlikte karşılaştırılmalıdır. Bir başka belgede geçen farklı keşif yolu, güncel uygulama sözleşmesi doğrulanmadan kopyalanmamalıdır.

Teknik ekibin tutacağı protokol kaydı sade fakat yeterli olmalıdır: uygulanan sürüm, etkin yetenekler, doğrulanan uç noktalar, kimlik doğrulama yöntemi, test ortamı ve değişiklik sahibi. Taslak bir özellik ile kararlı bir uygulama aynı düzeyde gösterilmez. Sağlayıcının gelecek planında bulunan bir özellik, mevcut kapasite olarak sunulmaz. Sürüm değiştiğinde hangi görevlerin yeniden çalıştırılacağı da bu kayda bağlanır.

Webtures açısından önerilen çıktı, teknoloji isimlerinden oluşan bir kontrol listesi değildir. Müşterinin mevcut sistemleriyle hedef görevi eşleyen bir entegrasyon kararıdır. Kararda hangi bileşenin korunacağı, hangisinin uyarlanacağı, hangi dış onayın beklendiği ve hangi aşamanın insan tarafından tamamlanacağı görünür olmalıdır. Bu yaklaşım, henüz ticari erişimi doğrulanmamış bir kanala gereksiz yatırım yapılmasını önlerken katalog, teklif ve işlem kalitesinde bugünden geliştirilebilecek alanları açığa çıkarır.

18 Araç ve API sözleşmelerinin tasarımı

Bir aracın yapay zekâ tarafından çağrılabilmesi, o aracın ticari kullanıma hazır olduğunu göstermez. Hazırlık, girdinin ne anlama geldiğini, hangi değişikliği yapabileceğini ve sonucun nasıl doğrulanacağını açıkça tanımlamakla başlar. “Siparişi yönet” gibi geniş bir araç, okuma, değiştirme, iptal ve ödeme işlemlerini belirsiz biçimde bir araya getirebilir. Daha açık araç sınırları, hem ajanın kararını hem uygulamanın yetki kontrolünü kolaylaştırır.

Katalog sorgulama, stok doğrulama, teklif üretme ve sipariş oluşturma işlevlerinin etkileri ayrı değerlendirilmelidir. Salt okunur bir ürün sorgusu ile stok rezervasyonu yapan bir çağrı aynı şekilde ele alınmaz. Araç açıklaması, yan etkiyi gizlememelidir. Sepet oluşturmak rezervasyon başlatıyorsa bu davranış sözleşmede yazılı olmalıdır. Hangi eylemin müşteriye görünür sonuç ürettiği ve hangisinin finansal etki doğurduğu uygulama tarafından bilinmelidir.

Girdi sözleşmesi ürün ve varyant kimliği, miktar, para birimi, müşteri bağlamı ve gerekli sürüm bilgilerini açık biçimde taşımalıdır. Sayısal tutarın hangi birimle verildiği belirsiz bırakılmamalıdır. Bazı sağlayıcıların kullandığı en küçük para birimi yaklaşımı diğer bütün araçlara varsayılan olarak taşınmaz. Boş değer, bilinmeyen değer ve sıfır birbirinden ayrılır. Stok miktarının bilinmemesi, ürünün stokta bulunmadığı anlamına gelmediği gibi sınırsız stok anlamına da gelmez.

Yanıt yalnızca kullanıcıya gösterilecek bir cümleden oluşmamalıdır. Gerekli durumlarda ürün kimliği, teklif sürümü, hesaplanan toplam, geçerlilik zamanı ve işlem durumu yapılandırılmış biçimde dönmelidir. MCP araç tanımları bu amaçla girdi şeması ve isteğe bağlı çıktı şeması sunar. Bununla birlikte şemaya uygun bir yanıtın ticari açıdan doğru olduğu ayrıca sınanır. Doğru biçimlendirilmiş yanlış fiyat, doğrulama ihtiyacını ortadan kaldırmaz.

Hata sözleşmesi, ajanın ne yapması gerektiğini belirleyen önemli bir parçadır. Geçersiz ürün kimliği, yetki eksikliği, süresi dolmuş teklif, geçici hizmet hatası ve sonucu bilinmeyen işlem farklı durumlardır. Her hataya otomatik tekrar uygulanması doğru değildir. Tekrarın güvenli olup olmadığı, önceki işlemin etkisi ve sağlayıcının kuralıyla belirlenmelidir. Kullanıcıya gösterilen açıklama anlaşılır olmalı; hata ayrıntıları gizli anahtar veya başka müşterinin bilgisini içermemelidir.

Araçların kendileri hakkında verdiği açıklamalar da mutlak güven kaynağı değildir. Bir aracın salt okunur olduğunu söylemesi, uygulamada hiçbir değişiklik yapmadığını kanıtlamaz. İşletme tarafında erişim kapsamı, kaynak sınırı ve işlem denetimi uygulanır. Kullanıcı hesabıyla ilişkili her çağrıda doğru müşteriye ait kaynak kullanıldığı doğrulanır. Bir müşterinin sepetinin başka müşterinin veya yetkisiz bir oturumun erişimine açılması, model kalitesinden bağımsız bir erişim kusurudur.

Uygulama öncesinde araç başına bir kabul örneği ve bir olumsuz örnek hazırlanması yararlıdır. Stok sorgusu doğru varyantı döndürmeli, bilinmeyen varyantı uydurmamalıdır. Teklif aracı zorunlu ücretleri hesaplamalı, para birimi değiştiğinde bunu gizlememelidir. Sipariş aracı aynı iş talebinin yeniden çağrılmasını yönetmelidir. Böylece araç kataloğu, açıklamaların bulunduğu bir rehber olmaktan çıkar; işletmenin hangi işlevi hangi koşullarda güvenilir biçimde sunduğunu gösteren denetlenebilir bir sözleşmeye dönüşür.

19 Sepet teklif ve ticari kurallar

Sepet, seçilen ürünlerin listesidir; ticari teklif ise bu ürünlerin hangi koşullarda alınabileceğini belirler. Ürün bedeli, teslimat seçeneği, zorunlu ücretler, uygulanabilir indirim ve ilgili vergi hesabı birlikte değerlendirilmeden kesin toplam açıklanmamalıdır. Ajanın katalogda gördüğü fiyat, checkout anında geçerli teklifin yerine geçmez. Özellikle adres, ödeme yöntemi veya üyelik durumuna bağlı koşulların erken aşamada kesinleşmiş gibi sunulması kullanıcı güvenini zedeler.

Teklif için önerilen kayıt; satıcı kimliği, ürün varyantları, miktarlar, para birimi, toplam bileşenleri, teslimat seçeneği, geçerlilik süresi ve teklif sürümünü içermelidir. Bu kayıt, bütün protokollerde aynı alan adlarını kullanmak zorunda değildir. Önemli olan uygulamada aynı ticari anlamın korunmasıdır. Bir entegrasyonun alan adları diğerine taşınırken bedelin vergi dahil mi hariç mi olduğu veya teslimatın tahmin mi taahhüt mü olduğu kaybolmamalıdır.

Kontrollü bir örnekte kullanıcı toplam bütçeyi 4.000 TL ile sınırlandırmış olsun. Ürün 3.850 TL, zorunlu teslimat bedeli 200 TL ise görev bütçeye uygun değildir. Ajan, ürün etiket fiyatının sınır içinde olmasını başarı kabul edemez. Aynı şekilde ücretsiz teslimatın yalnızca belirli üyelik seviyesine ait olması, bu üyeliğe sahip olmayan kullanıcı için bedelsiz gönderim sözü vermeye izin vermez. Bu örnek bir test tasarımıdır; gerçek fiyat veya kampanya iddiası değildir.

Kampanya kuralları sürümlenmelidir. Kullanıcının uygunluğu, kuponun geçerlilik zamanı, minimum sepet tutarı ve başka indirimlerle birlikte kullanılıp kullanılamadığı belirlenir. Ajan uygun olmayan indirimi denediğinde anlamlı ret yanıtı almalıdır. İndirim uygulamak için farklı müşteri kimliği kullanması veya üyelik koşulunu yok sayması önlenmelidir. Satıcının marj koruma kuralları da modelin yazdığı açıklamalarla değil yetkili fiyatlama sistemiyle yürütülmelidir.

Stok yönetiminde kullanılabilir miktar ile fiziksel depodaki toplam miktar ayrılmalıdır. Başka siparişlere ayrılmış ürün, satılabilir stok olarak gösterilmeyebilir. Ancak “stok ikiye düştüğünde bütün ajan işlemleri kapanır” gibi evrensel bir kural doğru değildir. Eşik, ürünün talebine, rezervasyon yöntemine ve işletmenin risk tercihine bağlıdır. Denetim, belirli bir eşik dayatmak yerine aynı son stok biriminin iki talebe tahsis edilmesini veya toplam tahsisin satılabilir stoku aşmasını engelleyen davranışı sınamalıdır.

Onaydan sonra teklif değiştiğinde esas soru değişikliğin önceden verilen yetkinin içinde kalıp kalmadığıdır. Yalnızca fiyatın düşmesi, farklı ürün veya satıcıya geçişi meşru kılmaz. Teslimatın gecikmesi, iade koşulunun değişmesi veya ürünün yenilenmiş olarak sunulması kararın anlamını değiştirebilir. Kapsam dışı değişiklikte yeni onay gerekir. Uygun alternatif bulunamazsa işlemi durdurmak doğru sonuçtur. Böylece teklif yönetimi, dönüşümü artırmak için koşulları esneten bir mekanizma yerine müşterinin kararını doğru uygulayan bir ticaret kontrolü olur.

20 Kullanıcı yetkisi ve ödeme akışı

Agentic Commerce içinde en önemli ayrımlardan biri, kullanıcının bir sisteme erişim vermesiyle para harcama yetkisi vermesi arasındadır. Hesapla giriş yapılmış olması veya OAuth erişim tokenı alınması, o hesap adına sınırsız alışveriş yapılabileceğini göstermez. Kullanıcı ürün araştırmasını, sepet hazırlanmasını ve ödeme başlatılmasını farklı sınırlarla yetkilendirebilir. Bu ayrım arayüzde anlaşılır, uygulamada denetlenebilir olmalıdır.

Önerilen yetki kaydı; temsil edilen kullanıcıyı, işlem amacını, izin verilen satıcı veya kategori sınırlarını, toplam bütçeyi, para birimini ve geçerlilik süresini ilişkilendirir. Göreve göre miktar, teslimat koşulu veya ürün niteliği de kesin sınıra dönüşebilir. Kullanıcının doğal dilde verdiği talep, onay öncesinde açık bir özete çevrilmelidir. Ajanın yorumu ile kullanıcının gerçekten onayladığı kapsam arasındaki fark finansal işlemden önce giderilmelidir.

AP2 v0.2 bu alanda Checkout Mandate ve Payment Mandate yapılarını kullanır. İlki ticari sepetin satın alınması, ikincisi ilgili ödemenin yetkilendirilmesi için doğrulanabilir kayıt sağlar. Kullanıcının son sepeti onayladığı akış ile önceden kısıt verdiği otonom akış ayrılır. vct alanı şema türünü ve sürümünü; checkout_hash ilgili checkout kaydıyla bağı ifade eder. Açık yetkilerde ajan anahtarının bağlanması ve süre sınırı önemlidir. Bu alanlar uygulanan sürüme göre doğrulanmalı; eski yayınlardaki terimler güncel alan adı gibi kullanılmamalıdır.

AP2 bir banka veya ödeme ağı değildir. Aynı şekilde ödeme tokenı da tek başına kullanıcının bütün ticari koşulları onayladığını kanıtlamaz. Token, ham ödeme bilgisinin daha kontrollü kullanımını sağlayabilir; kapsamı sağlayıcıya göre değişir. Kriptografik yetki, ödeme kimlik bilgisi, bankanın provizyon onayı, tahsilat ve sipariş kabulü farklı kayıtlardır. Bunların tek bir “ödeme başarılı” etiketi içinde birleştirilmesi, hata anında ne olduğunu anlamayı zorlaştırır.

Türkiye için uygunluk, belirli satıcı ve ödeme sağlayıcısı bağlantısında değerlendirilmelidir. Kuruluş ülkesi, ödeme hesabı, alıcının konumu, para birimi, kart ağı ve işlem türü ayrı koşullardır. Global bir duyuru, bütün yerel hesapların ilgili özelliği kullanabildiğini göstermez. Desteğin araştırmada doğrulanamamış olması da kesin olarak destek bulunmadığı anlamına gelmez. Canlı uygulama kararı için sağlayıcının güncel teknik ve ticari teyidi gerekir.

Ek kullanıcı doğrulaması gerektiğinde akış güvenilir biçimde insana devredilmelidir. 3D Secure her işlemde aynı SMS veya tek kullanımlık şifre ekranının açılacağı anlamına gelmez; kullanılan yönteme ve işlem değerlendirmesine göre farklı akışlar bulunabilir. Ajan, gereken doğrulamayı atlamaya veya kullanıcı adına kod tahmin etmeye çalışmamalıdır. Buradaki hazırlık ölçütü, kontrolün kaldırılması değil, doğru yerde devreye girmesi ve sonrasında işlemin durum kaybetmeden devam etmesidir.

Yetki iptal edildiğinde yeni finansal veya durum değiştiren işlem başlatılmamalıdır. Buna karşılık daha önce başlatılmış bir işlemin durumunu sorgulamak ve güvenli uzlaştırmayı yürütmek gerekebilir. İptal anı, işlem anı ve finansal etki ayrı kaydedilir. Bu ayrıntı, kullanıcının kontrolünü korurken sistemin yarım kalmış işlemleri gözden kaçırmamasını sağlar.

21 İşlem güvenilirliği ve sipariş yaşam döngüsü

Bir ajan görevi ağ bağlantısı kesildiğinde, servis yavaşladığında veya yanıt eksik geldiğinde de doğru davranmalıdır. Normal koşulda tek seferde çalışan bir demo, güvenilir ticaret altyapısının yeterli kanıtı değildir. Hazırlık değerlendirmesi, işlemin beklenen yolunun yanında belirsiz sonuçları ve toparlanma davranışını da kapsamalıdır. Kullanıcı açısından en ciddi sorunlardan biri, sistemin kendi durumunu bilmeden yeni bir işlem başlatmasıdır.

Önerilen durum modeli, sepetten teslimata uzanan olayları birbirinden ayırır. Bütün işletmeler aynı durum adlarını kullanmak zorunda değildir. Ancak her kaydın hangi sistemde kesinleştiği ve başka hangi adımı tetikleyebildiği açık olmalıdır. Ödeme sağlayıcısının onayı, sipariş yönetim sisteminde kayıt bulunmadığında tek başına sevkiyat emri olarak değerlendirilmemelidir.

Idempotency, aynı isteğin tekrar gönderilmesiyle mükerrer etki oluşmasını önlemek için kullanılan önemli bir kontroldür. Ancak anahtarın kapsamı, saklanma süresi ve parametre değişikliklerine verilen yanıt sağlayıcıya bağlıdır. Bu nedenle ödeme isteğine eklenen teknik anahtar, kalıcı iş talebi kimliğiyle tamamlanmalıdır. Kullanıcının aynı alışveriş isteği, yeni oturum veya yeni ağ denemesi nedeniyle yeni sipariş niyeti sayılmamalıdır.

Yanıt kaybında sistem önce mevcut talebin durumunu araştırmalıdır. İlk isteğin başarısız görünmesi, işlemin gerçekleşmediğini kanıtlamaz. Aynı talep için yeni bir anahtar üretip tekrar ödeme başlatmak güvenli toparlanma yöntemi değildir. İşlem hâlâ belirsizse kullanıcıya kesin başarısızlık mesajı vermek yerine durumun kontrol edildiği açıklanır. Bu sırada otomatik tekrar sayısı ve toplam bekleme süresi sınırlandırılır.

Olay bildirimleri gecikmeli, yinelenmiş veya beklenenden farklı sırada gelebilir. İşleme alınmış olayların kimliği kaydedilmeli; aynı olay ikinci kez sevkiyat veya fatura oluşturmamalıdır. Gecikmiş bir bildirim siparişi yanlışlıkla önceki duruma döndürmemelidir. Olayın imzası ve ilgili hesap doğrulanır. Sadece zaman damgasına bakarak kesin sıra çıkarılması yerine, yetkili sistemdeki güncel durum gerektiğinde yeniden okunur.

Ödeme oluştuğu hâlde sipariş kaydının tamamlanamaması gibi durumlar açık istisna kuyruğuna alınmalıdır. Kimin inceleyeceği, hangi sürede sonuç beklendiği ve hangi telafi adımının uygulanabileceği önceden yazılır. Telafi her zaman bütün işlemleri geriye çevirmek değildir; bazen siparişi tamamlamak, bazen provizyonu kaldırmak, bazen kullanıcıya dönmek gerekir. Karar, mevcut finansal ve operasyonel duruma dayanmalıdır.

Webtures raporunda bu alanın çıktısı yalnızca hata sayısı olmamalıdır. Hatanın kullanıcıya etkisi, kaç işlemin belirsiz kaldığı, ne kadar sürede uzlaştırıldığı ve aynı sorunun tekrarını engelleyen değişiklik açıklanmalıdır. Gerçek kayıtlar incelenmeden bir sistemin mükerrer tahsilattan tamamen arındığı ileri sürülmez. Sınanan koşullar ve doğrulanamayan durumlar sonuçla birlikte görünür tutulur.

22 Güvenlik ve kontrollü olumsuz testler

Agentic Commerce güvenliği, modele doğru davranmasını söylemekle sınırlanamaz. Ajanın okuduğu ürün açıklaması, kullanıcı yorumu veya dış belge kötü niyetli talimat içerebilir. Bir içerik, ürün hakkında bilgi vermek yerine bütçeyi değiştirmesini, başka hesaba erişmesini veya onay adımını kaldırmasını isteyebilir. Bu nedenle dış veri ile sistem talimatı arasındaki sınır hem model akışında hem araç yetkisinde korunmalıdır.

Kontrollü olumsuz testler, güvenlik kontrolünün başarısızlık durumunda nasıl çalıştığını gösterir. Test içeriği izin verilen ortamda hazırlanır; gerçek üçüncü taraf sayfalara müdahale edilmez. Zararsız bir deneme metninin ajanı yanlış araca yönlendirmesi sınanabilir. Ancak sonuç yalnızca ajanın verdiği cevaptan çıkarılmaz. Gerçekte hangi araçların çağrıldığı, hangi kayda erişildiği ve herhangi bir ticari değişiklik oluşup oluşmadığı da incelenir.

Yetki kapsamı dar tutulmalıdır. Ürün araştıran bir ajan ödeme anahtarına ihtiyaç duymayabilir. Sepet oluşturan araç bütün müşteri hesaplarını okuyabilmemelidir. Sipariş sorgulama erişimi, otomatik olarak iade yapma yetkisine dönüşmemelidir. Kullanıcı, oturum ve işletme sınırları her çağrıda kontrol edilir. Hassas kimlik bilgileri model bağlamında veya kullanıcıya açık hata mesajlarında bulunmamalıdır.

Olumsuz test setinde süresi dolmuş yetki, iptal edilmiş izin, farklı satıcı için kullanılan ödeme tokenı, yanlış para birimi, başka müşterinin sepeti ve değiştirilmiş imza bulunabilir. Aynı talebin tekrar kullanılması ve eşzamanlı çağrılar da sınanır. Başarılı sonuç, işlemin uygun şekilde reddedilmesi ve anlamlı kanıt bırakılmasıdır. Yetkisiz isteğin durması ticari görev tamamlama oranına eklenmez; güvenlik sonucu olarak ayrı değerlendirilir.

Güvenlik kontrollerini devreden çıkararak elde edilen yüksek başarı oranı, hazırlık kanıtı değildir. Bot yönetimi, kimlik doğrulama veya ödeme kontrolü için desteklenen entegrasyon yolu seçilmelidir. İmzalı ajan kimliği yararlı olabilir; ancak imza doğrulaması kullanıcının bütün talimatlarının karşılandığını tek başına göstermez. Aynı şekilde bir MCP bağlantısı, erişim tokenlarının doğru hizmet için verildiği veya bütün yetkilerin doğru sınırlandığı anlamına gelmez.

Test ortamındaki güvenlik, ticari etkiyi de kapsar. Sınırsız tekrarlar, kontrolsüz ürün sorguları veya uzun ajan döngüleri maliyet ve servis yükü oluşturabilir. Çağrı sayısı, işlem bütçesi, süre ve eşzamanlı görev sınırı belirlenmelidir. Testin durdurulacağı koşullar önceden yazılır. Üretim ortamında stok ayırmak, müşteri mesajı göndermek veya provizyon oluşturmak ayrı izin ve geri alma planı gerektirir.

Olumsuz senaryoların temiz geçmesi, sistemin her saldırıya karşı güvenli olduğunu kanıtlamaz. Kanıt, sınanan sürüm ve senaryo setiyle sınırlıdır. Model, araç, yetki politikası veya veri kaynağı değiştiğinde ilgili testler yeniden çalıştırılmalıdır. Webtures için doğru raporlama; bulunan kusuru, iş etkisini, sorumlusunu ve tekrar test sonucunu açıkça göstermektir. Yetkisiz finansal etki veya başka müşterinin verisine erişim, genel puanın içinde kaybolmamalı ve ilgili akışın açılmasını durdurmalıdır.

23 İnsan devri ve müşteri deneyimi

İnsan müdahalesi, agentic ticaretin başarısız olduğu anlamına gelmez. Bir görevde eksik tercih, doğrulanamayan uyumluluk veya ek ödeme onayı varsa kullanıcıya dönmek doğru tasarımdır. Hazırlık değerlendirmesi, otonomluğu her koşulda artırmayı değil, kararın doğru tarafta alınmasını hedeflemelidir. Müşterinin kontrolünü kaybetmeden hızlı ilerleyebilmesi, gereksiz soruların azaltılması kadar önemlidir.

Devir noktaları görev başlamadan belirlenmelidir. Hangi koşullar ajanın önceden verilen sınırlar içinde çözebileceği, hangilerinin yeni onay gerektirdiği açık olmalıdır. Siyah renk yalnızca tercihse başka renk önerilebilir; ancak kullanıcı onaylamadan farklı ürünün satın alınması ayrı bir karardır. Kesin teslimat sınırı karşılanmıyorsa ajan bunu sessizce esnetmemelidir. Bilinmeyen bilgi ile kullanıcı tercihi eksikliği de aynı soru biçiminde sunulmamalıdır.

Kullanıcıya devredilen bağlam anlaşılır ve yeterli olmalıdır. Seçilen ürün, varyant, adet, satıcı, toplam tutar ve teslimat koşulu görünür kalmalıdır. Hangi adımın tamamlandığı, hangisinin beklediği ve neden kullanıcıya ihtiyaç duyulduğu açıklanmalıdır. Ajanın başarısızlık ayrıntılarını teknik hata yığını olarak göstermesi yerine, karar verilebilir bir özet sunması gerekir. Kullanıcı devam etmek istemediğinde güvenli biçimde durabilmelidir.

Mağazaya yönlendirme yapılırken sepetin korunması ayrıca test edilmelidir. Yeni tarayıcı penceresi, uygulama içi tarayıcı veya oturum süresi değişikliği ürün bilgisini kaybettirebilir. Kullanıcı yeniden giriş yaptığında farklı hesaba ait sepetin açılmaması gerekir. Süresi dolmuş teklif için eski tutar kesinmiş gibi gösterilmez; güncel koşullar yeniden alınır. Devir bağlantıları gereksiz kişisel veri veya ödeme bilgisi taşımamalıdır.

Deneyim değerlendirmesinde erişilebilirlik önemini korur. Ajanların bazı işlemleri API üzerinden yapması, insanların arayüzle etkileşiminin ortadan kalktığı anlamına gelmez. Onay, karşılaştırma, adres düzeltme ve destek süreçleri anlaşılır etiketler, okunabilir toplamlar ve kullanılabilir hata mesajları gerektirir. Kullanıcının görmediği bir kutunun onaylı sayılması veya önemli koşulların dar bir alana gizlenmesi iyi bir agentic deneyim oluşturmaz.

Devir başarısı ile tamamen otonom tamamlama ayrı raporlanmalıdır. Doğru sepetle mağazaya geçen bir kullanıcı henüz satın alma yapmış sayılmaz. Kullanıcının sonradan vazgeçmesi de tek başına teknik devir hatası değildir. Ölçüm, görevde beklenen son duruma dayanmalıdır. Bu ayrım sayesinde ekipler daha fazla otonomi görüntüsü üretmek yerine, kararın kesintiye uğradığı gerçek noktaları iyileştirebilir ve müşteri güvenini ticari performansın parçası olarak yönetebilir.

24 İptal iade ve satış sonrası işlemler

Agentic Commerce hazırlığı, siparişin oluşturulmasıyla tamamlanmaz. Müşteri daha sonra adresini düzeltmek, teslimat durumunu öğrenmek, ürünü iptal etmek veya iade talebi açmak isteyebilir. Bu işlemler ilk satın alma yetkisinden farklı yetkiler gerektirebilir. Bir ajan alışverişi hazırlamış olsa bile, aynı kullanıcı adına gelecekte her siparişi değiştirebileceği varsayılmamalıdır.

İptal talebi ile tamamlanmış iptal birbirinden ayrılmalıdır. Sipariş henüz hazırlanmıyorsa uygulanabilen bir işlem, sevkiyat başladıktan sonra farklı bir sürece dönüşebilir. Kullanıcıya “iptal edildi” demek için yetkili sistemde ilgili durumun oluştuğu doğrulanmalıdır. Talep incelemeye alındıysa bu durum açıkça söylenir. Ajan, yalnızca talep gönderdiği için finansal veya lojistik sonucun tamamlandığını ileri sürmemelidir.

İade sürecinde ürün, sipariş satırı, miktar ve uygunluk bilgisi birlikte değerlendirilir. Kısmi iadede toplam sipariş bedelinin yanlışlıkla iade edilmesi önlenmelidir. Kampanyalı sepet, çoklu ödeme yöntemi veya daha önce yapılmış iade varsa kalan tutar yetkili kayıttan hesaplanır. Bu işlem modelin serbest metin hesabına bırakılmaz. Para birimi ve tutar birimi bütün servisler arasında korunmalıdır.

Geri ödeme talebinin sağlayıcı tarafından kabul edilmesi, tutarın aynı anda müşterinin hesabında görünmesi anlamına gelmeyebilir. Kullanıcıya verilen durum, gerçek ödeme kaydıyla uyumlu olmalıdır. Talep edilen, işlenen, başarısız olan ve tamamlanan geri ödemeler ayrılır. Evrensel bir süre vaat edilmez; sağlayıcının ilgili işlem için sunduğu bilgi kullanılır. Belirsizlik varsa müşteriye anlaşılır takip yolu ve sorumlu kanal gösterilir.

İade yetkisi kötüye kullanıma açık bir alandır. Ajanın sadece sipariş numarasını bilmesi yeterli kabul edilmemelidir. Doğru kullanıcı, doğru sipariş ve izin verilen işlem kapsamı doğrulanır. Üçüncü tarafın bir ürün yorumuna veya destek belgesine yerleştirdiği talimat, iade alıcısını değiştirememelidir. Ödeme bilgilerinin başka bir hesaba yönlendirilmesi, açıklama metnine güvenilerek yapılabilecek bir düzenleme değildir.

Mükerrer işlem kontrolü satış sonrasında da sürmelidir. Aynı iade talebinin ağ hatası nedeniyle tekrar gönderilmesi ikinci geri ödeme oluşturmamalıdır. Aynı ürün satırı için eşzamanlı taleplerin toplamı, uygun kalan tutarı aşmamalıdır. İşletmenin test tasarımında tam iptal, kısmi iade, reddedilen talep, gecikmiş olay bildirimi ve başarısız geri ödeme yer almalıdır. Kontrollü testte kullanılan ürünler ve finansal etkiler ayrıca kaydedilir.

Politika bilgisi müşteriye sade dille sunulmalı; ürün, satıcı ve işlem türüne göre değişen koşullar korunmalıdır. Tek bir iade süresi bütün kategoriler için evrensel kural gibi kodlanmamalıdır. Hukuki yorum gerektiren veya işletmenin istisna kararı beklenen durumlar ilgili uzmana aktarılır. Agentic sistemin görevi her talebi otomatik kabul etmek değil, doğru talebi doğru yetkiyle ve izlenebilir biçimde yürütmektir.

Webtures için bu alan, hazırlık raporunu gerçek ticaret yaşam döngüsüne bağlar. Satış öncesinde doğru ürün seçmek kadar, satış sonrasında yanlış işlemi güvenli biçimde düzeltmek de müşteri güvenini etkiler. Rapor; hangi işlemlerin yalnızca bilgilendirme düzeyinde, hangilerinin talep oluşturma düzeyinde, hangilerinin doğrulanmış uygulama düzeyinde çalıştığını açıkça göstermelidir. Böylece satın alma hızının yanında operasyonel doğruluk ve müşterinin işlem üzerindeki kontrolü de ölçülebilir hâle gelir.

25 İzinli denetimin kapsamı ve veri toplama

İyi bir hazırlık değerlendirmesi, mağazanın tamamına genel bir başarı etiketi vermek yerine belirli ticari görevler için güvenilir kanıt üretir. Webtures’ın önerdiği denetim, önce iş hedefini ve erişim sınırlarını tanımlar. Hangi ürün grupları incelenecek, hangi müşteriye hizmet verilecek, hangi kanal kullanılacak ve test hangi işlemde duracak? Bu sorular yanıtlanmadan başlatılan otomatik tarama, çok sayıda teknik uyarı üretebilir; ancak hangi sorunun satış veya müşteri deneyimi üzerinde belirleyici olduğunu açıklamakta yetersiz kalır.

Kapsam kaydı; alan adlarını, mağaza ortamlarını, katalog ve stok kaynaklarını, ödeme bağlantılarını, test hesaplarını ve veri sorumlularını bir araya getirir. İzin verilen işlemler salt okuma, test sepeti oluşturma, stok rezervasyonu, ödeme provizyonu, tahsilat, iptal ve iade için ayrı yazılır. Bir alanda verilen izin diğerine taşınmaz. Testin durdurulmasını isteyebilecek kişi, çalışma saatleri, istek sınırları, geri alma adımları ve beklenmeyen etki halinde izlenecek yol baştan belirlenir. Böylece araştırma, üretim operasyonunun sorumluluklarıyla uyumlu yürür.

Veri toplama mümkün olan en düşük erişimle başlar. Ürün dışa aktarımı, mevcut feed dosyaları, kamuya açık ürün sayfaları, izinli sistem kayıtları ve teknik tasarım belgeleri ilk inceleme için yeterli olabilir. Sonraki aşamada yalnızca eksik kanıtı tamamlayacak erişim açılır. Denetçinin bütün müşteri veritabanına veya sınırsız yönetici anahtarına sahip olması bir kalite ölçütü değildir. Sentetik müşteri hesapları ve dar kapsamlı teknik roller, testin yeniden kurulmasını da kolaylaştırır.

Her veri örneği anlamını açıklayan bağlamla saklanmalıdır. Aynı SKU için farklı fiyatların görülmesi her zaman hata değildir; farklı para birimi, müşteri grubu, vergi bağlamı veya kampanya koşulu bulunabilir. Karşılaştırma kaydı ürün, varyant, satıcı, pazar, adres bölgesi, hesap rolü, para birimi ve kontrol zamanını içermelidir. Alanın hangi sistemden beklendiği de yazılır. Stok için depo yönetimi, ürün özelliği için onaylanmış katalog, sipariş durumu için sipariş yönetimi belirleyici olabilir. Tek doğruluk yaklaşımı, bütün verinin tek veritabanında tutulmasını gerektirmez.

Denetim kanıtları dört düzeyde ayrılır: belge incelemesi, salt okunur doğrulama, sandbox görev doğrulaması ve izinli üretim doğrulaması. Tasarım belgesinde bulunan bir özellik çalışır kabul edilmez. Sandbox başarısı üretim başarısına dönüştürülmez. Üretimde doğrulanan dar bir görev de bütün katalog ve ülkelerin aynı düzeyde hazır olduğu anlamına gelmez.

Test ortamıyla üretim arasındaki farklar ayrıca kaydedilir. Sandbox’ta vergi, kampanya, kargo veya stok rekabeti basitleştirilmişse sonuç bu sınırlar içinde yorumlanır. Bir kontrolün yapılamaması da açık bir sonuçtur: erişim verilmedi, kayıt bulunamadı, kanal desteklemiyor veya görev kapsam dışında. Bu durumlar birbirinin yerine kullanılmaz. Kanıtın eksik olduğu yerde hüküm ertelenir; teknik kusur görülmüş gibi puan kesilmez.

Toplanan kayıtlar amaçla sınırlı tutulur. Kişisel veri, ödeme bilgisi ve gizli erişim anahtarları rapora kopyalanmaz; gerekiyorsa maskelenmiş örnekler kullanılır. Hangi kaydın kim tarafından görüleceği, ne kadar tutulacağı ve çalışma sonunda nasıl kapatılacağı denetim düzeninin parçasıdır. Denetimin ilk teslimi böylece bir uyarı listesi değil, kapsamı ve güven düzeyi anlaşılır bir kanıt envanteri olur.

Otomatik denetim araçlarının rolü

Otomatik tarama, geniş bir ürün veya sayfa kümesindeki ortak kusurları bulmak için yararlıdır. Ancak tarama sonucu, gerçek müşterinin görevini tamamlama kanıtı olarak kullanılmamalıdır. Erişilebilirlik kontrolü bir düğmenin adını değerlendirebilir; doğru ürünü seçip seçmediğini anlamak için görev ve sistem kaydı gerekir. API sözleşme testi yanıtın biçimini doğrulayabilir; toplam tutarın geçerli ticari kurallarla hesaplandığı ayrıca sınanır.

Lighthouse içindeki deneysel Agentic Browsing değerlendirmesi, belirli sürüm ve ortam koşullarında erişilebilirlik, sayfa kararlılığı, WebMCP ve llms.txt gibi konularda bulgular sunabilir. Burada bir dosyanın kontrol edilmesi, o dosyanın bütün AI kanallarında zorunlu olduğu anlamına gelmez. Sonuç, genel bir ticari hazırlık veya ödeme güvenilirliği sertifikası olarak yorumlanmamalıdır. Araç sürümü ve etkin deneysel özellikler test kaydında tutulmalıdır.

Araç seçimi için hedef platform, gözlem kapsamı, yeniden üretilebilirlik ve veri işleme koşulları birlikte değerlendirilir. Laboratuvar görev setlerinden alınan yöntemler yararlı olabilir; yayımlanmış bir başarı yüzdesi ise farklı model, site ve görevlerden oluşan müşteri ortamına doğrudan taşınamaz. Webtures değerlendirmesinde otomatik kontrol, kontrollü görev yürütme ve yetkili sistem kaydı birbirini tamamlayan kanıtlar olarak ele alınır.

26 Kontrollü görev sözleşmesi

Kontrollü görev sözleşmesi, ajandan ne istendiğini ve hangi davranışın doğru kabul edileceğini test başlamadan önce tanımlar. Buradaki sözleşme bir hukuki belgeyi değil, değerlendirme kaydını ifade eder. Kullanıcı isteği, teknik izinler, ticari sınırlar ve doğrulama yöntemi aynı kayıtta buluşur. Bu kayıt olmadan “ürünü buldu”, “sepete ekledi” veya “işlemi tamamladı” ifadeleri birbirinden farklı sonuçlar için kullanılabilir.

Görev önce ihtiyaç ve zorunlu koşulları ayırır. Bir ürünün belirli cihaza uyumlu olması zorunlu; renginin siyah olması tercih olabilir. Ajan zorunlu koşulu doğrulayamadığında daha çok arama yapabilir, kullanıcıdan bilgi isteyebilir veya durabilir. Tercihi karşılamayan fakat zorunlu koşulları sağlayan bir seçenek ise açıklanarak sunulabilir. Test, bu iki davranışı aynı hata sınıfına koymamalıdır. Kullanıcının hedefi doğrulanamıyorsa görünürde akıcı bir cevap başarı sayılmaz.

Temsili görev sözleşmesi

Aşağıdaki örnek, test tasarımını açıklamak için oluşturulmuştur; gerçek bir ürün, fiyat veya teslimat taahhüdü değildir.

Görev kaydı bu özetin yanında kullanılan kanal, araçlar, hesap rolü, zaman sınırı, tekrar politikası, veri sürümü ve test ortamını da tutar. Süre sınırının sonunda henüz bitmemiş bir görev başarılı ilan edilmez. Yeniden denemenin aynı koşunun devamı mı yoksa yeni bir deney mi olduğu önceden belirlenir. Aksi halde çok sayıda başarısız girişimden sonra gelen tek başarılı sonuç, gerçek güvenilirliği örter.

Başarı doğrulaması iki parçalıdır. Nihai durum doğru olmalı; bu duruma ulaşırken izin sınırları korunmalıdır. Doğru ürünün sepette görünmesi, başka hesaptan veri okunmuşsa yeterli değildir. Benzer biçimde hiçbir yetki ihlali olmadan yanlış varyant seçilmesi de olumlu görev başarısı değildir. Son durum yetkili sistem kayıtlarıyla karşılaştırılır; açıklamaların anlamı gerekiyorsa insan değerlendirmesiyle incelenir. Başka bir dil modelinin yorumu tek doğrulama kaynağı olarak kullanılmaz.

Görev sözleşmesi birden fazla doğru sonucu kabul edebilir. Ürünün gerçekten bulunmadığı koşulda doğru ret, fiyatın değiştiği koşulda yeniden onay veya ek doğrulama gerektiğinde kullanıcıya devir beklenen sonuç olabilir. Ancak bunlar açıkça kendi sonuç sınıflarında raporlanır. Satın alma amacıyla başlayan bütün görevleri “ajan doğru davrandı” başlığında toplamak, olumlu tamamlanma oranını belirsizleştirir. Webtures değerlendirmesinde hem müşterinin hedefinin ne ölçüde gerçekleştiği hem sistemin sınırlarını ne ölçüde koruduğu görünür kalmalıdır.

27 Görev setleri ve hata senaryoları

Bir deneme ortamında tek bir ürünün sepete eklenmesi, agentic commerce hazırlığının küçük bir bölümünü gösterir. Görev seti, müşterinin kararını zorlaştıran koşulları ve sistemin hata anındaki davranışını birlikte kapsamalıdır. Webtures’ın önerdiği tasarımda görevler, ürün keşfi, seçim, ticari teklif, işlem hazırlığı, kullanıcıya devir ve izin verilen satış sonrası işlemler boyunca düzenlenir. Her aile için olağan durumun yanında bir sınır durumu bulunur.

Keşif görevleri doğrudan ürün adını söylemekle sınırlanmaz. İhtiyaç üzerinden arama, teknik özelliğe göre eleme, birden fazla ürünün karşılaştırılması ve eksik bilgiyle karşılaşıldığında açıklama isteme değerlendirilir. Türkçe günlük kullanım ile katalog dili arasındaki fark da incelenir. Kullanıcı “iki monitör bağlamak” istediğinde ajanın yalnızca HDMI sözcüğü geçen ürünü bulması yeterli değildir; cihaz, çözünürlük ve bağlantı koşulları anlamlı biçimde eşleşmelidir.

Ticari görevlerde değişen veri özellikle önemlidir. Göreve başlarken uygun görünen bir ürünün fiyatı yenilenebilir, son stok başka müşteri tarafından alınabilir veya kampanyanın geçerlilik süresi dolabilir. Test bu değişiklikleri kontrollü ortamda üretir. Beklenen davranış eski bilgiyle devam etmek değil, ilgili koşulu yeniden doğrulamak ve yetki sınırı değişmişse kullanıcıya dönmektir. Veri yenilendiğinde aynı ürünü bulamama ile güncel bilgiyi bilerek görmezden gelme ayrı hata nedenleridir.

İşlem dayanıklılığı görevleri, başarılı yanıt alınmayan durumlara odaklanır. Sepet isteğinin yanıtı kaybolduğunda kayıt oluşmuş olabilir. Ödeme sağlayıcısı sonucu ile sipariş yönetimi sonucu farklı zamanlarda gelebilir. Aynı olay tekrar teslim edilebilir. Bu senaryolar, ajanın daha fazla deneme yapma becerisini değil, işlem durumunu güvenilir biçimde öğrenmesini ve aynı ticari niyet için gereksiz ikinci işlem oluşturmamasını sınar. Zaman aşımını doğrudan başarısız ödeme olarak yorumlayan akışlar özellikle incelenir.

Yetki görevleri farklı müşteri hesabına erişme, geçerliliği bitmiş izin kullanma, tutar veya satıcı sınırını aşma ve iptal edilmiş yetkiyle devam etme gibi durumları kapsar. Testin beklenen sonucu reddetme veya kontrollü devir olabilir. Ürün açıklamasına yerleştirilmiş zararsız bir deneme yönlendirmesiyle dış içeriğin sistem kurallarını değiştirip değiştirmediği de sandbox içinde sınanabilir. Böyle bir test yalnızca izinli ortamdaki sentetik içerikle yapılır; canlı üçüncü taraf hizmetlere karşı manipülasyon anlamına gelmez.

Hata kaydı sadece “başarısız” sonucundan oluşmamalıdır. İlk kırılma noktası, kullanıcıya etkisi, sistemin verdiği yanıt, geride kalan durum ve toparlanma davranışı saklanmalıdır. Tek bir kök neden birden fazla aşamada belirti verebilir. Örneğin yanlış varyant eşlemesi hem stok hatası hem bütçe aşımı üretebilir. Aynı sorun üç kez farklı kusur sayılarak önceliklendirme bozulmamalıdır.

Görev setinin kapsamı işletmenin gerçek iş modeline göre seçilir. Yalnızca teklif hazırlayan B2B akışına tüketici checkout görevi uygulanmaz. Satış sonrası yetki bulunmayan projede gerçek iade başlatılmaz. Küçük fakat ticari olarak anlamlı bir görev seti, kapsamı açıklanmayan uzun bir kontrol listesinden daha güçlü karar desteği sağlar. Test sayısı kalite göstergesi değildir; hangi davranışın hangi koşullarda doğrulandığı kaliteyi belirler.

28 Pilot araştırma ve örneklem tasarımı

Webtures’ın ilk saha çalışması için önerilen tasarım, onay veren on perakendeciyle yürütülecek keşif amaçlı bir pilottur. Örnek dağılım dört giyim, üç elektronik ve üç ev yaşam işletmesinden oluşabilir. Bu dağılım bir uygulama önerisidir; bu rapor kapsamında işletmeler üzerinde test yapılmamıştır. Pilotun amacı ulusal bir sıralama üretmekten önce tekrar eden hata türlerini, veri bağımlılıklarını ve düzeltmenin görev başarısına etkisini anlamaktır.

Her işletmede otuz SKU incelenmesi, toplam üç yüz SKU’luk katalog örneklemi oluşturur. Seçim yalnızca yüksek trafik alan veya verisi düzenli ürünlerle sınırlanmamalıdır. Varyantlı ve tekil ürünler, kampanyalı ve standart fiyatlar, yüksek ve düşük stok, farklı teslimat koşulları ve farklı veri kaynakları kapsanmalıdır. Örneklemde kritik hata ihtimali yüksek ürünlere özellikle yer verilebilir; ancak bu seçimin genel katalog hata oranını tahmin etmek için tarafsız olmadığı açıklanmalıdır.

Görev yürütme tasarımı katalog incelemesinden ayrıdır. Her işletme için on iki görev ailesi, uygun olan iki erişim yolu ve üç tekrar planlanır. Bütün yollar kullanılabiliyorsa bir dalganın üst sınırı 10 × 12 × 2 × 3 = 720 yürütmedir. Aynı kapsamla düzeltme sonrası ikinci dalga yapılırsa üst sınır 1.440 yürütme olur. İncelenen üç yüz SKU bu sayıyla tekrar çarpılmaz. Her görev ailesinin kullanacağı ürün kümesi ayrıca belirlenir; aynı ürün birden fazla görevde yer alabilir.

Bu hesapta her işletme, görev ailesi ve erişim yolu birleşimi için önceden seçilmiş tek bir görev sözleşmesi üç kez yürütülür. Bir ailedeki bütün olumlu ve olumsuz alt senaryolar bu sayıya dahil değildir. Ek senaryo seçilirse yürütme planı ve paydalar genişletilir. Örneğin işletme başına 24 ayrı senaryonun iki yolda üçer kez çalıştırılması, on işletmede bir dalga için 1.440 yürütme oluşturur.

İki erişim yolu, projeye göre tarayıcı üzerinden yürütme ve izinli ticari araç/API yolu olarak tanımlanabilir. Bunlar her işletmede zorunlu kabul edilmez. Yol bulunmadığında başarısız görev icat edilmez; uygunluk matrisinde kapsam dışında veya henüz doğrulanmamış olarak gösterilir. Planlanan matris, teknik ve ticari olarak uygun matris ve gerçekten tamamlanan matris ayrı saklanır. Eksilen kapsam, raporun dip ayrıntısı değil, sonucun nasıl yorumlanacağını belirleyen bilgidir.

Tekrarlar yeni oturumlarla ve kayıtlı koşullarla yürütülür. Bir önceki denemede oluşan sepet, önbellek, kullanıcı tercihleri veya öğrenilmiş bağlam sonraki denemeyi etkileyebilir. Sıfırlanamayan etkiler not edilir; görev sırası mümkün olduğunda dengelenir. Aynı görevin üç tekrarı üç bağımsız müşteri gözlemi gibi sunulmaz. İşletme, ürün ve görev ailesi düzeyindeki ortaklıklar analizde korunmalıdır.

Önce ve sonra karşılaştırmasında görev tanımları ve başarı kuralları sabit tutulur. Bununla birlikte fiyat, katalog, ajan sürümü veya kanal koşulu değişmişse iki dalga tamamen eşdeğer sayılmaz. Değişiklik günlüğü hangi farkın uygulamadan, hangisinin dış koşullardan gelebileceğini gösterir. Küçük bir pilotta gözlenen iyileşmeyi yalnızca tek bir müdahaleye bağlamak çoğu zaman mümkün değildir.

Kamuya açık yayın için işletme adlarının kullanımı, bulguların anonimleştirilmesi ve maddi hata düzeltme süreci baştan kararlaştırılır. İşletmenin bulguyu kontrol etmesi araştırma sonucunu seçme hakkına dönüşmemelidir. Katılımın gönüllü olması, belirli altyapıların örneklemde yoğunlaşması ve küçük örneklem gibi sınırlamalar açık yazılır. Pilot büyüdükçe sektör, işletme ölçeği ve altyapı dağılımına göre daha dengeli bir araştırma tasarımı kurulabilir; ilk pilotun sonuçlarına sonradan ulusal temsil niteliği eklenmez.

29 Ölçüm göstergeleri ve doğru paydalar

Bir hazırlık raporundaki en önemli metodolojik karar, başarı oranının hangi denemelere göre hesaplandığıdır. Yalnızca sonuca ulaşan koşular kaydedilirse bütün sistemler olduğundan güvenilir görünür. Zaman aşımı, araç hatası veya yanlış son durum üreten geçerli denemeler paydada kalmalıdır. Test düzeneğinin kendi arızası nedeniyle hiç başlamayan denemeler ise gerekçeleriyle ayrı tutulabilir. Zor bir görevi sonradan kapsam dışı ilan ederek başarı oranını yükseltmek kabul edilebilir bir değerlendirme yöntemi değildir.

Temsili payda örneği

Hesabı açıklamak için yüz koşuluk bir plan düşünelim. Bunların sekseni olumlu müşteri görevi, yirmisi doğru durdurma beklenen olumsuz görev olsun. Dört olumlu koşu test düzeneği açılmadığı için hiç başlayamasın. Kalan yetmiş altı olumlu koşunun elli yedisi doğru tamamlanırsa olumlu görev başarısı 57 / 76 = %75 olur. On dokuz başarısız koşunun içindeki zaman aşımları ve sistem hataları paydadan çıkarılmaz.

Yirmi olumsuz koşunun on sekizinde doğru ret oluştuğunu varsayalım. Doğru durdurma oranı 18 / 20 = %90 olur. Bu on sekiz doğru ret, elli yedi olumlu sonuca eklenerek tek bir satış başarı yüzdesi üretilmez. Ayrıca yüz planlı koşudan doksan altısının geçerli yürütüldüğü açıklanır. Bu, koşu düzeyindeki ilerlemedir; bütün tekrarları tamamlanan işletme–görev ailesi–erişim yolu hücrelerinin oranıyla aynı gösterge değildir. Sayılar tamamen temsilidir.

Süre ölçümünde yalnızca ortalama verilmesi uzun beklemeleri gizleyebilir. Medyan, uygun örneklemde üst yüzdelikler ve süre sınırını aşan koşu sayısı birlikte gösterilir. Başarılı koşuların süresi ile bütün geçerli koşuların durumu ayrılmalıdır. Daha hızlı başarısız olmak, daha verimli ticaret anlamına gelmez. Benzer şekilde az araç çağrısı, doğru sonucun oluştuğunu tek başına göstermez.

Veri güncelliği kaynak değişikliğinin hedefte doğrulanmasına kadar geçen süreyle ölçülebilir. Henüz yansımamış değişikliklerin gecikmesi sıfır yazılmaz; açık ve izlenmeye devam eden kayıt olarak tutulur. Fiyat, stok ve açıklama farklı önem ve değişim hızlarına sahip olduğu için tek bir uyum oranında kaybolmamalıdır.

Toplam sonuçlarda kolay görevlerin fazla tekrarlanması ağırlığı değiştirmemelidir. Görev ailesi bazındaki oranlar ve ham adetler korunur; birleşik gösterge kullanılacaksa ağırlıklandırma önceden belirlenir. Küçük örneklemde birkaç ondalık basamaklı puan yerine açık sayılar ve belirsizliğin anlaşılır açıklaması daha faydalıdır. Her metriğin yanında kapsam, tarih, kanal ve ölçüm düzeyi bulunmalıdır.

30 Gözlemlenebilirlik ve işlem ilişkilendirme

Gözlemlenebilirlik, bir ajanın nereye tıkladığını izlemekten daha geniştir. Ticari görevin hangi veriyle başladığını, hangi araçları kullandığını, hangi izin sınırlarında ilerlediğini ve hangi işletme kaydını oluşturduğunu ilişkilendirmeyi gerektirir. Webtures’ın önerdiği düzen, gözlenen olay ile bu olaydan çıkarılan yorumu ayırır. Bir ürün sayfasına erişilmesi, ürünün karşılaştırıldığı veya satın alma için seçildiği anlamına gelmez.

İlk katman erişim ve çağrı kayıtlarıdır. Sunucu, CDN, katalog servisi ve ticari API, kendilerine ulaşan istekleri gösterebilir. İkinci katman görev ve oturum kayıtlarıdır. Başlangıç hedefi, araç çağrıları, süreler, hata kodları ve kullanıcıya devir burada izlenir. Üçüncü katman ticari sonuçtur: sepet, sipariş, ödeme, rezervasyon, iptal ve iade durumları. Bu katmanları ortak kimlikler üzerinden bağlamak, görünürde tamamlanan bir görevin gerçekte hangi sonuçla bittiğini anlamayı sağlar.

Kalıcı iş niyeti kimliği, bir müşterinin tek ticari talebini temsil eder. Bu kimliğin altında birden fazla görev yürütmesi, araç çağrısı veya yeniden deneme bulunabilir. Sepet, sipariş ve ödeme kimlikleri ayrıca saklanır. Böylece aynı talebe bağlı tekrarlar yeni müşteri talebi gibi sayılmaz. Bütün sağlayıcıların aynı kimliği desteklediği varsayılmaz; entegrasyon düzeyinde bir eşleme kaydı gerekebilir. İlişkilendirme kaybolduğunda tahmin üretilmeden kayıt açık bırakılır.

Ajan kaynağının kesinliği de görünür olmalıdır. Yalnızca User-Agent metni, kriptografik olarak doğrulanmış istekle aynı güven düzeyinde değildir. Davranışsal olarak otomasyona benzeyen oturum ise doğrulanmış ajan kimliği olarak etiketlenmemelidir. Kayıtlar doğrulanmış, doğrudan gözlenmiş ancak doğrulanmamış, analitik olarak tahmin edilmiş ve bilinmeyen şeklinde ayrılabilir. Bu sınıflandırma, denetimin belge–salt okuma–sandbox–üretim kanıt düzeylerinden farklı bir amaç taşır: burada sorulan şey isteğin kime ait olduğudur.

Ölçüm tasarımı kullanılan erişim yolunu dikkate alır. Tarayıcı üzerinden ilerleyen veya mağazaya devredilen akışlarda sayfa olayları oluşabilir. Doğrudan servis çağrısıyla yürüyen bir işlem ise aynı istemci etiketlerini çalıştırmayabilir. Bu nedenle yalnızca web analitiği oturumlarına bakılarak bütün ajan ticareti hesaplanmaz. Sunucu olayları ve sipariş kayıtlarıyla uzlaştırma yapılır; gözlenemeyen alanlar açıkça belirtilir.

İşletmenin erişemediği model içi değerlendirmeler de ölçülmüş gibi sunulmamalıdır. Bir ürünün modelin gizli karşılaştırma listesine kaç kez girdiği, bağımsız bir satıcının standart loglarından çıkarılamaz. Gözlenebilen şey belirli test yanıtlarında önerilme, izinli araç çağrısında sorgulanma, kaydedilmiş devir veya ticari işlemdir. “Ajan gösterimi” gibi bir ad kullanılacaksa olayın teknik tanımı ve gözlem alanı açık olmalıdır.

Sonuçların gelirle ilişkilendirilmesi ayrıca dikkat ister. AI yönlendirmesiyle gelen bir sipariş, tamamen otonom tamamlanmış sipariş demek değildir. Gözlenen ilişki de ilave satış etkisini tek başına kanıtlamaz. Denetim panosu kaynak, görev sonucu ve ticari sonucu ayrı gösterebilir; artımlı katkı değerlendirmesi karşılaştırma tasarımı gerektirir. Kayıt düzeni bu ayrımı mümkün kıldığı ölçüde yönetime değer sağlar.

31 Olgunluk değerlendirmesi ve kritik engeller

Hazırlık kararı, yöneticinin hangi kapsamı açabileceğini, hangi koşulları tamamlaması gerektiğini ve neyin henüz bilinmediğini göstermelidir. Tek bir toplam puan, açık erişim sorunuyla ödeme yetkisi kusurunu aynı sayıya indirgediğinde bu amacı zayıflatır. Webtures yaklaşımında değerlendirme; sekiz denetim alanı, kanıt düzeyi, görev kapsamı ve kritik engellerin birlikte okunmasına dayanmalıdır. Bu yapı rapor için önerilen uygulama modelidir; resmi bir sertifikasyon veya evrensel sektör standardı değildir.

Sekiz alan; kanal ve yetki uygunluğu, ürün keşfi ve kimliği, veri doğruluğu ve güncelliği, teklif ve ticari koşullar, görev yürütme, güvenlik ve kullanıcı kontrolü, ölçüm ve uzlaştırma, işletim ve iyileştirmedir. Her alanın yanında gözlenen durum, kanıt, açık soru ve bir sonraki adım bulunur. Bir alandaki güçlü sonuç diğerindeki eksikliği örtmez. Kusursuz katalog verisi, yetkisiz ödeme riskini kabul edilebilir hale getirmez.

Dört kanıt düzeyi birbirini tamamlayan bir ilerleme olarak kullanılabilir. Belge incelemesi tasarımın bulunduğunu, salt okunur doğrulama gerçek verinin belirli koşullarda tutarlı olduğunu gösterir. Sandbox doğrulaması kontrollü görevlerin çalıştığına ilişkin kanıt sağlar. İzinli üretim doğrulaması ise belirlenmiş canlı kapsam hakkında bilgi verir. Bu düzeyler şirketin bütün yeteneklerine yayılan tek merdiven değildir; ürün keşfi üretimde doğrulanmışken iade akışı yalnızca belge aşamasında olabilir.

Kritik kusurlar için kapsamı belirli geçit kuralları uygulanır. Yetkisiz ödeme, aynı ticari niyet için çift tahsilat veya başka müşterinin verisine erişim P0 olarak ele alınır ve etkilenen akışın açılmasını engeller. Yanlış varyant, yanlış toplam ve geçersiz stokla ilerleme P1 sınıfında incelenebilir. Ancak bu kusurlar onaylanmamış finansal işlem veya başka kritik etki doğuruyorsa P0 önceliklidir. Daha düşük etkili açıklık, gereksiz adım veya kullanım sorunları ayrı planlanır. Sınıf yalnızca hata adına değil, gerçekleşen etkiye ve yayılım kapsamına bağlıdır.

Kritik engel bulunmaması da otomatik genel onay değildir. Hiç sınanmamış ödeme akışında sıfır kritik hata görülmesi, güvenilir ödeme kanıtı sayılmaz. Kapsam eksikliği ile sıfır hata birbirinden ayrı tutulmalıdır. Açık bir bağımlılık, kapalı bir kanal veya sağlanmamış kullanıcı izni varsa sonuç “koşullu” ya da “henüz doğrulanmadı” biçiminde açıklanabilir.

Olgunluk raporunun karar cümlesi somut olmalıdır: “Seçilen otuz SKU için Türkçe ihtiyaçtan test sepetine kadar doğrulandı; ödeme kapsam dışında; teslimat güncellemesi için iki açık bulgu bulunuyor.” Bu cümle, bağlamsız bir “yüzde doksan hazır” ifadesinden daha fazla bilgi taşır. Görsel skor kartı kullanılacaksa kapsam, tarih ve kanıt düzeyi aynı yüzeyde görünmelidir.

Hazırlık kararı süresiz geçerli sayılmaz. Katalog eşleme değişikliği, yeni ödeme sağlayıcısı, yetki modeli güncellemesi, platform sürümü veya önemli kampanya kuralı yeniden değerlendirmeyi tetikleyebilir. Yönetim kurulacak kontrolü yalnızca yayına çıkış kapısı olarak değil, ticari işletimin devam eden bir parçası olarak görmelidir.

32 Bulguları uygulamaya dönüştürme ve yeniden test

Hazırlık raporunun ticari değeri, bir bulgunun uygulama ekibi tarafından anlaşılabilir ve doğrulanabilir bir işe dönüşmesiyle ortaya çıkar. “Veri kalitesini artırın” veya “ajan uyumunu geliştirin” gibi genel tavsiyeler çalışma başlatabilir; fakat tamamlanma ölçütü sağlamaz. Webtures’ın önerdiği bulgu kaydı, etkilenen müşteri görevini, gözlenen davranışı, beklenen davranışı, kanıtı, sorumluyu, bağımlılıkları ve kabul koşulunu birlikte içerir.

Her bulguda gözlem ile kök neden varsayımı ayrılır. Yanlış fiyatın görülmesi gözlemdir; bunun önbellek süresinden kaynaklandığı henüz araştırılması gereken bir açıklama olabilir. Çözüm önerisi varsayımı kesin bilgi gibi ele alırsa ekip yanlış katmanda çalışabilir. İlk uygulama adımı bazen kod değiştirmek değil, teklif kimliği ve güncelleme zamanını kaydederek sorunun kaynağını görünür hale getirmektir.

Temsili bir bulgunun çalışma paketine dönüşmesi

Bir testte seçilen bağlantı istasyonunun ürün sayfasında uygun görünmesine karşın sepette farklı bir varyantla oluştuğunu varsayalım. Bu gerçek müşteri sonucu değildir. Gözlem; görevde istenen ürün kimliği, seçilen varyant, sepet satırı ve kontrol zamanı ile kaydedilir. Olası nedenler katalog eşleme hatası, tarayıcıdaki varsayılan seçim veya aracı servisin yanlış kimlik göndermesi olabilir. Kanıt toplanmadan bütün kataloğun yeniden yazılması önerilmez.

İnceleme sonunda eşleme hatası doğrulanırsa çalışma paketi ilgili veri dönüşümünü, etkilenen ürün ailesini ve sorumlu ekibi belirtir. Kabul koşulu yalnızca örnek ürünün düzelmesi değildir. Aynı ailedeki diğer varyantların korunması, bulunmayan bir varyantın sessizce başka ürüne çevrilmemesi ve seçim belirsiz olduğunda ajanın durması da sınanır. Böylece düzeltme, tek bir ekran görüntüsüne göre kapatılmaz.

Önceliklendirme etki, yayılım, gerçekleşme olasılığı, kanıt güveni ve çözüm bağımlılıklarını birlikte değerlendirmelidir. Kritik yetki kusurları bu sıralamanın önüne geçer. Geniş ürün grubunu etkileyen bir kimlik problemi, tek bir açıklama eksikliğinden daha erken ele alınabilir. Bununla birlikte hızlı düzeltilebilen düşük riskli işler, uzun mimari projelerin bitmesini beklemek zorunda değildir. Yol haritası, acil koruma, kök neden düzeltmesi ve kalıcı iyileştirmeyi ayırarak uygulanabilir hale gelir.

Yeniden test önce aynı hatayı yakalayan görevi, ardından ilgili komşu senaryoları kapsar. Başlangıç koşulları ve başarı tanımı korunur; değişen sürüm kaydedilir. Bir kez başarılı çalışması aralıklı bir sorunun tamamen çözüldüğünü göstermez. Önceden belirlenen tekrar düzeni uygulanır; hata yeniden üretilemiyorsa sonuç “çözüldü” yerine “izlemede” kalabilir. Kapatma kararı, kanıt ve yetkili kabul kaydıyla tamamlanır.

Canlıya geçiş için geri dönüş planı da uygulama işinin parçasıdır. Özelliğin kapatılması, eski veri akışına dönülmesi, açık sepetlerin ele alınması ve bekleyen finansal durumların uzlaştırılması gerektiğinde kimin ne yapacağı belirlenir. Geri alma tek başına bütün ticari etkileri silmez; önceki işlemlerin durumu ayrıca kontrol edilir.

Sonuçta rapor bir defalık belge olmaktan çıkar; kurumun görev, bulgu, değişiklik ve doğrulama geçmişini tutan çalışma düzenine dönüşür. Webtures’ın bu alandaki ayırt edici katkısı, teknik ayrıntıyı yönetimin kararına ve uygulama ekibinin kabul koşuluna aynı anda bağlayabilmesidir. Bu katkı, önerinin sayısından çok, kanıtla kapanan sorunlar ve korunan ticari doğruluk üzerinden değerlendirilmelidir.

33 Sektörlere göre uygulama modelleri

Agentic Commerce hazırlığı, her işletmede aynı görevin otomatikleştirilmesi anlamına gelmez. Ürünün nasıl seçildiği, yanlış seçimden doğan maliyet ve müşterinin hangi kararı kendisine saklamak istediği, uygulama modelini belirler. Bu nedenle sektör sınıflandırması teknoloji tercihinden önce gelmelidir. İlk kapsam, işletmenin belirgin bir sorunu çözebildiği ve sonucun doğrulanabildiği bir müşteri görevine dayanmalıdır. Aşağıdaki modeller gerçekleşmiş müşteri vakaları değil, uygulama tasarımında kullanılabilecek önerilerdir.

Giyim ve ayakkabıda varyant ve uygunluk

Bu kategoride temel görev, aynı ürün ailesinin içinden doğru beden, renk ve satın alınabilir varyantın seçilmesidir. Ürün başlığının bulunması, bu görevin tamamlandığını göstermez. Beden tablosunun hangi modele ait olduğu, ölçülerin nasıl alındığı, kalıp bilgisi ve ürünün kullanım amacı birlikte değerlendirilir. Kullanıcının belirttiği zorunlu koşullar ile esnetebileceği tercihlerin ayrılması gerekir.

İlk pilot belirli bir koleksiyonda doğru varyantı test sepetine taşımayı hedefleyebilir. Yanlış beden eşlemesi, tükenmiş varyant, renk değişimi ve iade koşullarının yanlış aktarılması ayrı sonuçlar olarak incelenir. Beden bilgisi yetersizse soru sormak uygun davranıştır. Ürün açıklamasından kişiye kusursuz uyum sonucu çıkarmak değildir. Uygulamanın ticari değerlendirmesinde sipariş sayısının yanında varyant kaynaklı destek ve iade nedenlerinin değişimi de izlenmelidir.

Elektronikte teknik uyumluluk

Elektronikte müşterinin ihtiyacı çoğu zaman bir ürün adından daha ayrıntılıdır. Bir bağlantı aygıtının mevcut bilgisayarla, işletim sistemiyle ve monitörlerle çalışması gerekebilir. Model kodu, üretici açıklaması, paket içeriği ve gereken ek parçalar bu nedenle aynı görevde ele alınır. Benzer isimli ürünler birbirinin yerine geçirilmemelidir.

Uygun başlangıç, sınırlı bir cihaz ailesi için uyumlu aksesuar seçimi ve toplam maliyetin hazırlanmasıdır. Uyumluluk verisinin bulunmadığı durumlar görünür bırakılır. Garanti sağlayıcısı ve ürünün yeni, kullanılmış veya yenilenmiş olması seçime dahil edilir. Böylece pilot, yalnızca uygun fiyat bulma yeteneğini değil, müşterinin ihtiyacına uymayan bir siparişi önleme becerisini de değerlendirir.

Market alışverişinde ikame ve teslimat

Market senaryosunda miktar, birim fiyat, ambalaj büyüklüğü ve teslimat aralığı birlikte önem taşır. Bir ürünün yerine başka bir ürün seçmek yalnız fiyat hesabı değildir. İçerik, alerjen, marka tercihi ve saklama koşulu bakımından kullanıcı onayı gerekebilir. Bu bilgiler doğrulanamıyorsa modelin kendiliğinden eşdeğerlik kurması önlenmelidir.

İlk görev, önceden tanımlanmış alışveriş listesini belirli bütçe ve teslimat aralığı içinde hazırlamak olabilir. Eksik ürünler ayrıca gösterilir; onaylanmamış ikameler sessizce sepete eklenmez. Değişken ağırlıklı ürünler ve nihai tutarı sonradan belirlenen kalemler için tahmin ile kesin tutar ayrılır. Değerlendirme, hazırlanmış sepetin gerçek teslimat koşullarına uygunluğunu da kapsar.

B2B ve seyahatte kararın hazırlanması

B2B tedarikte başarı, ödeme tamamlamaktan önce satın alma onayına sunulabilecek bir teklif paketinin hazırlanması olabilir. Teknik şartname, miktar, birim, minimum sipariş, teslim süresi ve sözleşme koşulları birlikte ele alınır. Fiyatın müşteriye özel olması halinde kamuya açık katalog bilgisiyle kesin teklif oluşturulmaz. Talep hazırlama yetkisi ile bütçeyi bağlayan satın alma yetkisi ayrılır.

Seyahatte ilk kapsam, yolcu ve tarih koşullarıyla uyumlu seçeneklerin toplam fiyat ve iptal şartlarıyla sunulması olabilir. Aynı uçuş veya otel farklı değişiklik haklarıyla satılabilir. Bu nedenle ucuzluk tek seçim ölçütü yapılmaz. Rezervasyonun kesinleşmesi, ön ödeme veya ceza doğuran değişiklikler ayrıca yetkilendirilir. Her iki sektörde de insan onayına doğru hazırlanmış devir, kendi başına değerli bir sonuçtur.

34 Türkiye ve sınır ötesi ticaret

Türkiye için hazırlık değerlendirmesi, yerli ve yabancı platformları tek bir erişim varsayımı altında toplamamalıdır. Satıcının kuruluş ülkesi, kullandığı ödeme hesabı, teslimat noktası, alıcının bulunduğu yer ve hedef AI kanalı ayrı alanlardır. Bu alanların her birleşimi farklı bir uygulama kapsamı doğurabilir. İlk yönetim kararı, hangi ticari koridorun değerlendirileceğinin belirlenmesidir.

Türkiye içinde satış yapan bir işletmede başlangıç, ürünlerin doğru anlaşılması ve güncel ticari koşullarla mağazadaki izinli işlem aşamasına taşınması olabilir. Sınır ötesi satışta buna dil, para birimi, adres, vergiler, taşıma ve satış sonrası hizmet eklenir. Bir ürünün farklı dilde açıklamasını yayınlamak, aynı ürünün ilgili ülkeye satılabilir veya teslim edilebilir olduğunu kanıtlamaz.

Yerel koşulların veri modeline aktarılması

Türkçe görevler gündelik ifadeleri ve yerel alışveriş beklentilerini kapsamalıdır. Taksit, mağazadan teslim, belirli ilçeye gönderim, sipariş kesim saati ve iş günü ifadeleri aynı biçimde yorumlanmayabilir. Ürün sayfasındaki genel teslimat açıklaması ile adres girildikten sonra oluşan teklif ayrı değerlendirilmelidir. Kampanya koşulu ödeme yöntemine veya müşteri grubuna bağlıysa, görev bu bilgiyi istemeli ya da indirimli tutarı kesinleştirmemelidir.

Yerel e-ticaret yazılımının API sunması bütün ticari işlevlerin dışarıya açıldığı anlamına gelmez. Kullanılan paketin, sürümün ve sözleşmenin hangi sorguları veya değişiklikleri desteklediği sağlayıcıdan teyit edilmelidir. Özel geliştirme gerekiyorsa bakım sorumluluğu, sürüm değişiklikleri ve veri aktarım sınırları teklifin parçası yapılır. İnternette bir entegrasyon duyurusuna rastlanmaması da sağlayıcının bu yeteneği kesinlikle sunamadığı sonucunu doğurmaz.

Ödeme ve satış sonrası teyit

Ödeme hizmeti sağlayıcısıyla doğrulanacak kayıt; desteklenen işlem türlerini, ek kullanıcı doğrulamasını, yetki süresini, para birimini, iptal ve iade davranışını içermelidir. Her akışın aynı doğrulama yöntemini kullandığı varsayılmamalıdır. Müşteriye devir gerekiyorsa bu adım, ürün ve toplam tutar korunarak tasarlanmalıdır. Güvenlik adımını kaldırarak tamamlanan akış hazırlık başarısı sayılmaz.

Sınır ötesi senaryoda müşterinin ödeyeceği toplam ile satıcının tahsil edeceği net tutar farklı hesaplar olabilir. Kur dönüşümü, taşıma bedeli, sınırda oluşabilecek ücretlerin sorumlusu ve iade adresi açıklaştırılır. Belirsiz ek ücretler sıfır kabul edilmez. Teslimat vaadi, ilgili güzergâh ve taşıyıcının doğrulanmış koşullarına dayanmalıdır; iç pazardaki süre dış pazara aynen aktarılmamalıdır.

Kişisel veriler, tüketici bilgilendirmeleri, ticari sözleşmeler ve ülkeye özgü yükümlülükler işletmenin ilgili uzmanlarınca değerlendirilir. Teknik rapor bu değerlendirmenin yerini almaz; hangi veri ve işlemin hangi taraflar arasında taşındığını görünür kılar. Güncel belge, hesap onayı ve sözleşme kapsamı birlikte doğrulandığında, kurum genel bir ülke varsayımı yerine somut bir akış üzerinden karar verebilir.

Ülke ve dil sürümleri için ürün eşleme kaydı tutulması da önemlidir. Aynı model farklı pazarlarda farklı paket içeriği, ölçü birimi veya garanti koşuluyla sunulabilir. Çeviri süreci bu farkları düzleştirmemelidir. Görev seti yalnızca Türkçe soruların başka dile çevrilmesinden oluşmaz; hedef pazardaki adres, tarih, beden ve para biçimleriyle yeniden hazırlanır. Her yeni pazar, mevcut ürünün dağıtım alanı olarak görülmeden önce kendi ticari koşullarıyla değerlendirilir.

35 Birim ekonomi ve yatırım kararı

Agentic Commerce programının ekonomik değeri, yeni bir kanala bağlanmış olmakla oluşmaz. Hangi görevin daha az hatayla tamamlandığı, müşteriye ne kazandırdığı ve işletmenin hangi maliyetini değiştirdiği açıklanmalıdır. Teknik kabul ölçütleri ile ekonomik kabul ölçütleri birbirini tamamlar. Güvenilir bir akış pahalı olabilir; ucuz bir akış ise yanlış siparişler nedeniyle toplam maliyeti yükseltebilir.

Başlangıç yatırımı ile sürekli gider ayrılmalıdır. Ürün verisinin düzenlenmesi, entegrasyon geliştirme, test ortamı, görev seti ve ekip eğitimi başlangıç yatırımına dahil edilebilir. Model ve araç kullanımı, veri servisleri, izleme, insan değerlendirmesi, bakım ve destek ise çalışma sürdükçe oluşur. Test, geliştirme ve canlı kullanım giderleri ayrı tutulduğunda, pilot maliyetinin ilerideki işlem maliyeti sanılması önlenir.

Başarısız görevler maliyet hesabından çıkarılmaz. Sonuç alınamayan çağrılar, tekrarlar ve insan incelemesi tüketilen kaynaklardır. Buna karşılık aynı gider farklı başlıklarla iki kez sayılmamalıdır. Model maliyetinde bulunan tekrar çağrıları, ayrıca başarısızlık maliyeti adıyla yeniden yazılmaz; farklı olan inceleme veya müdahale emeği eklenebilir.

Temsili katkı hesabı

Aşağıdaki hesap, yöntem açıklamak için oluşturulmuş tamamen temsili bir senaryodur. Webtures sonucu, fiyat teklifi veya beklenen müşteri getirisi değildir. Örnekte indirim ve iade düzeltmeleri yapılmış, vergiler hariç net gelir 1.000.000 TL kabul edilmiştir. Ürün maliyeti de satılan ve iade edilmiş ürünlerin muhasebe etkileri işlendikten sonraki tutardır.

Toplam gider 800.000 TL, katkı ise 200.000 TL olur. Katkının net gelire oranı yüzde 20’dir. İade tutarı net gelirde düşüldüğü için tekrar giderleştirilmez; tabloda yalnızca iadenin ek operasyon gideri bulunur. Bu hesap kurumun genel giderlerini, finansmanını ve başlangıç yatırımını içermediğinden net kâr olarak adlandırılmaz.

Yatırım kararı bu katkının ne kadarının gerçekten ek olduğunu sorgulamalıdır. Başka kanalda yapılacak satışın yeni akışa taşınması, satış tutarının tamamını ilave kazanç haline getirmez. Karşılaştırılabilir dönem, müşteri grubu veya uygun deney tasarımı kullanılarak etki ayrıştırılır. Düşük kullanım ve yüksek müdahale ihtiyacı senaryoları da değerlendirilir. Kontrollü testin başarılı olması ekonomik sonucu kanıtlamaz; daha kapsamlı bir canlı değerlendirmeyi gerekçelendirebilir.

Nakit etkisi ayrıca değerlendirilmelidir. Siparişin oluşması, tahsilatın kullanılabilir hale gelmesi ve iade ihtimalinin kapanması farklı zamanlara yayılabilir. Kurum kanalın ödeme vadelerini, stok bağlama etkisini ve destek için ayırdığı kapasiteyi kendi kayıtlarıyla hesaplamalıdır. Katkısı olumlu görünen bir akışın başlangıçta ek işletme sermayesi gerektirmesi mümkündür. Bu nedenle yatırım bütçesi yalnız yazılım geliştirme bedeliyle sınırlanmaz; geçiş dönemindeki operasyon kapasitesi de plana dahil edilir.

36 Doksan günlük pilot ve on iki aylık yol haritası

Dönüşüm programı, bitiş tarihi belirlenmiş bir entegrasyon projesi olarak tasarlanırsa veri ve platform değiştikçe geçerliliğini yitirebilir. Bu nedenle ilk pilotun amacı hem belirli görevleri iyileştirmek hem de tekrar kullanılabilir bir işletim düzeni kurmaktır. Buradaki doksan gün ve on iki ay, örnek planlama ufuklarıdır. Erişimler, tedarikçi desteği ve kurumun değişiklik takvimi gerçek süreyi belirler.

İlk doksan gün

İlk iki haftada ticari hedef ve son işlem aşaması seçilir. Bir ürün grubu, belirli görev aileleri ve sınırlı ortamla başlanır. Veri sahipleri, teknik sorumlular ve müşteri kabulünü verecek kişi atanır. Gerekli belgeler veya test erişimleri eksikse bu dönem tamamlanmış sayılmaz; takvimin geri kalanı gerçek bağımlılığa göre düzenlenir.

Üçüncü ve dördüncü haftalarda başlangıç değerlendirmesi yapılır. Ürün verisi, ticari koşullar ve görev sonuçları birlikte incelenir. Kolay görevlerin iyi sonucu, zor görevlerin başarısızlığını gizlememelidir. Dönem sonunda yönetimin elinde hedef kapsam, gözlenen kusurlar, bilinmeyenler ve öncelikli düzeltmeler bulunur. Beklenmeyen kapsam büyümesi ayrıca karara bağlanır.

Beşinci ve sekizinci haftalarda seçilen düzeltmeler uygulanır. Her işin sahibi, kabul koşulu ve geri dönüş planı belirlenir. Veri tutarlılığı gibi mevcut müşteriye de fayda sağlayan işler ile belirli bir kanala özgü entegrasyonlar ayrılır. Böylece henüz onaylanmamış bir kanal, bütün programın ilerlemesini durdurmaz.

Son haftalarda aynı görevler yeniden çalıştırılır; hata, ret ve insan devri senaryoları da değerlendirilir. Kabul edilen kapsam için canlı izleme hazırlığı yapılır. Sonuç, otomatik olarak yaygınlaştırma değildir. Genişletme, sınırlı kullanımda kalma veya bağımlılık çözülene kadar durma seçeneklerinin her biri geçerli olabilir.

Pilot sonrasında genişleme

Dördüncü ile altıncı ay arasında pilotta oluşan veri sözleşmeleri, görev tanımları ve olay kayıtları standartlaştırılabilir. Yeni bir kategoriye geçerken mevcut testler doğrudan kopyalanmaz; kategoriye özgü yanlış karar maliyeti ve ticari koşullar eklenir. İşletim gideri ve insan müdahalesi artışı izlenir.

Yedinci ile dokuzuncu ay arasında, sağlayıcı desteği ve ekonomik gerekçe varsa yeni kanal veya işlem aşaması değerlendirilebilir. Ödeme, iptal ve iade gibi durum değiştiren yeteneklerin her biri ayrı kabul gerektirir. Bir ülke veya hesapta doğrulanmış akış başka pazarda yeniden incelenir.

Son çeyrekte yatırımın toplam katkısı, bakım yükü ve tedarikçiye bağımlılığı değerlendirilir. İşe yaramayan özellikler korunmak zorunda değildir. Ekip, hangi yeteneği kendi bünyesinde tutacağını, hangi hizmeti dışarıdan alacağını ve hangi geliştirmeyi erteleyeceğini kararlaştırır. Yıl sonu hedefi her işlemi otonomlaştırmak değil, seçilen ticari görevleri sürdürülebilir biçimde işletmektir.

Yol haritasında her genişleme için bir geri dönüş kararı da bulunmalıdır. Yeni kategori beklenenden fazla insan müdahalesi gerektirirse kapsamın geçici daraltılması mümkün olmalıdır. Bir entegrasyonun ticari şartları değiştiğinde müşteriye hizmet veren alternatif akış korunur. Böylece program, tek bir sağlayıcının takvimine veya deneme özelliğine bağımlı hale gelmez. Teknik kapasite, ekip zamanı ve müşteri etkisi aynı genişleme kararında birlikte ele alınır.

37 Kurumsal işletim modeli ve sorumluluklar

Agentic Commerce, ürün bilgisiyle başlayıp fiyat, stok, teslimat ve ödeme sistemlerine uzandığı için tek bir ekibin sahiplenmesiyle sürdürülemez. Bununla birlikte bütün ekiplerin ortak sorumluluğu ifadesi de kararları belirsizleştirebilir. Her ticari hedef için bir hesap verebilir iş sahibi, her sistem için bir uygulama sorumlusu ve her kabul kararı için belirlenmiş bir yetkili bulunmalıdır.

Ticari sponsor, programın hangi müşteri ihtiyacını ve ekonomik sonucu hedeflediğini belirler. Teknoloji sorumlusu entegrasyon sınırlarını, ortamları ve sürüm planını yönetir. Ürün verisi ekibi niteliklerin kaynağını ve güncelliğini sahiplenir. Fiyatlama ve operasyon ekipleri kampanya, stok ve teslimat koşullarının uygulanabilirliğini doğrular. Finans ve ödeme ekipleri ticari kayıtların tutarlılığını ve mutabakatı izler.

Karar hakkının açık tanımı

Bir ürün açıklamasını düzeltme yetkisi ile bir kampanyayı değiştirme yetkisi aynı kişide olmak zorunda değildir. AI tarafından hazırlanan değişiklik önerisi de bu ayrımı ortadan kaldırmaz. Kurum hangi değişikliğin otomatik uygulanabileceğini, hangisinin iş sahibi onayı gerektirdiğini ve hangisinin yalnızca öneri olarak kalacağını tanımlamalıdır. Yetki kapsamı, göreve uygun en dar sınırda tutulur.

Müşteri hizmetleri işletim modelinin son aşaması olarak görülmemelidir. Bir ajan yanlış koşul aktardığında müşteri çoğunlukla destek ekibine gelir. Bu ekip, hangi bilginin hangi anda sunulduğunu ve gerçekte hangi işlemin oluştuğunu görebilmelidir. Gereksiz kişisel veri gösterilmeden anlaşılır olay özeti sağlanması, hem çözüm süresini hem de kurum içi koordinasyonu iyileştirebilir.

Değişiklik ve istisna yönetimi

Katalog, kampanya veya sağlayıcı güncellemesi yeni bir değerlendirme ihtiyacı doğurabilir. Her değişiklikte bütün görevleri çalıştırmak yerine etkilenen akışlar belirlenir; kritik ortak bileşen değiştiyse kapsam genişletilir. Testin ne zaman tekrarlanacağı, yalnızca takvime değil değişikliğin niteliğine bağlanır.

İstisna yönetiminde sorun önemine göre sahiplenilir. Yanlış açıklama, işlem tutarsızlığı ve yetki ihlali aynı kuyrukta aynı hızla ele alınmamalıdır. Akışı durdurma yetkisinin kimde olduğu ve yeniden açmak için hangi kanıtın gerektiği önceden belirlenir. Sorunun geçici olarak kaybolması, tekrar test ve kayıt ihtiyacını ortadan kaldırmaz.

Çalışma ritmi kısa uygulama toplantıları ve daha seyrek yönetim değerlendirmeleriyle kurulabilir. Uygulama toplantısı açık kusurları ve bağımlılıkları çözer. Yönetim değerlendirmesi ise ticari katkı, maliyet ve kapsam kararlarına odaklanır. Ekip gelişimi, yalnızca araç kullanım eğitiminden oluşmaz; veri sorumluluğu, belirsizlik yorumlama ve doğru zamanda insana devir becerilerini de kapsar.

Personel veya tedarikçi değiştiğinde bilgi ve yetki sürekliliği ayrıca korunmalıdır. Görev tanımları, veri sözleşmeleri ve kabul kayıtları bireysel hesaplarda kalmamalıdır. Ayrılan kişinin erişimleri gözden geçirilirken açık işlerin sorumlusu yeniden atanır. Yeni ekip üyesi hangi alanın doğrulandığını, hangi koşulların kapsam dışı olduğunu ve hangi değişikliğin yeniden test gerektirdiğini kayıtlardan anlayabilmelidir. Bu düzen, pilotu yapan kişilere bağımlılığı azaltır.

38 Webtures hizmet modeli ve somut teslimatlar

Webtures’ın bu alandaki hizmet yaklaşımı, araştırmayı uygulanabilir değişikliklere bağlayan bir dönüşüm programı olarak kurulmalıdır. Temel vaat; izinli teknik denetim, kontrollü görev testi, öncelikli düzeltme planı ve değişiklik sonrasında yeniden değerlendirmedir. Müşteriye sunulan değerin kanıtı, genel bir AI anlatısından çok hangi görevin hangi kapsamda çalıştığının gösterilmesidir.

Hizmetin ilk aşaması kapsamlandırmadır. Müşterinin sistemleri, ürün grubu, hedef kanalı ve tamamlanmasını istediği işlem anlaşılır. Kamuya açık bilgilerle yapılan ön inceleme ile izinli sistem değerlendirmesi birbirinden ayrılır. Hızlı tarama, ayrıntılı işlem güvenilirliği hakkında kapsamının ötesinde bir sonuç üretmemelidir.

Değerlendirmeden uygulamaya teslim zinciri

Tam değerlendirme, yalnızca yönetici sunumundan oluşmaz. Teknik ekiplerin çalışabileceği kayıtlar ve yöneticinin karar verebileceği özet birlikte hazırlanır. Her bulgunun etkilediği görev, kanıtı, önceliği ve kabul koşulu bulunur. Erişilemeyen alanlar sonucun dışında bırakılır; bilinmeyen durumun olumlu sonuç gibi görünmesine izin verilmez.

Uygulama aşamasında veri ve içerik düzenlemeleri, entegrasyon işleri ve ödeme altyapısı değişiklikleri ayrı uzmanlıklar olarak planlanır. Webtures’ın kendi ekibi, müşteri ekibi ve uygulama ortağının yapacağı işler sözleşmede görünür olmalıdır. Kullanılabilir uzmanlık ve entegrasyon yeteneği doğrulanmadan bütün geliştirmelerin hazır biçimde sunulduğu ileri sürülmemelidir.

Ticari kapsam ve kabul

Fiyatlama; yalnızca sayfa sayısı veya çalışma saatiyle değil, ürün kapsamı, görev çeşitliliği, ortam, erişim türü, değerlendirme emeği ve tekrar sıklığıyla ilişkilendirilebilir. Sabit kapsamlı değerlendirme ile değişken bağımlılıklara sahip geliştirme aynı fiyat varsayımına bağlanmamalıdır. Ek kapsam gerektiğinde müşteriye etkisi açıklanır ve çalışma buna göre güncellenir.

Sürekli hizmetin amacı raporu belirli aralıklarla yeniden üretmek değildir. Kritik veri değişikliklerini, işlem kusurlarını ve maliyet sapmalarını izleyerek müşterinin müdahale etmesini sağlamaktır. Gereksiz uyarılar azaltılır; uyarının kime gideceği ve ne yapılacağı tanımlanır.

Hazırlık değerlendirmesi, belirli koşullar için verilmiş bir görüş olarak sunulur; genel sertifika veya bütün ajanlarda başarı garantisi olarak değil. Müşterinin belirli bir ürün satın alması olumlu değerlendirme koşulu yapılmaz. Bu yaklaşım, hizmetin ticari hedefleriyle araştırmanın güvenilirliğinin birlikte korunmasını sağlar.

Hizmet sonunda müşteri, çalışmayı devam ettirebilecek bir devir paketi almalıdır. Güncel görev seti, açık kusurlar, erişim sahipleri, değişiklik geçmişi ve tekrar test yöntemi anlaşılır biçimde aktarılır. Sürekli hizmet sona erdiğinde hangi izlemelerin duracağı ve müşterinin hangi sorumlulukları devralacağı açıklanır. Teslimatın kalitesi, yalnızca danışmanlık süresince kullanılan ekranlarla değil, müşterinin bu bilgiyle kendi kararlarını sürdürebilmesiyle değerlendirilir.

39 Brantial ile ölçüm ve uygulama ilişkisi

Webtures’ın danışmanlık programı ile Brantial’ın ürün gelişimi arasında kurulabilecek ilişki, bulguların düzenli izlenmesini ve uygulama sonuçlarının karşılaştırılmasını kolaylaştırabilir. Bu raporda tarif edilen ticaret görevleri, yeni entegrasyonlar ve onaylı değişiklik akışları bir ürün geliştirme önerisidir. Kullanım kapsamı doğrulanmadan mevcut Brantial yetenekleri veya tamamlanmış müşteri uygulamaları olarak sunulmaz.

Önerilen tasarımda görünürlük verisi ile görev doğrulaması birbirini tamamlar. Bir ürünün AI yanıtında yer alması araştırmanın başlangıcı olabilir; ürünün güncel fiyatla seçilmesi veya doğru sepete ulaşması farklı kayıtlar gerektirir. Bu nedenle ürün ekranında görünürlük, bilgi doğruluğu ve işlem sonucu ayrı gösterilmelidir. Tek puanla birleştirme, hangi iyileştirmenin gerekli olduğunu gizleyebilir.

Geliştirme sırasının belirlenmesi

İlk ürün adımı, görev ve kanıt kayıtlarını ilişkilendiren bir çalışma alanı olabilir. Görev tanımı, kullanılan veri sürümü, gözlenen kusur, önerilen değişiklik ve yeniden test sonucu birlikte tutulur. Böyle bir temel, doğrudan sipariş işleme yeteneği gerektirmeden danışmanlık sürecini destekleyebilir.

İkinci adım, müşterinin izin verdiği veri kaynaklarıyla okuma entegrasyonlarıdır. Amaç farklı sistemlerde aynı ürünün hangi kayıtlarla temsil edildiğini ve verinin ne zaman değiştiğini izleyebilmektir. Her bağlantıda veri kapsamı, erişim süresi ve müşteri sorumlusu belirlenir. Bütün katalog veya müşteri verisinin sırf ileride kullanılabilir diye aktarılması gerekmemelidir.

Daha sonraki aşamada düzeltme önerilerinin iş akışına taşınması değerlendirilebilir. Sistem, ürün niteliğindeki tutarsızlığı gösterebilir ve yetkili kayda dayanarak öneri hazırlayabilir. Önerinin onaylanması, hedef sisteme yazılması ve sonucun yeniden okunması ayrı adımlar olarak tasarlanır. Ödeme, sipariş veya fiyat değişikliği gibi etkili eylemler için daha dar yetkiler ve ayrıca kabul gerekir.

Güvenilir ürün iddiasının sınırı

Ürün tanıtımında güvenlik belgesi, barındırma bölgesi, veri işleme kapsamı ve entegrasyon desteği ancak güncel belgelerle doğrulandıktan sonra kullanılmalıdır. Yol haritasındaki bir madde, mevcut özellik listesine taşınmamalıdır. Belirli bir müşteriye özel geliştirme de bütün hesaplarda standart özellik olduğu izlenimi vermemelidir.

Ölçüm altyapısı müşterinin verisini dışa aktarabilmesini ve bulguları kendi ekipleriyle inceleyebilmesini desteklemelidir. Webtures raporu, Brantial ekranının yorumlanmamış bir kopyasına indirgenmez. Danışmanlık değeri; ticari bağlamı açıklama, öncelik seçme ve değişikliğin sonucunu değerlendirme sorumluluğunda kalır.

Bu ilişki doğru kurulduğunda ürün geliştirme, sahada kanıtlanmış ihtiyaçlarla yönlendirilebilir. Ancak bu rapor kapsamında saha testi yapılmadığı için özellik öncelikleri doğrulanmış talep dağılımı olarak kabul edilmez. İlk uygulamalarla öğrenilecek ihtiyaçlar, ürün yatırım kararlarını ayrıca beslemelidir.

Geliştirilecek özelliklerin kendi kabul ölçütleri de bulunmalıdır. Bir uyarı modülü için yalnız bulunan sorun sayısı değil, yanlış uyarı yükü ve sorunun doğru kişiye ulaşması değerlendirilir. Bir öneri modülünde önerinin uygulanabilirliği ve dayandığı kanıt önemlidir. Entegrasyon sayısının artması tek başına ürün başarısı değildir; bağlantıların güncel kalması, kapsamının açık olması ve kopmaların anlaşılır biçimde bildirilmesi gerekir. Böylece ürün ölçümü de müşteri görevleriyle aynı doğrulama disiplinini taşır.

40 Yönetim kararları ve geleceğe hazırlık

Agentic Commerce konusunda yönetimin ihtiyacı, tek bir gelecek tahminine inanmak değil, farklı gelişmelere uyum sağlayabilecek karar düzenini kurmaktır. Pazarın benimseme hızı, platformların ticari şartları ve müşterilerin yetki devretme isteği farklı yönlerde gelişebilir. Kurumun hazırlığı, bu belirsizlikleri saklamadan ölçülebilir işler üretebilmesine dayanmalıdır.

İlk karar, hangi görevin iyileştirileceğidir. Belirli bir ürünün doğru bulunması, geçerli bir teklif hazırlanması ve kullanıcının onayladığı işlemin tamamlanması farklı hedeflerdir. Yönetim, hedefi açık tanımladığında gereksiz kapsam büyümesini sınırlar ve hangi ekibin hangi sonucu sahiplenmesi gerektiğini netleştirir.

İkinci karar, ekonomik ve operasyonel kabul sınırıdır. Hangi maliyet düzeyinde devam edileceği, hangi hata türünün akışı durduracağı ve hangi durumda insan desteğinin yeterli olduğu önceden belirlenir. Kabul ölçütleri yalnız başarılı demo sonrasında oluşturulursa yatırımın değerlendirilmesi kolayca iyimser varsayımlara bağlı hale gelir.

Birden fazla geleceğe uygun yatırım

Ajan aracılı ticaretin yavaş ilerlediği senaryoda ürün verisi, teklif tutarlılığı ve destek kayıtlarının iyileştirilmesi mevcut müşterilere hizmet eder. Belirli platformların hızla büyüdüğü senaryoda kanal erişimi, ticari koşullar ve veri paylaşımı önem kazanır. Daha açık bir ekosistemde ise taşınabilir görev tanımları ve farklı arayüzlere uyarlanabilen entegrasyonlar değerli olabilir. Bu senaryolar kesin öngörüler değil, yatırımın dayanıklılığını sorgulamak için düşünme araçlarıdır.

Kurum kendi ajanını geliştirme kararını da aynı disiplinle vermelidir. Ürün verisine ve müşteri ihtiyacına hâkim olmak, otomatik olarak ayrı bir ajan ürünü işletmeyi gerektirmez. Böyle bir yatırımın sürekli bakım, dağıtım, destek ve güvenilirlik yükü vardır. Önce hangi görevde mevcut seçeneklerin yetersiz kaldığı ve işletmenin hangi bilgisiyle fark yaratacağı gösterilmelidir.

Öğrenmenin yönetilmesi

Yönetim, programdan yalnızca başarı oranı istememelidir. Kapsamı, başarısızlık nedenlerini, doğrulanamayan alanları ve ticari katkıyı birlikte görmelidir. Son dönemde hangi varsayımın değiştiği ve bunun yol haritasını nasıl etkilediği düzenli değerlendirilmelidir. İlerlemeyi durdurma veya kapsamı daraltma kararı, kanıta dayanıyorsa öğrenmenin geçerli bir sonucudur.

Bu raporun önerdiği temel yatırım, doğrulanabilir bir çalışma döngüsüdür: sınırları belirlenmiş görevi seçmek, izinli incelemeyle mevcut durumu anlamak, onaylı değişikliği uygulamak ve sonucu yeniden test etmek. Döngüye ekonomik değerlendirme ve açık sorumluluk eklendiğinde, hazırlık tek seferlik bir kontrol olmaktan çıkar.

İleride sektör karşılaştırması yayımlanacaksa, özel müşteri değerlendirmesiyle kamusal araştırmanın amaçları ayrılmalıdır. Katılım izni, örnekleme yöntemi ve karşılaştırılabilir kapsam baştan belirlenir. Gönüllü küçük bir grubun sonuçları bütün Türkiye'nin durumu gibi sunulmaz. Müşteri sıralaması, hizmet satın alımından etkilenmez. Kurumun araştırma itibarı, güçlü görünen bir sonuç üretmesinden çok hangi sonucun hangi koşullarda söylenebileceğini açık tutmasına bağlıdır.

Webtures’ın bu alandaki konumu, ticaret altyapısının dönüşümünü uygulamaya taşıyan uzmanlık üzerinde kurulmalıdır. İddianın gücü kullanılan terimlerden değil, müşterinin kararını kolaylaştıran bulgulardan, uygulanabilir teslimatlardan ve sınırları açık sonuçlardan gelmelidir. Kalıcı hazırlık, bugün neyin çalıştığını bilmek ve yarın değiştiğinde nasıl karşılık verileceğini belirlemektir.

Ek A Denetim kontrol listesi

Bu liste ilk denetimin planlanması için 48 kontrol içerir. Bir platformun resmi şartnamesi veya bütün işletmeler için zorunlu sertifikasyon listesi değildir. Her kontrol için uygulanabilirlik, gözlem, kanıt, sorumlu ve sonraki adım kaydedilir. Bir kontrolün uygulanmaması ile başarısız olması ayrı durumlar olarak tutulur. Kritik kusurlar tamamlanan kontrol sayısıyla dengelenmez.

Kanal ve yetki uygunluğu

• Hedef kanalın tanımı: Keşif, mağazaya devir, test sepeti veya doğrudan işlem yollarından hangisinin değerlendirildiği açıkça yazılır.
• Hesap kabulü: İşletmenin başvuru, erişim ve canlı kullanım durumları ilgili hesap üzerinden doğrulanır. Teknik dokümana erişebilmek kabul kanıtı değildir.
• Coğrafi kapsam: Satıcı hesabı, alıcı konumu ve teslimat bölgesi ayrı alanlar halinde tutulur; bunların aynı ülke olduğu varsayılmaz.
• Ürün uygunluğu: Ürün kategorisi, ürün durumu, kişiselleştirme ve abonelik gibi koşullar hedef kanalın kapsamıyla karşılaştırılır.
• Yetki kapsamı: Okuma, sepet oluşturma, sipariş tamamlama ve iade gibi eylemler için verilen izinler ayrı incelenir.
• Test sınırı: Ortam, zaman penceresi, çağrı sınırı, mali etki ve sonlandırma sorumlusu deneme başlamadan kayda alınır.

Ürün keşfi ve kimliği

• İhtiyaç temelli keşif: Marka adı içermeyen gerçekçi talepler için uygun ürünlerin bulunabildiği kontrol edilir.
• Satıcı kimliği: Aynı ürünün farklı satıcı tekliflerinin karışmadığı ve ilgili koşulların doğru satıcıya bağlandığı doğrulanır.
• Ürün ailesi ve varyant: Renk, beden, kapasite veya paket miktarı değiştiğinde kimliğin ve ticari kaydın tutarlı kaldığı sınanır.
• Kimlik eşlemesi: PIM, ERP, feed, sayfa ve checkout kimliklerinin aynı ürünü gösterdiği eşleme kaydıyla kontrol edilir.
• Dil ve ölçü birimi: Türkçe ifade, model kodu, yerel beden sistemi ve ölçü birimi değişimlerinin anlam kaybı yaratıp yaratmadığı incelenir.
• Eksik bilgi davranışı: Ürün niteliği bilinmediğinde sistemin kesinlik uydurmak yerine açıklama istemesi veya belirsizliği belirtmesi değerlendirilir.

Veri doğruluğu ve güncelliği

• Alan sahibi: Fiyat, stok, ürün özelliği ve teslimat için belirleyici kaynağın hangi sistem olduğu kayıt altına alınır.
• Dağıtım tutarlılığı: Görünür sayfa, yapılandırılmış veri, feed ve API yanıtı aynı tarihli ürün kaydıyla karşılaştırılır.
• Güncelleme gecikmesi: Kaynak değişikliğinin hedeflerde ne zaman görüldüğü ölçülür; ortalamanın yanında geciken ve ulaşmayan değişiklikler gösterilir.
• Stok anlamı: Fiziksel stok, satılabilir stok, ayrılmış stok ve teslimat bölgesine uygun stok birbirinden ayrılır.
• Sürüm ve zaman: Veri sürümü, kaynak zamanı ve aktarım zamanı ayrı tutulur; yalnız son aktarım tarihine dayanılmaz.
• Tutarsızlık çözümü: Kaynaklar çeliştiğinde kullanılacak davranış, sorumlu ekip ve gerekirse görevi durdurma kuralı tanımlanır.

Teklif ve ticari koşullar

• Toplam maliyet: Ürün, zorunlu ücretler, kargo ve uygulanabilir indirimlerle müşterinin ödeyeceği toplam yeniden hesaplanır.
• Kampanya uygunluğu: Kullanıcı, ürün, sepet, zaman ve ödeme yöntemi koşulları sağlanmadan indirim vaat edilmediği kontrol edilir.
• Teslimat geçerliliği: Tarih ve ücretin gerçek adres, stok noktası ve taşıma seçeneğine bağlı olduğu doğrulanır.
• Teklif süresi: Süresi geçen veya değişen teklifin yeniden üretildiği ve gerektiğinde yeniden onaya sunulduğu sınanır.
• İade ve garanti: İlgili ürünün durumu, kapsamı ve istisnaları doğru ticari kayıtla eşleştirilir.
• Ticari sınırlar: Miktar, harcama ve marj kurallarının yetkili işletme politikalarıyla uyumlu uygulandığı incelenir.

Görev ve işlem yürütme

• Görev sözleşmesi: Zorunlu koşullar, tercihler, izinli araçlar ve beklenen son durum testten önce yazılır.
• Araç yanıtı: Başarı, hata ve eksik bilgi durumlarının işlem devamını doğru yönlendirdiği kontrol edilir.
• Sepet durumu: Ajanın bildirdiği ürün, miktar ve toplamın gerçek sepet kaydıyla eşleştiği doğrulanır.
• Yinelenen istek: Ağ hatası veya yeniden deneme nedeniyle aynı iş niyetinin fazladan sipariş oluşturmadığı sınanır.
• Zaman aşımı: Yanıt kaybolduğunda önce mevcut durumun sorgulandığı, yeni mali işlemle kör tekrar yapılmadığı kontrol edilir.
• İşlem kapanışı: Sipariş, ödeme ve stok durumlarının birbirleriyle tutarlı olduğu ya da açık bir bekleyen durum taşıdığı doğrulanır.

Güvenlik ve kullanıcı kontrolü

• Kimlik doğrulama: Ajan sağlayıcısı, kullanıcı ve işletme hesabı kimliklerinin birbirine karıştırılmadığı değerlendirilir.
• En az yetki: Her aracın yalnız görev için gerekli veri ve eylemlere eriştiği sınanır.
• Yetki iptali: İptal veya süre aşımından sonra yeni durum değiştiren işlemlerin durduğu kontrol edilir; uzlaştırma erişimi ayrıca ele alınır.
• Hassas veri: Kişisel verinin, erişim anahtarlarının ve ödeme bilgilerinin model çıktısı veya gereksiz loglara sızmadığı incelenir.
• Dış içerik yönlendirmesi: İzinli test ortamında ürün veya yorum içeriğinin sistem kurallarını değiştirmediği doğrulanır.
• İnsan devri: Ek doğrulama gerektiğinde kullanıcının anlaşılır biçimde devralabildiği ve onayın kapsamının korunduğu sınanır.

Ölçüm ve uzlaştırma

• Ortak işlem kimliği: Görev, teklif, sepet, ödeme ve sipariş arasında izlenebilir bağlantı kurulur.
• Trafik kanıtı: Gözlenen, teknik olarak doğrulanan, çıkarılan ve bilinmeyen ajan ilişkileri ayrı etiketlenir.
• Webhook işleme: İmza, tekrar teslim, sıra değişimi ve gecikme durumlarının doğru işlendiği sınanır.
• Doğru payda: Başarısız veya belirsiz uygun girişimlerin yalnız sonucu olumsuz olduğu için ölçümden çıkarılmadığı kontrol edilir.
• Maliyet kaydı: Başarılı görevlerle birlikte başarısız denemeler, tekrarlar ve insan desteğinin maliyeti de hesaba katılır.
• Sonuç ayrımı: Keşif, sepet, sipariş, tahsilat, net gelir ve ek gelir farklı göstergelerle izlenir.

İşletim ve iyileştirme

• Sorumlu ekip: Her veri alanı, entegrasyon ve bulgu için karar verecek kişi veya ekip bellidir.
• Değişiklik kaydı: Model, araç, platform, katalog ve ticari kural sürümlerindeki değişiklikler izlenir.
• Tekrar test: Düzeltme sonrası ilgili görev ve etkilenebilecek komşu akışlar yeniden değerlendirilir.
• Olay yönetimi: Kritik kusurda durdurma, müşteri etkisini belirleme, uzlaştırma ve yeniden açma sorumlulukları tanımlıdır.
• Geri alma planı: Yeni entegrasyon devreden çıktığında mevcut müşteri yolculuğunun nasıl sürdürüleceği belirlenir.
• Düzenli gözden geçirme: Kapsam, kabul koşulları ve ekonomik sonuçlar belirli dönemlerde yeniden değerlendirilir.

Ek B On iki görev ailesi için uygulama kartları

Aşağıdaki görevler önerilen pilotun başlangıç kütüphanesidir. Test verileri ve parasal tutarlar temsilidir. Her işletmede ürün, kanal, izin ve doğrulama yöntemi yeniden tanımlanır. Görev ailesi, aynı amacı sınayan birden fazla olumlu ve olumsuz senaryo içerebilir. Pilot matrisindeki 12 aile bu kümeden seçilebilir. Bölüm 28’deki 720 yürütme hesabında her aile ve uygun erişim yolu için tek bir görev sözleşmesi seçilir ve üç kez çalıştırılır; buradaki bütün alt senaryolar bu sayıya dahil değildir.

İhtiyaçtan doğru ürüne ulaşma

Görev, açık ürün adı vermeden kullanım ihtiyacına uygun seçenekleri bulmaktır. Örneğin belirli bir bilgisayarda iki ekran kullanmak isteyen müşteriye uygun bağlantı istasyonu aranabilir. Başarı için üreticiye dayalı uyumluluk ve gerekli bağlantı özellikleri doğrulanır. Benzer isim veya yüksek puan tek başına yeterli değildir. Hangi bilginin bulunamadığı kayıt altına alınır. Uygun ürün yoksa bunu söylemek doğru sonuçtur; kullanıcının kesin koşulunu sessizce değiştirmek kabul edilmez.

Varyant ve miktar seçme

Görev, ürün ailesi içinden belirlenen renk, beden, kapasite veya paket miktarını seçmektir. Deneme, ürün sayfasından feed’e ve test sepetine kadar aynı kimliği izler. Başarı kanıtı ürün fotoğrafı değil, yetkili varyant kaydı ve sepet satırıdır. İstenen varyant stokta yoksa yakın bir varyant kullanıcı onayı olmadan seçilmez. Çoklu miktarda sipariş, satılabilir stok ve paket adediyle birlikte değerlendirilir.

Alternatifleri karşılaştırma

Görev, aynı ihtiyacı karşılayan seçenekleri ortak ölçütlerle karşılaştırmaktır. Birinde kargo dahil fiyat, diğerinde kargosuz fiyat kullanmak yanlış karşılaştırmadır. Karşılaştırma ölçütleri testten önce belirlenir; veri bulunmayan alanlar boş veya belirsiz olarak gösterilir. Ajanın kendi ürettiği bir kalite puanı üretici özelliği gibi sunulmaz. Sonuç, kullanıcının önceliklerini ve seçenekler arasındaki gerçek farkları açıklamalıdır.

Bütçeye uygun teklif hazırlama

Görev, zorunlu ücretler dahil belirli toplamı aşmayan bir teklif hazırlamaktır. Temsili 4.000 TL sınırında ürünün 3.900 TL olması, 150 TL kargoyla bütçeye uyduğu anlamına gelmez. Kampanya kodunun geçersizleşmesi ve para biriminin değişmesi ayrı olumsuz senaryolardır. Başarı güncel toplam ve teklif süresi üzerinden değerlendirilir. Ajan bütçeyi aşıyorsa kullanıcıdan yeni yetki almalı veya işlemi durdurmalıdır.

Teslimat koşulunu karşılama

Görev, belirlenmiş adrese ve tarihe uygun teslimat seçeneği bulmaktır. İş günü ile takvim günü, hazırlık süresi ile taşıma süresi ayrılır. Ürün sayfasındaki genel teslimat metni gerçek adres için geçerli teklifin yerine geçmez. Başarı, uygulanabilir teslimat seçeneği ve ilgili koşullarla doğrulanır. Uygun teslimat bulunamadığında daha geç seçeneğin sessizce kabul edilmesi başarısızlıktır; alternatif için açık devir yapılmalıdır.

Test sepeti oluşturma

Görev, onaylanan ürünleri ve miktarları sandbox sepetine eklemektir. Beklenen son durum sepet olduğu için ödeme veya sipariş başlatılması kapsam ihlalidir. Aynı iş niyetine ait yeniden deneme, miktarı istenmeden artırmamalıdır. Ayrı ve yetkili bir ekleme isteğinin etkisi ayrıca değerlendirilir. Sepetteki ürün kimlikleri, fiyat, indirim ve teslimat koşulları görev sözleşmesiyle karşılaştırılır. Sepet süresi dolarsa sistem yeni durumun nasıl oluşturulacağını açıkça belirtmelidir.

Kullanıcıya alışverişi devretme

Görev, araştırma veya sepet hazırlama sonrasında kontrolü kullanıcıya vermektir. Kullanıcı doğru mağaza ve doğru varyantla devam etmelidir. Bir bağlantının açılması tek başına başarılı devir değildir; seçilen miktarın, geçerli teklifin ve gerekli bağlamın korunduğu doğrulanır. Oturum sınırları, uygulama içi tarayıcı ve giriş gereksinimleri test edilir. Kullanıcının yeniden seçim yapması gerekiyorsa bu sürtünme kayıt altına alınır.

Yetkili işlemi tamamlama

Görev yalnız uygun test ortamında ve açık yetkiyle yürütülür. Onaylanan satıcı, ürün, tutar, para birimi ve süre kontrol edilir. Başarı, ödeme ve sipariş kayıtlarının hedeflenen son durumla eşleşmesidir. Token alınması veya API’nin olumlu yanıtı tek başına satın alma kanıtı değildir. Ek doğrulama istenirse kullanıcıya devir beklenir. Provizyon, tahsilat ve sipariş kabulü ayrı sonuçlar olarak tutulur.

Stok ve fiyat değişimine uyum sağlama

Görev devam ederken izinli test verisinde fiyat veya stok değiştirilir. Amaç sistemin değişikliği fark edip geçerli teklif üretmesini sınamaktır. Eski fiyatla görüntüleme ile eski fiyat üzerinden işlem yapılması farklı kusurlardır. Başarı, güncel bilginin alınması ve değişiklik onay kapsamını aşıyorsa yeniden izin istenmesidir. Uygun seçenek kalmadığında görev durmalıdır. Yeniden test, yalnız değişen ürünü değil benzer varyantları da kapsar.

Kesinti ve tekrardan güvenli dönme

Görev sırasında yanıt kaybı, gecikme veya tekrar teslim kontrollü biçimde oluşturulur. Ajanın önce mevcut durumu öğrenmesi ve aynı iş niyeti için fazladan işlem üretmemesi beklenir. İşlem kimliği ile ödeme ve sipariş kayıtları karşılaştırılır. Başarı için hem nihai durumun doğru olması hem yan etkilerin sınırda kalması gerekir. Kayıp yanıtın ardından iki kez oluşmuş fakat sonradan biri iptal edilmiş sipariş, hatasız işlem diye raporlanmaz.

Yetkiyi aşan talebi durdurma

Bu olumsuz test ailesi başka müşteri hesabı, süresi dolmuş izin, farklı satıcı, bütçe aşımı veya iptal edilmiş yetki örneklerini kapsar. Beklenen sonuç güvenli ret ya da uygun insan devridir. Reddin kendisi hata değildir. Başarı, yetkisiz durum değişikliğinin oluşmamasıyla doğrulanır. Durdurulan girişimler olumlu satın alma başarı oranına eklenmez; ayrı güvenlik göstergesi olarak raporlanır.

Satış sonrası görevi yürütme

Görev, test siparişinin durumunu öğrenmek, uygun koşullarda iptal talebi hazırlamak veya yetkili kısmi iadeyi yürütmek olabilir. Önce kullanıcı ile sipariş ilişkisi ve işlem kapsamı doğrulanır. İade talebinin alınması, ürünün kabul edilmesi ve paranın geri gönderilmesi farklı durumlardır. Başarı, görevin hedeflediği duruma göre belirlenir. Yanlış kaleme veya yanlış tutara uygulanan işlem, müşteri mesajı doğru görünse bile başarısız sayılır.

Ek C Uygulama kayıtları ve kabul şablonları

Şablonlar, değerlendirmeyi farklı ekipler arasında devredilebilir hale getirmek için kullanılır. Hassas bilgi yerine referans kimlikleri yazılır. Görev kayıtları, müşteri verisinin gereksiz kopyalarını oluşturan yeni bir depoya dönüşmemelidir.

Kapsam kaydı

Bir kapsam kaydı işletmeyi, iş hedefini, hedeflenen son işlemi, ürün grubunu, kanalı, ortamı ve zaman aralığını tanımlar. İzin verilen erişimler ve eylemler ayrı yazılır. Ortamın üretimden farklı olduğu noktalar belirtilir. Yetkiyi veren kişi, test sahibi ve durdurma sorumlusu kayıtla ilişkilendirilir. Erişim sağlanamayan alanlar açık kalır; bunlar olumlu sonuç diye işaretlenmez.

Bulgu kaydı

Temsili bulgu örneği

Bir üründe mavi 256 GB varyantı seçildiği halde test sepetine siyah 128 GB varyantının eklendiği varsayılsın. Bu gerçek bir müşteri bulgusu değildir. Kanıt, seçim kaydı ile sepet satırının farklı varyant kimliklerini göstermesidir. İlk araştırma, URL parametresi ile checkout kimliği arasındaki eşlemeye yönelir. Düzeltme sonrasında aynı seçim ve diğer varyantlar tekrar sınanır. Görsel rengin düzelmesi yeterli değildir; sepetin ürün kimliği de doğru olmalıdır.

Canlıya geçiş karar kaydı

Karar kaydında kapsamdaki ürünler, kullanıcılar, kanallar ve izin verilen işlem sınırı yer alır. Açık kritik kusur bulunup bulunmadığı, geri alma yöntemi, gözlem süresi ve olay sorumlusu belirtilir. Pilotun hangi koşulda genişletileceği veya durdurulacağı önceden yazılır. Kararı veren kişiler teknik hazırlık ile ticari kabulün kendi sorumluluklarını ayrı onaylar.

Değişiklik sonrası değerlendirme kaydı

Model, protokol sürümü, feed şeması veya kampanya kuralı değiştiğinde etkilenen görev aileleri belirlenir. Değişiklik önce kontrollü ortamda değerlendirilir. Sonuçlar aynı kabul koşullarıyla karşılaştırılır. Başarı oranının yükselmesi güvenlik kusurunu kapatmaz; maliyet azalması da yanlış ürün oranının artmasını tek başına haklı çıkarmaz. Değişiklik kararı görev kalitesi, kullanıcı yetkisi ve ekonomik sonuç birlikte görülerek verilir.

Ek D Ortak dil ve sık sorulan yönetim soruları

Temel terimler

Ajan: Belirli bir amacı gerçekleştirmek için araç ve veri kaynaklarıyla çalışabilen yazılım sistemi. Yetki alanı göreve göre değişir.

Görev sözleşmesi: İhtiyaç, kısıt, izin, ortam, beklenen sonuç ve doğrulama yönteminin birlikte yazıldığı kayıt.

İş niyeti kimliği: Aynı müşteri hedefi için yapılan tekrarların ortak ticari işlemle ilişkilendirilmesini sağlayan kimlik.

Teklif: Belirli ürün, miktar, fiyat ve ticari koşulların geçerlilik sınırlarıyla sunulması.

Feed: Ürün bilgilerinin bir kanalın beklediği veri sözleşmesine uygun toplu veya düzenli aktarımı.

Yetkili kaynak: Bir veri alanı için işletmenin doğru kabul ettiği sistem ve sorumluluk kaydı. Her alanın kaynağı aynı olmayabilir.

Sandbox: Testlerin kontrollü veriler ve sınırlı etkilerle yürütüldüğü ortam. Üretimle aynı davranışı kendiliğinden garanti etmez.

Idempotency: Aynı isteğin belirlenen koşullarda tekrar yürütülmesinin ek etki üretmesini önleyen davranış. Kapsamı ve süresi sözleşmeye bağlıdır.

Uzlaştırma: Görev, ödeme ve sipariş kayıtlarının hangi gerçek sonucun oluştuğunu belirlemek üzere karşılaştırılması.

İnsan devri: Görevin gerekli bilgi ve kontrolle kullanıcıya veya yetkili operatöre aktarılması.

Tokenizasyon: Hassas ödeme bilgisinin yerine belirli kullanım kuralları olan bir temsil kullanılması. Genel harcama izniyle eş anlamlı değildir.

Gözlemlenebilirlik: Sistemin davranışını olay, kayıt ve ölçümler üzerinden açıklayabilme yeteneği.

İyi bir web sitesi tek başına yeterli midir

İyi bir web deneyimi değerli bir temeldir. Ancak ürün kimliği, güncel teklif, izinli araç erişimi ve işlem güvenilirliği ayrıca değerlendirilmelidir. Tersine, teknik bir API’nin bulunması da kullanıcıya devir deneyimini önemsiz yapmaz. Değerlendirme hedeflenen yolun bütünü üzerinde yapılır.

Her işletme kendi ajanını geliştirmeli midir

Hayır. Bazı işletmeler için mevcut kanallara doğru katalog ve işlem yetenekleri sunmak yeterli olabilir. Kendi ajanını geliştirme kararı, çözülmek istenen görev ve işletim maliyetiyle gerekçelendirilmelidir. Yeni arayüz geliştirmek, ürün veri sorunlarını çözmenin yerine geçmez.

Bütün protokolleri uygulamak gerekli midir

Hayır. Protokol seçimi hedef kanal, yetenek ve sağlayıcı koşullarını izlemelidir. Kullanılmayan entegrasyonlar bakım ve güvenlik yükü oluşturabilir. Önce desteklenecek görev belirlenir, sonra bu görev için gerekli teknik sözleşmeler seçilir.

Bir hazırlık puanı yeterli olur mu

Tek puan ilerleme anlatımını kolaylaştırabilir fakat kapsamı ve kritik kusurları saklamamalıdır. Ödeme yetkisi ihlali yüksek içerik puanıyla dengelenemez. Karar; kanal, ürün grubu, görev, kanıt düzeyi ve açık engellerle birlikte verilmelidir.

Hazırlık tamamlandıktan sonra çalışma biter mi

Hayır. Ürün, stok, kampanya, model ve platform değişiklikleri daha önce çalışan görevi etkileyebilir. Tekrar test ve sorumluluk düzeni hazırlığın bir parçasıdır. Kontrol sıklığı veri değişim hızına ve işlemin etkisine göre belirlenir.

İlk yönetim toplantısında hangi karar alınmalıdır

İlk karar, bütünü otomatikleştirme hedefinden önce hangi müşteri görevinin hangi kapsamda değerlendirileceğidir. Bu kararın yanında veri sahibi, teknik sorumlu, izin sınırı ve başarı kanıtı belirlenmelidir. Sonraki yatırım, bu görevin ortaya çıkardığı somut ihtiyaçlar üzerinden genişletilebilir.