Google Calendar Etiketleriyle Randevu Türleri Nasıl Yönetilir?
Randevu takviminde özel etiketler ne işe yarar?
Randevu otomasyonunda Google Calendar özel etiketleri, etkinlikleri yalnızca renkli göstermek için değil, ekip içinde tanımlı bir sınıflama sözlüğüyle ayırmak için kullanılabilir. Örneğin “ön görüşme”, “teknik keşif” ve “takip” gibi türler, herkesin farklı bir serbest metin yazması yerine ortak etiketlere bağlanabilir. Ancak etiket, randevunun kesinleşme kaydı, hasta verisi veya müşteri ilişkileri yönetimi sisteminin yerine geçmez. Önce hangi iş kararının takvimde görüleceğini, hangi verinin ayrı sistemde tutulacağını belirlemek gerekir.
Google'ın Calendar API sürüm notları, 7 Temmuz 2026'da özel etiket ve renk desteğinin genel kullanıma açıldığını belirtir. Resmî etiket rehberi ise takvim düzeyindeki labelProperties ile etkinlik düzeyindeki eventLabelId alanlarını ve eventLabelVersion=1 parametresini açıklar. Bu yazı bir API kurulum planıdır; tüm Google Calendar arayüzlerinde aynı görünüm veya her kullanıcı hesabında aynı yetki varsayılmaz.
Sınıflama sözlüğünü iş akışından çıkarın
İlk karar, etiketlerin hangi soruyu cevaplayacağıdır. Bir diş kliniğinde “ilk değerlendirme”, “kontrol” ve “tedavi hazırlığı” bir tür sınıflaması olabilir. Bir yazılım ajansında “tanışma”, “analiz” ve “teklif sunumu” başka bir sözlüktür. Bunları renk seçerek değil, randevuya bakan kişinin hangi sonraki adımı alacağını yazarak oluşturun. Sınıflar çok genel kalırsa ekip yine açıklama alanına döner; çok ayrıntılı olursa atama hataları artar.
Etiketler için kısa, anlaşılır adlar ve değişmeyecek kimlikler belirleyin. İsim daha sonra düzenlenebilir; entegrasyonun karar vermesi gereken şey yalnızca görünen metin olmamalıdır. “Mavi renkli olanlar tekrar aranacak” gibi bir kural, tema veya erişilebilirlik ihtiyacı değiştiğinde kırılabilir. Renk görsel yardımcıdır; iş anlamını etiket kimliği ve dokümante edilmiş eşleme taşır.
Örnek bir akışta teklif görüşmesi formdan gelir, ekip uygun zamanı onaylar, takvime “analiz” etiketiyle kaydeder ve CRM kaydına takvim etkinliği kimliğini yazar. Toplantı ertelenirse aynı müşteri kaydı ile olay bağını korumak gerekir. Bu örnek bir tasarım senaryosudur; Webinle'nin mevcut bir müşterisinde uygulandığı iddiası değildir.
API alanlarını doğru yerde kullanın
Google dokümanında etiket tanımlarının takvimin labelProperties alanında yönetildiği, etkinliğin seçilen etiketi eventLabelId ile taşıdığı anlatılır. Etiket özelliğini kullanırken ilgili isteklerde eventLabelVersion=1 verilmesi gerekir; bu modda eski colorId alanını aynı beklentiyle kullanmayın. Önce küçük bir test takviminde yeni etiketi oluşturun, etkinliğe atayın, okuyun ve kaldırın. Yalnızca oluşturma sonucunu görmek uçtan uca doğrulama değildir.
Yetki sınırını ayrıca belirleyin. Resmî rehber, takvim etiketlerini oluşturma veya değiştirme için owner erişimi gerektiğini; etkinliklere etiket atamada ise uygun yazma düzeyinin gerektiğini belirtir. Ekipte herkesin etiket sözlüğünü değiştirmesi gerekmeyebilir. Takvim sahibi, otomasyon hesabı ve randevu temsilcisi arasında kimlerin tanım değiştireceğini, kimlerin yalnızca etkinlik üzerinde seçim yapacağını ayırın.
Takvimi tümden güncelleyen bir entegrasyon, mevcut etiket listesini yanlışlıkla silebilir. Google rehberi önce takvimi okuyup mevcut listeyi düzenlemeyi, sonra güncellemeyi örnekler. Uygulamada da bu kuralı test edin: eşzamanlı bir değişiklik varsa çatışmayı fark edip yeniden okuma veya inceleme akışı çalışmalı. Etiketleri yalnızca renk paleti gibi değil, paylaşılan yapılandırma verisi gibi ele alın.
Randevu otomasyonuna bağlama adımları
Önce randevunun yaşam döngüsünü çizin: talep, onay, takvim oluşturma, hatırlatma, erteleme, iptal ve kapanış. Etiket hangi noktada atanacak? Personel değiştirdiğinde aynı mı kalacak? Müşteri gelmediğinde yeni bir tür mü seçilecek yoksa durum alanı mı değişecek? Tür ve durum birbirine karışırsa otomatik raporun anlamı bozulur. Örneğin “ilk görüşme” türü, “iptal” ise durum olabilir; tek etiket alanına her ikisini yığmayın.
Sonra kaynak sisteminizi seçin. Takvim operasyon görünümü sağlayabilir, fakat müşteri iletişim izinleri, klinik notları veya teklif geçmişi için uygun kayıt yeri ayrı olabilir. Takvim başlığına gereksiz kişisel veri yazmamak, paylaşım izinleriyle birlikte düşünülmelidir. Etiketleri hassas bilgiyi kodlamak için kullanmayın; yetkili kişiler etiketi görebilir. Randevu ekibine gösterilecek en az veriyi tanımlayın.
Üçüncü aşamada karşılıklı kontrol kurun. Formdaki tür takvime doğru yansıyor mu? Takvim etkinliği iptal edilince CRM kaydı değişiyor mu? Bir kişi etiketi elle değiştirince otomasyon yanlış e-posta veya hatırlatma gönderiyor mu? Entegrasyon kesintisinde işlem tekrarlandığında ikinci bir etkinlik oluşuyor mu? Bu senaryolar, yalnızca API isteğinin başarılı dönmesinden daha önemlidir.
Yayın öncesinde küçük bir pilot takvim kullanın. Her türden örnek randevu, yeniden planlama ve yetkisiz kullanıcı denemesi hazırlayın. Mobil ve masaüstü görünümünde çalışanların etiketi anlayıp anlamadığını sorun. Hata oranını ölçmeden “renkler süreci hızlandırdı” gibi sonuçlar çıkarmayın; gözlem ve kullanıcı geri bildirimi ayrı kaydedilsin.
Sık hatalar ve düzeltme
Etiket etkinlikte görünmüyorsa önce istek parametresi, etiket kimliği ve takvim yetkisini kontrol edin. Etkinlik oluşturuluyor ama sınıf gelmiyorsa genel bağlantı hatasından çok alan eşlemesi incelenmelidir. Mevcut renkler beklenmedik biçimde değişiyorsa colorId ile etiket modunun aynı işlemde nasıl kullanıldığını gözden geçirin. Bir kullanıcı sözlüğü değiştiremiyorsa teknik hata demeden önce sahiplik düzeyini doğrulayın.
Eski etkinlikleri toplu biçimde yeniden etiketlemek ayrı bir göç çalışmasıdır. Kayıtların başlıklarından güvenilir biçimde sınıf çıkmıyorsa otomatik tahminle hepsini değiştirmeyin. Belirsizleri “incele” kuyruğuna alın; değişiklik günlüğü ve geri dönüş listesi oluşturun. Canlı takvimde geçmiş olayların rengi değişince otomasyonun geçmiş performans verisini yeniden yorumlamadığını da kontrol edin.
İlgili hizmet ve sonraki adım
Webinle otomasyon yazılımları hizmetiyle randevu, takvim ve takip sistemlerinin sınırları birlikte tanımlanabilir. Takvimde gizli etkinlik ayrıntılarını kimlerin görebileceği ayrı bir ihtiyaçsa özel etkinlik yetkisi rehberi tamamlayıcıdır; bu yazı ise etkinlik türlerini etiketleme akışını inceler.
Bir keşif görüşmesi için mevcut randevu türlerini, takvim sayısını, kullanılan form veya CRM'i ve izin rollerini çıkarın. Böylece etiketleme gerekip gerekmediği, gereken API yetkileri ve test senaryoları gerçek iş akışına göre değerlendirilebilir. Amaç çok renk kullanmak değil, ekip için açık ve sürdürülebilir bir randevu dili oluşturmaktır.