
Bir müşteri “bu ürünün fiyatı ne kadar?” diye sorduğunda asistanın cevabı üç şeye bağlıdır: hangi ürün, hangi tarih ve hangi adet. Kaynak sayfada görünen eski bir rakam, o anki gerçek fiyat değildir. Bu yazıda canlı fiyat bilgisinin ne zaman okunabileceğini, API cevabının hangi koşullarla eşleştirileceğini ve sabit fiyat metninin neden ayrı tutulması gerektiğini ele alıyoruz. Amaç, müşteriye yanlış kesinlik vermeden doğru bilgiye ulaşmak ve ekibin fiyat kararına karışmadan süreci düzenlemektir.
Fiyat Sorusunun Koşulunu Netleştirmek
Fiyat sorusu tek başına eksik bir sorudur. Müşteri bir oda tipini, bir hizmet paketini ya da bir ürün varyantını kastediyor olabilir. Tarih değiştiğinde aynı ürünün fiyatı da değişebilir, adet arttığında birim koşul ortaya çıkabilir. Asistan bu bilgileri eksik görüyorsa önce soruyu daraltmalıdır. Bu adım yanıt uzunluğunu artırmak için değil, yanlış ürünün fiyatını göstermemek için gereklidir. Müşteriden istenen bilgi de yalnız ürün, tarih ve adet gibi işlemle ilgili olanlarla sınırlı kalmalıdır.
Koşul netleşmeden verilen her rakam, müşteri açısından bağlayıcı bir söz gibi algılanabilir. Bu yüzden iş kuralı yazılırken hangi sorunun hangi ürün kapsamında yanıtlanacağı belirlenmelidir. Örneğin genel bir paket fiyatı sayfası ile belirli bir tarihe ait canlı fiyat aynı cümlede birleştirilmemelidir. Kurulum sırasında hangi soru tiplerinde ekip onayı gerektiğini de ayırın. Böylece asistan bilinen bilgiyi açıkça söyler, bilinmeyeni ise tahmin etmeden ilgili kanala yönlendirir.
Kaynaktaki Eski Fiyatın Anlık Fiyat Olmadığını Bilmek
Kaynak sayfalar, PDF belgeler ve soru-cevap metinleri çoğu zaman belirli bir andaki fiyatı yansıtır. Bu metinler yayınlandığı günden itibaren eskimeye başlayabilir. Eski bir fiyatın kaynakta görünmesi, bugün de geçerli olduğu anlamına gelmez. Asistan talimatına bu farkı açıkça yazmak gerekir: sabit metin, son güncelleme tarihi bilinen bilgi olarak sunulmalı ve güncel durum için canlı kaynağa ihtiyaç olduğu belirtilmelidir.
Burada dikkat edilmesi gereken nokta, kaynak bilgisinin yanlış olmasından çok bağlamının eksik olmasıdır. Bir fiyat, belirli bir para birimi, kampanya dönemi veya dahil olmayan ek hizmet koşuluyla birlikte yazılmış olabilir. Bu bağlam okunmadan rakam aktarılırsa cevap teknik olarak doğru görünse de müşteriyi yanıltabilir. Kurulumda her fiyat alanının kapsamını yazılı olarak işaretlemek, sonraki görüşme incelemelerini de kolaylaştırır. Otel tarafındaki örnekler için otel chatbot rehberine bakabilirsiniz.
API Cevabında Eşleşme, Para Birimi Ve Veri Zamanı
Bağlı bir sistemden fiyat bilgisi alınacaksa önce cevabın doğru kayda ait olduğu kontrol edilmelidir. Ürün kodu, tarih aralığı ve adet ile API cevabı eşleşmiyorsa sonuç kullanılmamalıdır. Eşleşmeyen bir cevabı en yakın sonuç gibi sunmak en tehlikeli hatalardan biridir. Eşleşme yoksa asistan bunu açıkça belirtmeli ve müşteriye doğrulama yolunu göstermelidir.
Para birimi ve veri zamanı da cevabın parçasıdır. Bir fiyatın hangi para birimiyle döndüğü, hangi andaki veriye dayandığı ve sistemin ne sıklıkta güncellendiği bilinmeden müşteriye net rakam söylenmemelidir. Veri zamanı yoksa asistan bu bilginin güncel olduğunu varsaymamalıdır. Bu bilgiler görüşme notu olarak saklanırsa ekip sonradan hangi cevabın hangi koşulda verildiğini inceleyebilir.
Kapsam Ve Adet Koşulunu Ayırmak
Kapsam, fiyatın neyi kapsadığını anlatır. Bir ürünün temel bedeli ile ek hizmet, paketleme veya uygulama farkı aynı rakamda olmayabilir. Müşteriye söylenen tutarın hangi kalemleri içerdiği belirtilmezse, sonradan ortaya çıkan fark güveni zedeler. Asistan kapsam bilgisi kaynakta yoksa bunu kendisi tamamlamamalı; eksik kalemi açıkça belirtmelidir.
Adet koşulu da benzer biçimde ele alınmalıdır. Birim fiyat ile toplam tutar arasında indirim eşiği olabilir ve bu eşik her sistemde aynı şekilde çalışmayabilir. Kurulumda adet kademelerinin kaynaktan mı yoksa API üzerinden mi okunacağı önceden seçilmelidir. Karar verilmemişse asistan çoklu adet sorusunda kesin toplam vermemeli, hangi bilginin eksik olduğunu sade bir dille anlatmalıdır.
Fiyat Bilgisi İle Ödeme Ve Satış Kesinleştirmenin Farkı
Fiyat bilgisi okumak ile satış veya ödeme işlemi yapmak aynı şey değildir. Müşteri bir fiyatı öğrendiğinde bu, siparişin oluştuğu, yerin ayrıldığı ya da ödemenin alındığı anlamına gelmez. Asistan bu ayrımı konuşmada açık tutmalıdır. Bir işlemin kesinleştirilmesi için yetkili sistem yanıtı ya da ekip onayı gerekiyorsa bu adım ayrıca anlatılmalıdır.
Ödeme bilgisi istenmesi de ayrı bir risk alanıdır. Kart bilgisi, doğrulama kodu veya parola gibi veriler hiçbir fiyat sorusunda istenmemelidir. Fiyat sorusu ile ödeme sürecini tek akışta birleştirmek, müşterinin neyi onayladığını anlamasını zorlaştırır. Bu nedenle bilgi yanıtı, talep özeti ve işlem onayı üç ayrı çıktı olarak tasarlanmalıdır.
Entegrasyon Yoksa Ne Söylenmeli?
Entegrasyon kurulmamışsa asistanın canlı fiyat bilgisine erişmediği açıkça bilinmelidir. Bu durumda sabit kaynaktan yalnız genel bilgi verilebilir ve güncel fiyatın ekipten ya da resmi kanaldan teyit edilmesi istenir. Asistanın fiyatı bildiği izlenimi veren bir dil kullanılmamalıdır. Bağlantının varlığı da herhangi bir sektör sistemi için hazır olduğu anlamına gelmez; her bağlantı ayrıca değerlendirilir ve test edilir. Daha geniş çerçeve için yapay zekâ chatbot sayfasına bakabilirsiniz.
Bağlantı varsa bile hata durumu planlanmalıdır. Servis yanıt vermediğinde, süre aşımı olduğunda veya cevap beklenen alanları içermediğinde müşteriye ne söyleneceği önceden yazılmalıdır. Bu senaryolar test listesine eklenirse yayın sonrasında beklenmeyen sonuçlar daha az görülür. Kurulum sırasında hangi fiyat sorularının canlı kaynağa bağlanacağı, hangilerinin yalnız sabit bilgiyle yanıtlanacağı yazılı bir tabloda gösterilmelidir.
Fiyat Sorusunda Hangi Bilgi Kullanılır?
| Soru Türü | Kullanılacak Bilgi | Sınır |
|---|---|---|
| Genel paket açıklaması | Onaylı sabit metin ve son güncelleme tarihi | Güncel tutar olarak sunulmaz |
| Belirli tarih ve adet fiyatı | Eşleşen canlı API cevabı | Eşleşme yoksa tahmin yapılmaz |
| Ödeme veya satış onayı | Yetkili işlem akışı | Bilgi yanıtı işlem sayılmaz |
| Bağlantı hatası | Hazırlanmış bekleme ve ekip yönlendirmesi | Eski rakam canlı gibi verilmez |
Tüm sütunları görmek için tabloyu yana kaydırın.
Temsili Konuşma Örneği
TEMSİLİ bir örnek: Bir konaklama işletmesinin web asistanında, müşterinin tarih ve oda tipi sorusu üzerinden yapılan kısa konuşma.
Müşteri: Haftasonu için deluxe oda fiyatı ne kadar?
Asistan: Fiyat tarih ve oda tipine göre değiştiği için kesin bir tutar vermem uygun olmaz. Hangi tarihleri düşündüğünüzü yazarsanız bağlı sistemde eşleşen bilgiyi kontrol ederim. Bağlantı yoksa güncel fiyatı ekibimiz teyit eder.
Müşteri: Kahvaltı dahil mi, bir de kaç kişi için?
Asistan: Kahvaltının dahil olup olmadığı ve kişi sayısına göre tutarın değişebileceği bilgisi kaynakta ayrıca belirtilmemiş. Bu kalemleri teyit etmeden toplam tutar vermiyorum. Talebinizi yetkili ekibe bırakabilirim; bu, fiyatın onaylandığı anlamına gelmez.
Uygulama Adımları
- Fiyat sorusunda ürün, tarih ve adet koşullarını hangi durumda soracağınızı yazılı olarak belirleyin.
- Sabit fiyat metinlerini son güncelleme tarihi ve para birimiyle birlikte kaynak listesine ekleyin.
- API cevabının ürün kodu, tarih ve adet ile eşleştiğini kontrol eden kuralı tanımlayın.
- Eşleşme, veri zamanı veya para birimi eksikse asistanın kullanacağı açık ifadeleri hazırlayın.
- Kapsam ve adet kademelerinin kaynaktan mı API'den mi okunacağına karar verin.
- Fiyat yanıtı, talep özeti ve işlem onayını ayrı akışlar olarak test edin.
- Yayın sonrası görüşmeleri inceleyerek eski fiyat veya eksik kapsam kaynaklı yanıtları düzeltin.
Canlı fiyat ile sabit fiyat metnini ayırmak, müşteriye hem hızlı hem güvenilir bilgi vermenin temelidir. Eşleşmeyen veya eskimiş bir rakam yerine koşulunu açıklayan bir yanıt, güveni çoğu zaman daha iyi korur. Kurulum öncesinde hangi soruların canlı kaynağa bağlanacağını belirleyin. Güncel paket kapsamı için fiyatlar sayfasını inceleyebilir, işletmenize uygun kurgu için demo görüşmesi talep edebilirsiniz.
