Yapay zekâyla e-posta yazarken vermediğiniz sözü eklemeyin.

Üslup düzeltmesi anlamı da değiştirebilir

‘Müşteriye daha güven veren bir yanıt yaz’ dediğinizde taslağa ‘Sorunu cuma günü kesin olarak çözeceğiz’ eklenebilir. Bu cümle nazik ve kararlı görünür. Ancak cuma için onaylı bir plan yoksa okuyucuya yeni bir söz verilmiştir. Gönderim öncesi yalnızca yazım hatalarını kontrol etmek, böyle bir anlam değişikliğini yakalamaya yetmez.

İş e-postasında üç katmanı ayrı düşünün: şu anda bilinen bilgi, sizin üstlenebileceğiniz eylem ve karşı taraftan istediğiniz adım. Birinci katman kaynağa, ikinci katman yetkinize, üçüncü katman alıcının gerçekten yapabileceği işe dayanır. Yapay zekânın görevi bu sınırlar içinde anlaşılır bir taslak hazırlamaktır. Kaynağı eksik bir cümlenin daha yumuşak söylenmesi, onu doğrulanmış hale getirmez.

GOV.UK iletişim rehberi önemli bilgiyi erken vermeyi, kısa yazmayı ve alıcıdan beklenen işi açık belirtmeyi önerir. Bu ilkeler mesaj düzenine yardımcı olur. Aşağıdaki taahhüt tablosu ise bizim eğitim uygulamamızdır; belirli bir müşterinin sözleşmesi veya kurumunuzun iletişim politikası yerine geçmez.Kaynak: GOV.UK Service Manual — Planning and writing text messages and emails

Taslağa izin verilen bilgiyi hazırlayın

E1: Alıcıya gönderilen üç demo kutusundan birinin hasarlı olduğu bildirildi.
E2: Kargo incelemesi açıldı; sonuç henüz gelmedi.
E3: Yenileme veya değişim kararı verilmedi. Ücret ve teslim tarihi doğrulanmadı.
E4: Yanıtı yazan koordinatör, perşembe saat 16.00’ya kadar durum güncellemesi yapmayı üstlenebilir. İncelemenin o saatte tamamlanacağını garanti edemez.
E5: İncelemeyi sürdürebilmek için hasarlı kutunun fotoğrafı gerekiyor; alıcı bu bilgiyi henüz paylaşmadı.

Bu beş satır gerçek müşteri kaydı değildir. İsim, telefon ve adres kullanmadan mesajın anlamını sınamaya yeter. Burada koordinatöre verilen yetki, inceleme sonucunu bildiği veya değişim onayı verebildiği anlamına gelmez. Kendi örneğinizde de ‘hangi bilgiyi biliyorum?’ ile ‘hangi eylemi taahhüt edebilirim?’ sorularını ayrı yanıtlayın.

Alıcının isteğini de onayla karıştırmayın. Müşteri cuma teslimat istiyor olabilir; bu istek tek başına teslimat planı oluşturmaz. Taslağın girdisinde müşteri talebi varsa bunu talep olarak etiketleyin. İç ekipten gelen bir tahmini de aynı dikkatle ele alın. ‘Muhtemelen yetişir’ ifadesi, dışarıya kesin teslim tarihi olarak taşınmamalıdır.

Ton talebine açık anlam sınırları ekleyin

Bağlam: Hasarlı demo kutusu hakkında alıcıya yanıt hazırlıyorum.
Girdi: [E1–E5 notları].
Görev: Kısa, nazik ve açık bir e-posta taslağı yaz. Önce mevcut durumu, sonra alıcıdan gereken bilgiyi, son olarak verebileceğim durum güncellemesini belirt.
Kısıtlar: Değişim, ücret, teslim tarihi veya kesin çözüm sözü ekleme. Perşembe 16.00 taahhüdünü inceleme sonucu değil durum güncellemesi olarak yaz. Yeni neden veya suçlu üretme.
Çıktı: Konu ve mesaj; ardından her olgusal cümle için E kodu ve her taahhüdün yetki dayanağı.
Kontrol: Alıcı e-postadan, kaynakta olmayan bir sonuç veya tarih çıkarabilmemeli. Mesaj yalnızca taslaktır.

Konu: Hasarlı demo kutusu için inceleme ve sonraki adım

Merhaba,
Üç demo kutusundan birinin hasarlı olduğunu bildirdiğiniz için teşekkür ederim. Kargo incelemesi açıldı; sonucu henüz bekliyoruz.
İncelemeyi sürdürebilmemiz için hasarlı kutunun fotoğrafını paylaşabilir misiniz?
Değişim kararı ve teslim tarihi henüz netleşmedi. İnceleme o zamana kadar sonuçlanmasa da perşembe saat 16.00’ya kadar size mevcut durum hakkında bilgi vereceğim.
İyi günler.

Bu metin bir araçta çalıştırılan gerçek yanıt veya gönderilmiş e-posta değildir. E4’teki sözü koruyan açıklamalı bir örnektir. Kaynak kodlarını iç kontrol bölümünde tutabilir, alıcıya gönderilecek metinden çıkarabilirsiniz. Kodları çıkarmak iddianın dayanağını değiştirmez; kaynaklı çalışma kopyası sizde kalır. Örnekte fotoğraf paylaşımı için yeni bir portal veya bağlantı uydurulmamıştır.

Hangi cümle hangi beklentiyi yaratıyor?

Kontrol tablosu, yalnızca metnin kaynakta geçip geçmediğini sormaz. İfadenin alıcı tarafından nasıl okunacağını da inceler. ‘Perşembeye kadar size döneceğiz’ bazı bağlamlarda çözüm beklentisi yaratabilir. ‘İnceleme tamamlanmasa da durum bilgisi vereceğim’ ifadesi bu örnekte eylemi daha açık sınırlar. Her mesaja aynı uzun açıklamayı eklemek gerekmez; belirsizliği yaratan kısmı netleştirmek yeterlidir.

Modelden son bir kez ‘daha iddialı yap’ istediğinizde kontrol tablosunu tekrar uygulayın. İlk taslağı doğrulamak, sonraki üslup değişikliklerini otomatik olarak doğrulamaz. ‘İnceleyeceğiz’, ‘çözeceğiz’ ve ‘yenisini göndereceğiz’ aynı eylem değildir. Bu fiillerden biri değiştiğinde mesajın kapsamı da değişebilir. Metin üzerinde yapılan küçük düzenlemeleri anlam bakımından büyük değişiklik saymanız gereken yer burasıdır.

Son kontrolü alıcının gözünden yapın

• Alıcı, şu anda neyin bilindiğini ve neyin beklediğini ayırabiliyor mu?
• Her tarih bir istek, tahmin veya taahhüt olarak doğru etiketlenmiş mi?
• Sözü veren kişinin bu eylemi üstlenme yetkisi var mı?
• İstenen bilgi gerçekten gerekli mi; adres, bağlantı veya ek dosya uydurulmuş mu?
• Gönderilecek son sürüm, kontrol edilen sürümle aynı mı?

Küçük alıştırma: E4’ü kaldırın; koordinatör henüz bir güncelleme saati belirlememiş olsun. Bu durumda modelin perşembe 16.00 ifadesini koruması hatadır. Beklenen hareket, iç kontrol notunda güncelleme zamanını netleştirme ihtiyacını belirtmektir. ‘En kısa sürede kesin çözüm’ gibi başka bir belirsiz söz eklemek sorunu çözmez. Gönderen, uygulanabilir bir güncelleme düzeni belirledikten sonra taslağı tamamlayabilir.

Bir sonraki e-postanızda önce bilgi, taahhüt ve istek satırlarını kendiniz yazın; ardından yapay zekâdan bunları düzenlemesini isteyin. Son okumada her fiilin ve tarihin dayanağını kontrol edin. Böylece metnin tonu iyileşirken sizin vermediğiniz bir sözün araya girmediğini de görebilirsiniz.