Ekip Randevu Takviminde Sahiplik Devri Nasıl Planlanır?

Randevu takviminde sahiplik devri neden ayrı bir iştir?

Ekip randevu takviminde sahiplik devri, bir çalışana takvimi görme veya etkinlik düzenleme yetkisi vermekten farklıdır. Özellikle klinik, danışmanlık ve servis ekiplerinde kullanılan ortak ikincil takvim, bir kişinin hesabına veri sahibi olarak bağlı kalabilir. Kişi ekipten ayrılırken yalnızca yeni çalışana paylaşım izni vermek, veri sahipliği sorununu çözmez. Google Calendar API için Haziran 2026'da yayımlanan sürüm notu, Google Workspace yöneticilerinin aynı kuruluş içindeki ikincil takvimlerin sahipliğini programlı biçimde devredebileceğini söylüyor. Bu imkânın sınırı önemlidir: birincil kişisel takvim, farklı kuruluşlar arasında devir veya silinmiş bir takvimin kurtarılması aynı işlem değildir.

Pratik yanıt şu: Önce takvimin gerçekten ikincil ve aktif olduğunu, ardından yeni veri sahibinin doğru Workspace kuruluşunda bulunduğunu, sonra da randevu bağlantılarının ve entegrasyonların devri kaldırıp kaldırmadığını kontrol edin. API çağrısı başarılı görünse bile iş akışının kesintisiz olduğunu ayrıca test edin.

Veri sahibi, takvim yöneticisi ve randevu sorumlusu

Bir işletmede bu üç rol farklı kişiler olabilir. Veri sahibi takvimin hesap düzeyindeki sahipliğini taşır. Takvim yöneticisi paylaşım izinlerini düzenleyebilir. Randevu sorumlusu ise günlük kayıtları girer, iptal eder ve müşteriyle iletişime geçer. Bu rolleri tek bir “admin” etiketi altında toplamak, personel değişiminde kimin hangi işi devralacağını belirsizleştirir. İkincil takvim için yeni veri sahibi seçerken yalnız teknik erişime bakmayın; hesabın uzun süre açık kalması, görevin kurum içinde sürdürülebilir olması ve gerektiğinde yedek sorumlunun belli olması gerekir.

Özel etkinlikleri kimlerin göreceği ayrı bir izin tasarımıdır. Sahiplik devri tüm gizlilik kararlarını otomatik olarak yeniden düzenleyen bir sihirli düğme değildir. Ekibiniz özel randevu ayrıntılarını farklı rollerde gizleyecekse randevu takviminde özel etkinlik yetkisi yazısındaki erişim ayrımını ayrıca uygulayın. Böylece sahiplik sürekliliği ile günlük görünürlük birbirinden bağımsız denetlenir.

Devir öncesi envanteri çıkarın

İlk liste, takvim kimliği ve mevcut veri sahibiyle başlar. Sonra takvime bağlı rezervasyon sayfası, otomatik hatırlatma, web formu, CRM kaydı, personel bildirimleri ve varsa üçüncü taraf entegrasyonları ekleyin. Her bağlantı için “takvim kimliğine mi, eski sahibin e-posta adresine mi, yoksa kişisel erişim anahtarına mı bağlı?” sorusunu sorun. Aynı takvim kimliğiyle devam edilse bile eski hesabın kimliğine bağlı bir otomasyon çalışmayı bırakabilir. Bu nedenle devirden önce gerçek bir test randevusu oluşturup hangi sistemlere düştüğünü kaydetmek gerekir.

Müşteri verisi taşıyan etkinliklerde test için gerçek kişisel bilgi kullanmayın. Örnek isim ve kontrollü bir e-posta adresiyle ilerleyin. İşlem gününde eski personelin hesabını hemen kapatmak yerine, kuruluşun erişim ve saklama politikasına uygun bir geçiş penceresi planlayın. Bu pencere içinde yeni sorumlunun rezervasyon oluşturma, düzenleme ve iptal akışını görmesini sağlayın. Takvim sahipliği ile toplantı davetiyesindeki düzenleyen rolünün aynı kavram olduğunu varsaymayın; kritik etkinlikleri ayrıca kontrol edin.

API yolunun koşullarını doğru okuyun

Google'ın transferOwnership yöntem dokümanı, işlemin Google Workspace kuruluşu içindeki kullanıcılar arasında ikincil takvim için olduğunu belirtiyor. Çağrıyı yapan kişinin “Manage Calendars” yönetici ayrıcalığına ve uygun Calendar yetkilendirme kapsamına sahip olması gerekiyor. İstekte useAdminAccess değeri true olmalı. Devredilecek takvim aktif olmalı; devre dışı veya silinmiş takvimler bu yöntemle aktarılamıyor. Hedef kullanıcı da newDataOwner alanıyla belirtiliyor. Bu şartlar yoksa otomasyon “bir kez daha dene” döngüsüne girmemeli; eksik koşulu açık hata olarak göstermeli.

Her işletme için API geliştirmek zorunlu değildir. Az sayıda takvim kullanan bir ekip, Google Takvim arayüzündeki sahiplik aktarımını tercih edebilir. Google Takvim yardımında yalnız ikincil takvimlerin sahipliğinin aktarılabildiği ve yeni sahibin kabul adımı anlatılıyor. Çok sayıda takvim, düzenli personel devri veya merkezi kayıt gereksinimi varsa yönetici kontrollü otomasyon mantıklı olabilir. Kararı, takvim sayısı kadar denetim ve hata yönetimi ihtiyacı belirler.

Güvenli uygulama akışı

Önce talebi yetkili kişi açmalı ve eski-yeni veri sahibi ile takvim kimliğini yazılı olarak doğrulamalıdır. Ardından takvimin aktifliği ve kuruluş içi hedef hesabın uygunluğu kontrol edilir. Uygulama, yalnız gerekli yetkiyle çalışmalı; kullanıcı e-posta adreslerini ve erişim belirteçlerini gereksiz loglara dökmemelidir. İşlem sonucu kaydedilirken takvim kimliği, işlem zamanı, onaylayan rol ve başarı/başarısızlık durumu yeterli olabilir. Gizli anahtarın kendisi kayıt altına alınmaz.

Devir sonrası aynı takvimde örnek bir randevu oluşturun. Web formundan kayıt düşüyor mu, iptal edildiğinde CRM durumu değişiyor mu, hatırlatma doğru kişiye mi gidiyor, bakın. Paylaşım listesini ve özel etkinlik görünürlüğünü kontrol edin. Daha sonra eski hesabın erişimi kuruluş politikasına göre daraltılır. Hata varsa önce otomasyonun hangi adımda durduğunu belirleyin: yetki eksikliği, yanlış takvim kimliği, pasif takvim veya hedef hesabın kurum dışında olması farklı çözümler ister. Başarısızlıkta eski hesabı hemen silmek toparlanma seçeneğini de zorlaştırabilir.

Birden fazla şube veya ekip aynı takvimi kullanıyorsa takvim adından sahiplik sonucu çıkarmayın. Aynı isimli iki ikincil takvim olabilir; kimliklerini ve bağlı rezervasyon adreslerini tek tek karşılaştırın. Devir planında geri dönüş sorumlusu ve müşteriye yanlış hatırlatma giderse izlenecek iletişim yolu da bulunmalıdır. Böyle bir olayda önce hatalı otomasyonu durdurmak, sonra kayıt kaynağını düzeltmek gerekir; sahipliği tekrar tekrar değiştirmek sorunu büyütebilir.

Ne zaman dışarıdan çözüm desteği gerekir?

Tek takvimli basit ekipte yazılım projesi açmak gereksiz olabilir. Fakat randevu web sitesi, CRM ve hatırlatma servisiyle birleşiyorsa, veri sahibi değişimi yalnız Calendar ayarı olarak kalmaz. Bağlantıların hangi hesapla yetkilendirildiği, hatanın nasıl izleneceği ve personel ayrılışında hangi sırayla işlem yapılacağı tasarlanmalıdır. Webinle'nin otomasyon yazılımları hizmeti bu tür süreç akışını değerlendirmek için ilgili hizmet sayfasıdır. İhtiyaç anlatırken kullanılan takvim türünü, bağlantı sayısını ve ayrılan personelin rolünü teklif formunda belirtmek, gerçekten gereken kapsamın belirlenmesini kolaylaştırır.