Randevu Otomasyonunda Ayrı Google Meet Bağlantısı Nasıl Üretilir?

Otomatik randevuda Google Meet bağlantısı nasıl oluşturulmalı?

Google Calendar üzerinden her yeni uzaktan randevu açıldığında, o etkinliğe özel bir Google Meet konferansı oluşturmak güvenli başlangıçtır. Önceki randevunun bağlantısını kopyalayıp yeni kayda taşımayın. Google'ın 17 Şubat 2026 tarihli Calendar API duyurusu, Meet kodunu farklı etkinliklerde yeniden kullanmanın erişim sorunlarına ve toplantı ayrıntılarının istenmeyen kişilere açılmasına neden olabileceğini söylüyor. Etkinlik başvurusu yeni konferans için conferenceData.createRequest kullanılmasını açıklıyor.

Bu öneri, bir randevu otomasyonunun yalnızca takvim kaydı oluşturmasıyla bitmediğini gösterir. Davetlinin doğru bağlantıyı alması, görüşme iptalinde eski bağlantının tekrar gönderilmemesi ve hata durumunun ekibe görünmesi gerekir. Klinik, danışmanlık veya teklif görüşmesi gibi akışlarda görüşmenin gizliliği operasyon tasarımının bir parçasıdır; bu yazı hukuki ya da klinik uygunluk iddiası taşımaz.

Randevu kaydı ile konferans kaydını ayırın

Bir randevunun en az iki durumu vardır: takvim etkinliği ve ona bağlı video konferans. Takvim etkinliği kaydedilmiş olsa bile konferans oluşturma isteği hemen tamamlanmamış olabilir. Bu nedenle kullanıcıya bağlantı içeren onay ile yalnızca saat rezervasyonu onayını aynı olay saymayın. Otomasyon, konferans oluşturma sonucunu kontrol ederek daveti uygun aşamada göndermelidir.

İş akışını “talep alındı”, “saat ayrıldı”, “konferans oluşturuldu”, “davet gönderildi” ve “katılımcı bilgilendirildi” gibi ayrı durumlarla düşünmek yararlıdır. Bu durumlar işletmenin kendi uygulama modelidir; Google'ın zorunlu durum adları değildir. Ama bir bağlantı üretilemediğinde kullanıcının ne gördüğünü ve ekibin hangi adımı tekrar edeceğini açık kılar.

API isteğinde hangi alanlara dikkat edilmeli?

Calendar API, konferans verisinin etkinliğe eklenmesi için conferenceData alanını kullanır. Yeni konferans istemek için createRequest içinde her istek için ayrı requestId üretmek gerekir. Başvuruda aynı kimlik tekrar kullanılırsa önceki isteğin yok sayılabileceği belirtilir. Etkinlik üzerinde konferans verisini oluşturup değiştirmek için ilgili istekte conferenceDataVersion=1 parametresi de gereklidir. Bunları kod içinde görünmeyen varsayımlar olarak bırakmayın; kabul testinde doğrulayın.

Konferans üretimi eşzamansız olduğundan createRequest.status sonucuna bakın. Başarılı takvim yanıtını görür görmez davet e-postasına bağlantı koymak, henüz üretilmemiş veya başarısız bağlantı gönderebilir. Uygulama belirli bir süre sonra tekrar okuyabilir, ancak tekrar deneme sayısı ve operatöre bildirim eşiği iş gereksinimine göre belirlenmelidir. Kullanıcıyı sonsuz “hazırlanıyor” durumunda bırakmayın.

İptal ve yeniden planlamada ne değişir?

Randevu başka saate taşındığında aynı etkinlik güncelleniyor mu, yoksa yeni etkinlik mi açılıyor? Bu ayrım bağlantı stratejisini etkiler. Yeni bir etkinlik oluşturuluyorsa eski etkinliğin konferans verisini kopyalamayın; yeni kayıt için yeni konferans isteği değerlendirin. Mevcut etkinlik güncelleniyorsa katılımcı, saat ve konferans bilgisinin tutarlılığını test edin. Hangi işlemin işletme için “yeniden planlama” sayıldığını süreç sahibi belirlemelidir.

İptal edilen görüşmenin davetini ve hatırlatma kuyruğunu da kapatın. Kullanıcıya eski ve yeni bağlantı aynı anda görünürse destek yükü artar. Ekip ekranında etkinlik kimliği, son güncelleme ve gönderilmiş davet sürümü görülebilmelidir. Bir kişi yanlış bağlantıyla katıldığında destek ekibinin hangi kaydın geçerli olduğunu hızla bulması gerekir.

Hatırlatmayı ne zaman göndermeli?

Hatırlatma, bağlantı hazır ve davetli listesi kesinleşmişse gönderilmelidir. Sadece takvim olayının yaratıldığı anı tetik kabul etmek hata doğurabilir. Gönderim öncesinde etkinlik hâlâ aktif mi, saat ve zaman dilimi doğru mu, Meet bağlantısı mevcut mu, alıcı listesi güncel mi diye kontrol edin. Bu denetim genel bir uygulama önerisidir; mesaj kanalı ve izin gereksinimleri işletmeye göre ayrıca belirlenir.

Birden fazla hatırlatma kanalı kullanılıyorsa her kanalın aynı güncel bağlantıyı okuduğundan emin olun. E-posta eski bağlantıyı, mesajlaşma kanalı yeni bağlantıyı taşıyorsa sorun takvim API'sinden çok entegrasyonun veri eşlemesindedir. Otomasyonu kurarken tek bir geçerli randevu kaynağı ve açık bir sürüm mantığı seçin.

Kabul testinde hangi durumlar olmalı?

İlk test, yeni randevunun yeni konferans üretmesi ve davetlinin bu bağlantıyı almasıdır. İkinci testte aynı kullanıcıya farklı saatte ikinci randevu açın ve iki konferansın farklı olduğunu doğrulayın. Üçüncü testte konferans oluşturmayı başarısızlığa zorlayın; sistemin hatayı kaydettiğini, eksik bağlantıyı göndermediğini ve ekibe iş bıraktığını görün. Sonra yeniden deneme sırasında aynı randevunun ikinci kez açılmadığını kontrol edin.

İptal, yeniden planlama, zaman dilimi farkı ve davetli değişikliği de ayrı testler olmalıdır. Özel etkinlik yetkileri veya ekip takvimi söz konusuysa özel etkinlik erişimi rehberindeki görünürlük sınırlarını ayrıca değerlendirin. Meet bağlantısı doğru olsa bile etkinlik başlığı ya da katılımcı listesi yanlış kişiye açılıyorsa akış hazır değildir.

Ölçüm ve sorumluluk nasıl kurulmalı?

Başarıyı yalnızca “takvim kaydı açıldı” sayısıyla ölçmeyin. Bağlantı oluşturma başarısı, davet teslimi, randevu iptali ve insan müdahalesi gerektiren durumlar ayrı izlenmelidir. Toplantıya katılım veya ticari sonuç gibi metrikler ölçülüyorsa veri kaynağı ve izin durumu açık olmalıdır. Elinizde bu zincir yoksa tahmini bir performans artışı yazmayın.

Süreç sahibi, teknik ekip ve müşteriyle görüşecek kişi aynı hata prosedürünü bilmelidir. Link hazır değilse kimi arayacaklar? Davetli başka bir saat gördüğünde hangi kayıt esas alınacak? Bu kararlar otomasyonun günlük kullanım kalitesini belirler.

Webinle ile randevu akışını netleştirin

Webinle'nin otomasyon yazılımları hizmeti, işletmeler için görünür ve denetlenebilir iş akışlarını kapsar. Proje görüşmesine mevcut takvim yapısını, randevu kanallarını, yeniden planlama kurallarını, hatırlatma zamanlarını ve hata sorumlularını getirmeniz, gereksinimi somutlaştırır. Böylece tek bir takvim bağlantısı mı yoksa teklif, CRM ve bildirimlerle birleşen bir süreç mi gerektiği anlaşılır.

Önce küçük bir randevu örneğiyle kabul ölçütlerini yazın: iki randevu, iki ayrı Meet bağlantısı; başarısız konferansta açık uyarı; iptal sonrası hatırlatma yok. Bu ölçütlerle Webinle'den kapsam değerlendirmesi isteyebilirsiniz. Bağlantı üretimini, kullanıcı iletişimini ve ekip müdahalesini aynı akışta düşünmek, uygulamanın sürdürülebilirliğini artırır.