Dijital Maket Nasıl Hazırlanır? Proje Verisinden Satışa Hazır Maketin Yolculuğu
Kısa cevap: Dijital maket iki paralel hattın birleşmesiyle ortaya çıkar: görsel hat ve veri hattı. Görsel hatta mimari projeden üç boyutlu model, kamera açıları ve kat planı görselleri üretilir; veri hattında ise bağımsız bölüm listesi, tipler, alanlar, cepheler ve şerefiye yapısı kurulur. İkisi bir araya geldikten sonra etkileşim katmanı tasarlanır ve CRM bağlantısı kurulur. Sürecin en çok gecikme yaşanan yeri modelleme değil, veri tarafıdır: envanter listesi eksik veya tutarsızsa ekran hazır olsa bile satışa alınamaz. Bu nedenle projeye başlarken ilk yapılacak iş, daire listesinin doğrulanmasıdır.
Bu yazı, dijital maketin üretim sürecini adım adım ele alıyor: hangi dosyalar gerekir, hangi aşamalardan geçilir, revizyonlar nasıl yönetilir ve teslim neyi kapsar. Terimlerin tanımı için: Sanal Maket Nedir? Bütçe kalemleri için: Konut Projesi Maket Maliyeti
Süreci anlamak neden önemli?
Dijital maket siparişi veren firmaların çoğu süreci bir görselleştirme işi gibi ele alır: proje dosyaları gönderilir, birkaç hafta beklenir, ekran teslim alınır. Gerçekte ise süreç geliştirici firmanın da içinde olduğu ortak bir çalışmadır ve tarafların sorumluluğu net değilse takvim kayar.
Süreci bilmenin üç pratik faydası vardır:
- Gerçekçi takvim. Lansmana yetişmesi gereken bir maketin ne zaman sipariş edilmesi gerektiği hesaplanabilir.
- Doğru teklif karşılaştırması. Hangi aşamaların kimin sorumluluğunda olduğu tekliflerde ayrışır.
- Gecikmelerin önlenmesi. En sık gecikme nedeni tedarikçi değil, geliştirici tarafından zamanında verilmeyen veridir.
İki paralel hat: görsel ve veri
Dijital maketi ayıran şey, iki farklı disiplinin aynı üründe buluşmasıdır.
| Görsel hat | Veri hattı | |
|---|---|---|
| Girdi | Mimari proje, cephe çizimleri, malzeme bilgisi, peyzaj | Bağımsız bölüm listesi, tipler, alanlar, cephe, şerefiye |
| Kim üretir | Görselleştirme ekibi | Geliştirici firmanın satış ve teknik ofisi |
| Çıktı | Üç boyutlu model, kamera açıları, kat planı görselleri | Daire kartlarını besleyen yapılandırılmış veri |
| Değişiklik etkisi | Cephe veya kütle değişirse yeniden üretim | Fiyat ve durum değişirse sadece veri güncellenir |
| Gecikme riski | Proje revizyonları | Listenin eksik veya tutarsız olması |
İki hattın buluştuğu nokta, her görsel öğenin bir veri kaydıyla eşleşmesidir: ekranda tıklanan daire, envanterdeki belirli bir bağımsız bölüme karşılık gelmelidir. Bu eşleşme kurulmadığında elinizde gezilebilir ama satış yapılamayan bir model olur.
Hangi dosyalar gerekir?
Tedarikçiye verilecek belgeler proje aşamasına göre değişir; ancak tipik liste şöyledir:
| Belge | Ne için kullanılır |
|---|---|
| Mimari proje (vaziyet, kat ve cephe planları) | Kütle ve blok modellemesi |
| Kat planları (daire bazında) | Daire kartlarındaki plan görselleri |
| Bağımsız bölüm listesi | Veri hattının temeli |
| Mahal listesi ve malzeme bilgisi | İç mekân görselleri ve detay bilgisi |
| Cephe malzemeleri ve renk kartelası | Modelin gerçeğe uygun görünmesi |
| Peyzaj ve vaziyet düzenlemesi | Çevre ve sosyal donatıların gösterimi |
| Varsa üç boyutlu model dosyası | Modelleme süresini kısaltır |
| Arsa ve çevre verisi | Konum, manzara ve yön bilgisi |
| Marka kimliği | Arayüz renkleri, logo, tipografi |
| Varsa drone görüntüleri ve fotoğraflar | Çevre gerçekliğinin artırılması |
Mimari ekip BIM ortamında çalışıyorsa model dosyasının paylaşılması süreci kısaltabilir. Ancak BIM modeli teknik amaçlarla üretildiği için doğrudan satış ekranına dönüşmez; görsel sadeleştirme ve optimizasyon gerekir.
Veri hattının kalbi: bağımsız bölüm listesi
Projenin en kritik girdisi, doğru hazırlanmış daire listesidir. Bu liste genellikle bir tablo olarak paylaşılır ve şu sütunları içermelidir:
- Blok, kat ve bağımsız bölüm numarası
- Daire tipi (1+1, 2+1, 3+1 gibi)
- Net ve brüt alan
- Cephe ve yön
- Balkon, teras veya bahçe bilgisi
- Kat planı dosyasının adı veya referansı
- Şerefiye katsayısı veya fiyat farkı
- Etap ve teslim dönemi
- Başlangıç fiyatı veya fiyat listesi referansı
- Satışa açık olup olmadığı
Listedeki en sık karşılaşılan sorunlar: aynı blok içinde birden fazla bağımsız bölümün aynı daire numarasını taşıması veya her bağımsız bölümün blok, kat ve daire numarasının birleşimiyle ya da benzersiz bir bağımsız bölüm koduyla tekil olarak eşleştirilememesi; net ve brüt alanların karıştırılması; kat planı dosyalarının daire numaralarıyla eşleşmemesi ve satışa kapalı dairelerin listede hiç yer almaması.
Farklı bloklarda aynı daire numarasının bulunması ise normaldir; A Blok 12 ile B Blok 12 ayrı bağımsız bölümlerdir. Sorun, sistemin bu ikisini birbirinden ayırt edememesinden doğar. Bu nedenle listede her satırın blok bilgisiyle birlikte tekil olarak tanımlanması ve tercihen benzersiz bir bağımsız bölüm kodu taşıması gerekir; aksi halde entegrasyon aşamasında eşleştirme hataları ve stok karışıklığı yaşanır.
Bu sorunlar tedarikçi tarafında çözülemez; çünkü hangi bilginin doğru olduğunu yalnızca geliştirici bilir. Bu nedenle listenin gönderilmeden önce teknik ofis ve satış tarafından birlikte doğrulanması gerekir. Envanter yapısının nasıl kurulacağı için: Konut Projesinde Envanter Yönetimi
Üretim aşamaları
| Aşama | Ne yapılır | Kimin sorumluluğunda |
|---|---|---|
| 1. Kapsam tanımı | Hangi işlevlerin olacağı, ekran türleri, entegrasyon kararı | Geliştirici ve tedarikçi birlikte |
| 2. Veri toplama | Proje dosyaları ve daire listesinin teslimi | Geliştirici |
| 3. Veri doğrulama | Listenin kontrolü, eksiklerin tamamlanması | Birlikte |
| 4. Üç boyutlu modelleme | Kütle, bloklar, çevre ve peyzajın modellenmesi | Tedarikçi |
| 5. Görsel üretim | Kamera açıları, kat görünümleri, kat planı görselleri | Tedarikçi |
| 6. Veri yapısının kurulması | Daire kodlaması, eşleştirme, filtre kriterleri | Birlikte |
| 7. Arayüz ve etkileşim | Gezinme, filtreleme, karşılaştırma, daire kartı tasarımı | Tedarikçi |
| 8. Entegrasyon | CRM ve web sitesi bağlantısı | Birlikte |
| 9. Test | Veri doğruluğu, cihaz uyumu, senkron kontrolü | Birlikte |
| 10. Devreye alma ve eğitim | Satış ekibine kullanım eğitimi | Birlikte |
Tabloda dikkat çeken şey, on aşamanın beşinde sorumluluğun paylaşılmış olmasıdır. "Maketi ajans yapıyor" varsayımıyla ilerleyen projelerde bu aşamalar sahipsiz kalır ve takvim kayar.
Kapsam tanımı: baştan netleşmesi gerekenler
Birinci aşama, sonraki her şeyi belirler. Sözleşme öncesinde cevaplanması gereken sorular:
- Hangi ekranlarda çalışacak? Satış ofisindeki büyük ekran, tablet, web sitesi, sunum bilgisayarı.
- Etkileşim düzeyi ne olacak? Yalnızca gezinme mi, filtreleme ve karşılaştırma da var mı?
- Daire kartında hangi bilgiler görünecek?
- Stok durumu gösterilecek mi? Gösterilecekse veri nereden gelecek?
- Fiyat gösterilecek mi? Sabit mi yazılacak, listeden mi okunacak?
- CRM bağlantısı olacak mı? Tek yönlü mü, çift yönlü mü?
- Web sitesine gömülecek mi? Lead formu içerecek mi?
- 360 derece görseller veya iç mekân turu eklenecek mi?
- Kaç dil desteklenecek?
- Yeni etaplar nasıl eklenecek?
Dördüncü, beşinci ve altıncı sorular maliyeti ve süreyi en çok etkileyen kalemlerdir. Aynı proje için gelen teklifler arasındaki büyük farklar genellikle bu üç sorunun farklı yorumlanmasından doğar. Entegrasyonun ne anlama geldiği için: Dijital Maket ile CRM Entegrasyonu Web kullanımı için: Web Sitesinde İnteraktif Daire Seçimi
Proje aşamasına göre ne zaman başlanmalı?
Dijital maket siparişinin zamanlaması, projenin hangi aşamada olduğuna bağlıdır. Çok erken başlanan projelerde revizyonlar üretilen işi boşa çıkarır; çok geç başlananlar ise lansmana yetişmez.
| Proje aşaması | Değerlendirme |
|---|---|
| Konsept aşaması | Kütle ve tipler değişebilir; bu aşamada render yeterli olabilir |
| Uygulama projesi kesinleşti | Modelleme için en uygun dönem; daire listesi netleşmiş olur |
| Ruhsat süreci tamamlandı | Satış takvimi netleşir; maket lansmana hazırlanabilir |
| Satış başladı | Geç kalınmış sayılır; ilk aylarda envanter Excel üzerinden yürür |
| İnşaat ilerledi | Gerçek fotoğraflarla desteklenmiş bir kurulum daha değerli olur |
Pratik kural şudur: uygulama projesi kesinleştiğinde ve bağımsız bölüm listesi son hâlini aldığında başlamak, hem revizyon riskini hem de gecikme riskini en aza indirir.
Satış başladıktan sonra devreye alınan projelerde ek bir iş doğar: o ana kadar yapılmış satışların ve açık opsiyonların sisteme doğru aktarılması. Bu aktarım eksik yapılırsa maket ilk günden yanlış veri gösterir ve satış ekibinin güvenini kaybeder.
Modelleme ve görsel üretim
Bu aşamada projenin üç boyutlu karşılığı oluşturulur. Görsel kalite ile performans arasında bir denge kurulması gerekir: aşırı detaylı bir model tabletlerde yavaş çalışır, aşırı sade bir model ise müşteriyi ikna etmez.
Bu aşamada karara bağlanacaklar:
- Detay seviyesi. Bina cephelerinin, peyzajın ve çevre yapılarının ne kadar ayrıntılı olacağı.
- Çevre gerçekliği. Komşu parseller, yollar ve manzara unsurlarının nasıl gösterileceği.
- Kamera açıları. Genel görünüm, blok görünümü, kat görünümü ve daire görünümü.
- Gün ışığı ve atmosfer. Gündüz, gün batımı veya gece görünümleri.
- Manzara gösterimi. Kattan bakış görsellerinin hangi katlar için üretileceği.
Manzara görselleri satış açısından en değerli ama en maliyetli kalemlerden biridir. Her kat için ayrı görsel üretmek yerine belirli kat aralıkları için temsili görsel üretilmesi yaygın bir yaklaşımdır; bu durumda görselin temsili olduğunun ekranda belirtilmesi gerekir.
Daire kodlaması ve eşleştirme
Altıncı aşama teknik görünse de projenin uzun vadeli sağlığını belirler. Maketteki her daire, envanterdeki kayıtla benzersiz bir kodla eşleşmelidir.
Dikkat edilecekler:
- Kodlama, CRM'de kullanılan yapıyla aynı olmalıdır
- Kod, sonradan değişmeyecek bir mantığa dayanmalıdır
- Blok adları tutarlı yazılmalıdır (A Blok, Blok A, A-Blok karışıklığı sık yaşanır)
- Yeni etaplarda aynı kodlama mantığı sürdürülebilmelidir
- Satışa kapalı daireler de listede yer almalı, ayrı durumla işaretlenmelidir
Kodlama farkı, entegrasyon projelerinde en sık karşılaşılan arıza nedenidir. İki sistem farklı kodlar kullanıyorsa aradaki eşleştirme elle tutulan bir tabloya bağlı kalır ve her yeni etapta bakım gerektirir.
Revizyon yönetimi
Konut projeleri süreç içinde değişir: kat planı revize edilir, blok sayısı güncellenir, cephe malzemesi değişir. Sözleşmede revizyon kapsamının yazılı olması gerekir.
| Değişiklik türü | Etkisi |
|---|---|
| Fiyat değişikliği | Veri güncellemesi; entegre kurulumda otomatik |
| Daire durumu değişikliği | Veri güncellemesi; entegre kurulumda otomatik |
| Kat planı revizyonu | İlgili görsellerin yeniden üretimi |
| Daire birleştirme veya bölme | Hem görsel hem veri tarafında değişiklik |
| Cephe veya malzeme değişikliği | Model ve görsellerin yeniden üretimi |
| Yeni blok veya etap | Yeni modelleme ve veri girişi |
| Peyzaj düzenlemesi | Çevre görsellerinin güncellenmesi |
Tablodaki ilk iki satır ile diğerleri arasındaki fark, entegrasyonun değerini de açıklar: veri değişiklikleri otomatik yansırken görsel değişiklikler üretim gerektirir. Bu nedenle sözleşmede "kaç revizyon dâhil" sorusunun cevabı, hangi tür revizyonu kapsadığıyla birlikte yazılmalıdır.
Fiyat güncellemelerinin nasıl planlandığı için: Kademeli Fiyat Artışı Nasıl Yönetilir?
Test aşaması: neyi kontrol etmeli?
Devreye almadan önce yapılacak kontroller iki gruba ayrılır.
Veri doğruluğu kontrolleri:
- Toplam bağımsız bölüm sayısı projeyle uyuşuyor mu?
- Her dairenin tipi, alanı ve cephesi doğru mu?
- Kat planları doğru dairelerle eşleşmiş mi?
- Şerefiye farkları fiyatlara doğru yansıyor mu?
- Satışa kapalı daireler doğru işaretlenmiş mi?
- Filtreler doğru sonuç veriyor mu?
Teknik kontroller:
- Büyük ekran, tablet ve web'de aynı davranıyor mu?
- İnternet kesildiğinde ne oluyor?
- Yükleme süresi kabul edilebilir mi?
- CRM'de yapılan bir durum değişikliği ekrana ne kadar sürede yansıyor?
- Ekrandan açılan opsiyon CRM'e doğru düşüyor mu?
- Mobil deneyim kullanılabilir durumda mı?
Dördüncü ve beşinci teknik kontroller, entegrasyonun gerçekten çalışıp çalışmadığını gösteren en somut testlerdir ve devreye almadan önce mutlaka yapılmalıdır.
Veri kontrollerinde en sık atlanan madde üçüncüsüdür: kat planı görsellerinin yanlış dairelerle eşleşmesi, müşteriye yanlış plan gösterilmesine yol açar ve genellikle ancak bir müşteri fark ettiğinde ortaya çıkar.
Devreye alma ve ekip eğitimi
Teknik olarak hazır bir maket, satış ekibi kullanmadığı sürece yatırım olarak kalır. Devreye alma aşamasında yapılması gerekenler:
- Senaryo bazlı eğitim. Menü tanıtımı yerine gerçek bir müşteri görüşmesinin baştan sona canlandırılması.
- Sunum akışının belirlenmesi. Görüşmenin hangi anında maketin devreye gireceği.
- Yetki ayrımının gösterilmesi. Müşteri ekranı ile danışman görünümü arasındaki fark.
- Sık kullanılan filtrelerin belirlenmesi. Ekibin en çok kullanacağı kombinasyonlar.
- Bağlantı paylaşımı. Görüşme sonrası müşteriye daire bağlantısı gönderme alışkanlığı.
- Sorun bildirimi. Yanlış veri fark edildiğinde kime, nasıl bildirileceği.
Altıncı madde veri kalitesini uzun vadede korur: satış ekibi hatayı fark edip bildirdiğinde düzeltilebilir, bildirmediğinde ekrana güven kaybolur ve herkes kendi fiyat listesine döner.
Satış ofisi altyapısının bütünü için: Satış Ofisi Nasıl Kurulur? Görüşme akışı için: Satış Ofisinde Dijital Sunum
Takvim planlaması
Süre; projenin büyüklüğüne, blok sayısına, istenen görsel kaliteye, entegrasyon kapsamına ve en önemlisi verinin hazır olup olmadığına göre değişir. Tedarikçiden aşamalı bir takvim istemek, gerçekçi bir beklenti kurmanın en pratik yoludur.
Takvimi etkileyen başlıca değişkenler:
| Değişken | Etkisi |
|---|---|
| Daire listesinin hazır olması | En büyük etki; eksik liste tüm süreci bekletir |
| Mevcut üç boyutlu model varlığı | Modelleme süresini belirgin biçimde kısaltabilir |
| Blok ve tip sayısı | Görsel üretim yükünü artırır |
| Manzara görseli kapsamı | Kat bazlı görsel sayısı süreyi uzatır |
| Entegrasyon kapsamı | Çift yönlü bağlantı ek geliştirme ve test gerektirir |
| Revizyon sayısı | Onay süreçleri uzarsa takvim kayar |
| Onay mekanizması | Karar verici sayısı arttıkça geri bildirim süresi uzar |
Son satır çoğu projede gözden kaçar: görsellerin onayı için beş farklı kişinin görüş vermesi gerekiyorsa, teknik üretimden çok onay bekleme süresi harcanır. Tek bir karar vericinin belirlenmesi süreci belirgin biçimde hızlandırır.
Lansmana yetişmesi gereken bir maket için geri sayım, lansman tarihinden değil satış ekibinin eğitim ihtiyacından başlatılmalıdır. Lansman planlaması için: Konut Projesi Lansman Süreci
Kim yapar? Üç farklı yapı
| Model | Güçlü tarafı | Dikkat |
|---|---|---|
| Görselleştirme ajansı | Yüksek görsel kalite | Veri ve entegrasyon tarafı sınırlı kalabilir |
| Yazılım firması | Etkileşim, veri ve entegrasyon güçlü | Görsel üretim dış kaynakla yapılabilir |
| CRM sağlayıcısının ürünü | Envanter ve fiyat bağlantısı hazır gelir | Görsel kapsam ve özelleştirme sınırları sorulmalı |
Hangi model seçilirse seçilsin, sorulması gereken soru aynıdır: veri tarafını kim kuracak ve envanterle bağlantı nasıl sağlanacak? Görsel kalitesi yüksek ama veriye bağlanmayan bir maket, birkaç ay içinde güncelliğini yitirir.
Ayrı sağlayıcılarla çalışılacaksa entegrasyonun kim tarafından geliştirileceği ve arıza durumunda kimin sorumlu olacağı sözleşmede yazılı olmalıdır.
Çok projeli firmalarda kurgu
Birden fazla proje yürüten firmalarda her proje için sıfırdan maket üretmek, hem maliyeti hem yönetim yükünü katlar. Bu durumda değerlendirilmesi gereken başlıklar:
- Ortak altyapı. Arayüz, filtreleme ve daire kartı yapısının projeler arasında standart olması; her projede yalnızca görsel ve veri katmanının değişmesi.
- Tek giriş noktası. Web sitesinde ziyaretçinin önce projeyi, sonra daireyi seçtiği bir akış.
- Ortak kodlama mantığı. Blok ve daire kodlamasının tüm projelerde aynı kurala göre kurulması.
- Yetkilendirme. Satış ekiplerinin yalnızca sorumlu oldukları projeleri görmesi veya tüm projeleri görüp çapraz yönlendirme yapabilmesi.
- Raporlamanın ayrışması. Hangi projenin maketinin ne kadar lead ürettiğinin ayrı izlenmesi.
Ortak altyapı kurulduğunda ikinci ve sonraki projelerin devreye alma süresi belirgin biçimde kısalır; çünkü tekrarlanan tek iş görsel üretim ve veri girişi olur.
Dördüncü madde çapraz satış açısından da anlam taşır: bir projeye uymayan müşteriye diğer projeden seçenek gösterilebilmesi, aynı ekrandan mümkün olduğunda işler. Çok projeli yapının gereksinimleri için: Aynı Anda Birden Fazla Projeyi Yöneten Satış Ekibi İçin CRM Rehberi
Teslim neyi kapsamalı?
Sözleşmede teslim kapsamının maddelenmesi, sonradan çıkan taleplerin ek ücret tartışmasına dönüşmesini önler. Netleşmesi gerekenler:
- Hangi ekranlar ve cihazlar için çalışacağı
- Kaç kamera açısı ve hangi görsellerin üretileceği
- Kat planı görsellerinin kapsamı
- 360 derece görsel veya iç mekân turu dâhil mi
- Dâhil olan revizyon sayısı ve türü
- Entegrasyon kapsamı ve test süreci
- Eğitim süresi ve kapsamı
- Barındırma ve teknik destek koşulları
- Yeni etap ekleme ücretlendirmesi
- Kaynak dosyaların ve içeriğin mülkiyeti
Son madde satın alma öncesinde mutlaka sorulmalıdır: üretilen görsellerin ve verilerin kullanım hakkı kimde? Tedarikçi değiştirmek gerektiğinde bu sorunun cevabı belirleyici olur.
Yayına aldıktan sonra: bakım
Dijital maket tek seferlik bir teslimat değil, proje boyunca yaşayan bir araçtır. Bakım kapsamında düşünülmesi gerekenler:
- Veri güncelliği. Entegre kurulumda otomatik; değilse kimin güncelleyeceği tanımlı olmalı.
- Yeni etap eklenmesi. Süre ve maliyeti baştan bilinmeli.
- Görsel yenileme. İnşaat ilerledikçe render yerine gerçek fotoğrafların eklenmesi.
- Teknik destek. Ekran donduğunda veya bağlantı koptuğunda kime ulaşılacağı.
- Performans takibi. Web tarafında kullanım verilerinin izlenmesi.
- Teslim sonrası kullanım. Kalan stok satışında maketin sürdürülüp sürdürülmeyeceği.
Üçüncü madde teslime yaklaşan projelerde değer üretir: render'la satılan bir projede gerçek fotoğrafların eklenmesi, güven itirazlarına en somut cevabı verir. Kalan stok yönetimi için: Teslim Sonrası Kalan Stok Nasıl Eritilir?
Sürecin tıkandığı yedi nokta
- Daire listesinin eksik gelmesi. En yaygın gecikme nedeni budur.
- Kat planı dosyalarının daire numaralarıyla eşleşmemesi. Elle eşleştirme gerektirir.
- Proje revizyonunun geç bildirilmesi. Üretilmiş görseller çöpe gider.
- Onay verecek kişinin belirsiz olması. Geri bildirim döngüsü uzar.
- Kapsamın sözleşmede muğlak kalması. Her talep ek ücret tartışmasına dönüşür.
- Entegrasyon kararının sonraya bırakılması. Sonradan eklenmesi baştan kurulmasından zordur.
- Eğitimin atlanması. Ekran kullanılmaz, yatırım karşılıksız kalır.
Evon tarafında süreç
Evon'un ürün sayfasında sanal maket, konut projesini üç boyutlu interaktif olarak sunan ve daire seçimi ile anlık stok görüntüleme imkânı veren bir yazılım olarak tanımlanır. Sayfada maket, envanter ve CRM'in aynı veriyle çalıştığı; bir dairenin durumu değiştiğinde her iki tarafta da güncellendiği belirtilmektedir. Blok, kat ve daire gezinme, kat planı, cephe ve manzara bilgisi, 360 derece görseller, gerçek zamanlı stok, dinamik fiyat ile opsiyon ve rezervasyon işlemleri sayfada yer alan başlıklar arasındadır.
Kendi projenizin kapsamını, takvimini ve veri gereksinimlerini demo üzerinden netleştirmenizi öneririz: Evon Maket Modül dökümü için: Modüller
Sık sorulan sorular
Dijital maket için hangi dosyalar gerekir?
Mimari proje (vaziyet, kat ve cephe planları), daire bazında kat planları, bağımsız bölüm listesi, mahal ve malzeme bilgisi, cephe malzemeleri, peyzaj düzenlemesi, varsa üç boyutlu model dosyası ve marka kimliği. En kritik olanı doğru hazırlanmış bağımsız bölüm listesidir.
Dijital maket ne kadar sürede hazır olur?
Proje büyüklüğüne, blok ve tip sayısına, görsel kapsamına, entegrasyon düzeyine ve verinin hazır olup olmadığına göre değişir. Tedarikçiden aşamalı bir takvim istemek ve onay verecek tek bir kişi belirlemek, süreyi öngörülebilir kılan iki pratik adımdır.
Mimari BIM modelimiz var, süreci kısaltır mı?
Kısaltabilir. Ancak BIM modeli teknik amaçlarla üretildiği için doğrudan satış ekranına dönüşmez; görsel sadeleştirme ve performans optimizasyonu gerekir.
Proje revize edilirse maket ne olur?
Fiyat ve durum değişiklikleri veri güncellemesidir ve entegre kurulumlarda otomatik yansır. Kat planı, cephe veya blok değişiklikleri ise görsel üretim gerektirir. Sözleşmede hangi revizyon türünün kaç kez dâhil olduğu yazılı olmalıdır.
Yeni etap eklendiğinde ne oluyor?
Yeni bağımsız bölümler veri tarafında tanımlanır; ancak yeni blokların modellenmesi ve görsellerinin üretilmesi ayrı bir iştir. Etap planı ve ücretlendirmesi sözleşme aşamasında konuşulmalıdır.
Üretilen görsellerin hakkı kimde olur?
Bu, sözleşmede açıkça düzenlenmesi gereken bir konudur. Kaynak dosyaların ve içeriğin kullanım hakkı, ileride tedarikçi değiştirmeniz gerektiğinde belirleyici olur.
Süreçte en sık nerede gecikme yaşanır?
Modelleme veya tasarımda değil, veri tarafında. Bağımsız bölüm listesinin eksik veya tutarsız gelmesi ile onay mekanizmasının belirsiz olması en yaygın iki gecikme nedenidir.
Sonuç
Dijital maket üretimi, bir görselleştirme siparişinden çok ortak yürütülen bir proje gibi işler. Görsel tarafı tedarikçi üstlenir; veri tarafı ise geliştiricinin sorumluluğundadır ve sürecin hızını büyük ölçüde bu taraf belirler.
Süreci sorunsuz yürütmenin üç anahtarı vardır: kapsamın sözleşmede net tanımlanması, bağımsız bölüm listesinin baştan doğrulanması ve onay verecek tek bir kişinin belirlenmesi.
Projeye başlamadan önce yapılacak en pratik iş şudur: daire listenizi açın ve her satırda blok, kat, daire numarası, tip, net ve brüt alan, cephe ve kat planı referansının dolu olup olmadığını kontrol edin. Bu tablo eksiksizse süreç hızlı ilerler; eksikse ilk iş onu tamamlamaktır.
Ücretsiz Evon demosu
Satış sürecinize Evon'un nasıl katkı sağlayacağını kendiniz deneyimleyin.