Üç bina, 640 daire, dört farklı tedarikçiden gelen teklifler ve masanın üzerinde birbirine hiç benzemeyen dört fiyat. Biri daire başına aylık lisans veriyor, diğeri bina başına sabit ücret, üçüncüsü "modül" bazlı, dördüncüsü ise kurulum bedelini gizleyip üç yıllık toplamı yazmış. Değerlendirme komitesi ilk toplantıda fark eder: sorun tedarikçilerde değil, RFP'de. "Sakinler için modern bir dijital deneyim sunulmalıdır" cümlesi bir gereksinim değildir; her tedarikçinin kendi ürününü tarif etmesine izin veren bir davettir.
Bu yazı, bir sakin deneyimi RFP'sini karşılaştırılabilir teklifler üretecek şekilde yazmak için pratik bir çerçeve sunuyor. Amaç şablon vermek değil; hangi maddelerin sözleşme sonrasında para ve zaman kaybettirdiğini, hangilerinin baştan yazılması gerektiğini göstermek.
Çoğu RFP, "mobil uygulama, kapı erişimi, arıza bildirimi, ödeme" gibi bir özellik listesiyle başlar. Tedarikçiler bu listeye "evet" der ve gerçek fark demo gününe kadar görünmez. Bunun yerine gereksinimleri kim için çalıştığına göre ayırın:
Her katmanda gereksinimi "sistem X yapabilmelidir" değil, "kullanıcı Y, Z koşulunda şunu tamamlayabilmelidir" biçiminde yazın. Örnek: "Sakin, arıza talebini fotoğraf ekleyerek 60 saniye içinde oluşturabilmeli ve talebin hangi ekibe atandığını uygulamadan görebilmelidir." Bu cümle demo sırasında test edilebilir; "kullanıcı dostu arıza modülü" ifadesi edilemez.
Her gereksinimin yanına bir öncelik etiketi koyun ve bu etiketin puanlamaya nasıl yansıdığını RFP'nin içinde açıklayın. "Zorunlu" maddede eksik olan teklif elenir; "tercihli" maddeler ağırlıklı puan alır; "gelecek" maddeler yalnızca yol haritası sorusuna dönüşür ve fiyatlandırılmaz. Tedarikçiler bu ayrımı görmediğinde her şeyi zorunlu sayar ve fiyatı buna göre şişirir, ya da tam tersine yol haritasındaki bir özelliği bugün varmış gibi anlatır.
Bir uygulama notu: "Gelecek" sütununa yazdığınız her madde için tedarikçiden tarih değil, hangi mevcut müşterinin bu özelliği talep ettiğini sorun. Referanssız yol haritası maddesi pazarlama slaytıdır.
Saha deneyimi olan herkes bilir: sözleşme sonrası ilk büyük tartışma neredeyse her zaman entegrasyon üzerinedir. RFP'de "mevcut kapı erişim sistemiyle entegre olmalıdır" yazılır, tedarikçi "evet" der, sonra ortaya çıkar ki entegrasyon tek yönlüdür, gecelik toplu aktarım yapar ve erişim sisteminin üreticisi kendi API'sine ayrı lisans ücreti istemektedir. Bu üç ayrıntı sözleşmede yoksa, faturası size gelir.
Her entegrasyon için en az şunları yazdırın:
Portföyünüzde ziyaretçi sayım veya ortak alan kullanım verisi toplayan sensörler varsa, bu veriyi de entegrasyon listesine ekleyin. Spor salonu, çamaşırhane veya lobi doluluğunu sakin uygulamasında göstermek küçük bir özellik gibi görünür ama bakım planlaması ve ortak alan ücretlendirmesi için gerçek karar verisi üretir. Sayım tarafında doğruluk beklentisini de yazılı hale getirin: sözleşmesel alt sınır %96, ışık ve yerleşim koşulları elverdiğinde tipik olarak %98–99. Sabit bir "%99 garanti" ifadesi vaat eden tedarikçiden koşulları sorun.
Yeni sisteme geçiş, boş bir veri tabanıyla başlamaz. Aktif kira sözleşmeleri, depozito bakiyeleri, açık arıza talepleri, geçmiş ödeme kayıtları ve KVKK kapsamında onay geçmişi taşınmak zorundadır. RFP'de taşınacak veri kümelerini, kayıt sayısını (yaklaşık da olsa) ve kaynak formatı belirtin. Tedarikçiden şunu isteyin: taşıma için ayrı bir bedel ve ayrı bir süre. "Kurulum dahil" ifadesinin arkasına gizlenen taşıma, projeyi en sık geciktiren kalemdir.
Uygulayıcıların bildiği ama RFP'lerde nadiren görülen bir madde daha: tedarikçinin demo ortamı her zaman önceden hazırlanmıştır. Değerlendirme aşamasında kendi binanızdan gerçek bir daire karışımı, gerçek aidat yapısı ve birkaç gerçek arıza senaryosu yükletmeyi şart koşun. Kendi verinizle yapılmayan demo, ürünün değil sunum ekibinin yeteneğini ölçer.
Tedarikçinin barındırdığı bulut mu, kendi özel bulutunuz mu, yoksa ikisi arasında seçim hakkı mı istiyorsunuz? Bu soruyu RFP'de netleştirmeden gelen fiyatlar karşılaştırılamaz, çünkü barındırma modeli hem lisans bedelini hem güvenlik sorumluluğunu değiştirir. Verinin hangi ülkede tutulduğunu, yedekleme sıklığını ve ihlal bildirim süresini yazılı isteyin.
Çıkış koşulları ise en az giriş koşulları kadar önemli. Sözleşme bittiğinde verinizi hangi formatta, kaç gün içinde ve hangi ücretle alacaksınız? Sakin uygulamasındaki hesaplar başka platforma nasıl devredilecek? Bu maddeleri ihale aşamasında sormak pazarlık gücü verir; sözleşme imzalandıktan sonra sormak ise yalnızca fiyat teklifi getirir.
Puanlama ağırlıklarını RFP'de açıklayın. Yaygın ve savunulabilir bir dağılım: işlevsel uyum %35, entegrasyon ve veri %20, uygulama planı ve referanslar %15, güvenlik ve barındırma %10, toplam sahip olma maliyeti %20. Fiyatı tek başına en yüksek ağırlığa koymak, üç yıl sonra değiştirme maliyetiyle geri döner.
Fiyat için tek bir şablon dayatın: kurulum, veri taşıma, eğitim, yıllık lisans, destek seviyesi, entegrasyon başına bedel ve daire sayısı arttığında uygulanacak kademeli fiyat. Beş yıllık toplam sahip olma maliyetini tedarikçi değil siz hesaplayın; tedarikçiden yalnızca girdileri isteyin.
Referans görüşmelerinde tedarikçinin verdiği listeyle yetinmeyin. Benzer büyüklükte, benzer yönetim modeline sahip ve en az iki yıl önce canlıya geçmiş bir müşteriyle konuşmayı şart koşun. İlk yıl herkes memnundur; ikinci yılın sorusu, yenileme dönemlerinin ve personel değişimlerinin sistemde nasıl yönetildiğidir.
Portföyünüzde hem konut hem perakende veya karma kullanımlı alanlar varsa, sakin deneyimi platformunun mevcut analitik altyapınızla aynı çatı altında yönetilebilmesi operasyonel yük azaltır. Vemco'nun 2025'te İspanyol mülk yönetimi yazılımı TecBrain'i (1995'te kurulmuş) bünyesine katması bu yönde bir adım: ziyaretçi sayım ve analitik tarafında yılların birikimi, kira ve topluluk yönetimi tarafıyla aynı veri modeline taşınıyor. Barındırılan veya özel bulut seçeneği ve mevcut sistemlerle entegrasyon yaklaşımı, RFP'de yukarıda sıralanan maddelerin çoğuna doğrudan karşılık geliyor. Yine de her tedarikçi gibi, kendi binanızın verisiyle test edilmeli.
RFP taslağınızı hazırlıyorsanız veya elinizdeki teklifleri karşılaştırmakta zorlanıyorsanız, gereksinim listenizi birlikte gözden geçirebiliriz: entegrasyon maddelerinin yazımından veri taşıma kapsamına ve puanlama ağırlıklarına kadar. Bize ulaşın, portföyünüze uygun bir sakin deneyimi RFP çerçevesi için görüşelim.