Kısa cevap: kreş yazılımı bir yoklama listesi değil, üç ayrı defterin tek yerde tutulmasıdır — çocuğun günü (yoklama, uyku, yemek, etkinlik), teslim yetkisi (çocuğu kim alabilir) ve tahsilat (aidat, ek hizmet, devamsızlık). Bir programı değerlendirirken ilk sorulacak şey ekran sayısı değil şudur: teslim yetkisi tarih aralığıyla tanımlı bir kayıt mı, günlük rapor veliye tek tuşla gidiyor mu ve aidat tahakkuku ödemeden ayrı mı üretiliyor? Bu üçü çoğu hazır paketi ilk toplantıda eler.
Kreş yazılımı okul yazılımının küçüğü değildir
Okul yönetim sistemi yazısında anlattığımız yapı ders, not ve sınav etrafında kurulur. Kreşte not yoktur; onun yerine günün kendisi veridir: çocuk kaçta geldi, ne kadar uyudu, ne yedi, hangi etkinliğe katıldı, bez/tuvalet durumu ne. Bu kayıtlar akademik değil **operasyonel**dir ve asıl tüketicileri öğretmen değil velidir. Bu yüzden veri modeli de farklıdır: kayıt derse değil **güne ve çocuğa** açılır.
İkinci fark yaş grubudur. Aynı kurumda 1 yaşındaki bebekle 5 yaşındaki çocuk aynı ekranı paylaşamaz: bebekte uyku ve beslenme aralığı, büyük grupta etkinlik ve hazırlık takibi ölçülür. Program grup başına farklı alan setini destekleyemiyorsa öğretmen kayıtları deftere yazmaya geri döner — ve o defter hiçbir rapora akmaz.
En kritik modül teslim yetkisidir
Kreşte bir tek geri alınamaz hata vardır: çocuğun yanlış kişiye teslim edilmesi. Bu yüzden teslim yetkisi serbest metin bir not değil, **tarih aralığı taşıyan bir kayıt** olmalıdır — büyükanne sürekli yetkili olabilir, komşu yalnızca bu hafta. Sistem kapıda tek soruya cevap vermeli: bu kişi, bu çocuğu, şu anda alabilir mi?
type TeslimYetkisi = {
cocukId: string;
kisiId: string;
baslangic: Date;
bitis: Date | null; // null = süresiz
};
function teslimEdilebilirMi(
cocukId: string,
kisiId: string,
an: Date,
yetkiler: TeslimYetkisi[],
): boolean {
// Varsayılan HAYIR: listede olmayan kişi çocuğu alamaz. Tersi
// (varsayılan evet + yasaklılar listesi) bir gün boş bırakılan
// bir alan yüzünden yanlış kişiye teslim demektir.
return yetkiler.some(
(y) =>
y.cocukId === cocukId &&
y.kisiId === kisiId &&
y.baslangic <= an &&
(y.bitis === null || an <= y.bitis),
);
}Fonksiyonun iki detayı önemli. Varsayılan **hayır**: listede olmayan alamaz. Ve yetki tarihlidir; süresi dolan yetki elle silinmeyi beklemez, kendiliğinden kapanır. Teslim anında kimin aldığı ve saati kayda geçmelidir — velinin ertesi gün "çocuğu kim aldı" sorusunun cevabı öğretmenin hafızasında değil sistemde durmalı.
Teslim yetkisi "not" alanında tutulan bir kreş programı, kapıdaki kararı yazılıma değil o an nöbetçi olan kişinin hatırasına bırakır. Yetkiyi kişi listesi + tarih aralığı olarak modellemek sonradan eklenebilecek bir özellik değil, baştan kurulacak bir alandır.
Veli iletişimi ürünün kendisidir
Kreş seçiminde velinin gözünde farkı yaratan şey mutfak ya da oyun alanı kadar **görünürlüktür**: gün içinde ne olduğunu bilmek. Günlük rapor (uyku, yemek, etkinlik, fotoğraf) bir "ekstra modül" değil, kurumun her gün teslim ettiği üründür. Pratikte işe yarayan kurallar:
- Rapor gün sonunda tek tuşla kapanmalı; öğretmen her çocuk için ayrı form dolduruyorsa üçüncü hafta rapor yazılmaz olur.
- Duyuru ve bireysel mesaj ayrılmalı: tüm gruba giden duyuru ile tek veliye yazılan mesaj aynı kanalda karışırsa veli ikisini de okumaz.
- Fotoğraf paylaşımında izin çocuk bazında tutulur — bir velinin izin vermemesi tüm grubun fotoğrafını engellemez, o çocuk kadrajdan çıkarılır. WhatsApp entegrasyonu düşünüyorsanız WhatsApp Business API yazısına bakın.
- Acil durum bilgisi (alerji, kronik rahatsızlık, ilaç) rapor akışında değil, çocuk kartının en üstünde sabit durmalı.
Sağlık ve alerji bilgisi özel nitelikli kişisel veridir; kimin görebileceği, ne kadar saklanacağı ve fotoğraf izinlerinin nasıl alındığı KVKK uyumlu web sitesi yazısındaki ilkelerle kurulmalıdır. Bu yazı hukuki danışmanlık değildir; kurum sözleşmenizi bir danışmana okutun.
Tahsilat: tahakkuk ödemeden ayrıdır
Aidat takibinde en yaygın hata, borcu ödeme geldiğinde oluşturmaktır. Doğru sıra tersidir: ay başında her çocuk için tahakkuk üretilir, gelen ödemeler bu tahakkuklara kapatılır. Aynı ayrımı site yönetim programı yazısında da anlattık; kreşte üstüne şu kalemler biner:
- Kardeş indirimi ve kurum anlaşması — indirim elle girilen bir tutar değil, kurala bağlı bir alan olmalı.
- Ek hizmetler: servis, yemek, geç kalma ücreti, yaz dönemi. Her biri ayrı tahakkuk türüdür.
- Devamsızlık politikası: hangi durumda ücret düşer, hangi durumda düşmez — sözleşmeye yazılan kural programda da tanımlı olmalı.
- Online ödeme: veliye link göndermek tahsilat oranını yükseltir; altyapısı için ödeme entegrasyonu yazısına bakın.
Hazır paket mi özel yazılım mı?
Tek şubeli çoğu kreş için hazır paket yeterlidir. Özel yazılım kararı üç testten en az ikisi "evet" olduğunda anlamlıdır:
- Birden çok şube var ve kayıt, kontenjan ile tahsilat merkezden toplu görülmek zorunda.
- Fiyat ya da devamsızlık kuralınız standart dışı (kurum anlaşmaları, yarım gün/tam gün karışık paketler, dönemsel fiyat).
- Başka bir sistemle konuşması gerekiyor: muhasebe, servis takibi, e-fatura. Entegrasyon tarafı için API entegrasyonu yazısına bakın.
Dördüncü soru hazır paketlerde en çok atlanandır: veriyi dışa aktarabiliyor musunuz? Çocuk kayıtları, teslim yetkileri, tahsilat geçmişi ve günlük raporlar dışa alınamıyorsa program değiştirmenin maliyeti lisans ücretinden büyük olur. Maliyet kalemlerini adam-gün üzerinden özel yazılım maliyeti yazısında anlattık; kreşte mobil taraf (öğretmenin tablet ekranı) projenin en az yarısıdır — öğretmen kullanmıyorsa hiçbir kayıt oluşmaz.
Sonuç
Kreş programını seçerken üç şeye bakın: teslim yetkisi tarihli bir kayıt mı, günlük rapor tek tuşla kapanıyor mu, tahakkuk tahsilattan ayrı mı üretiliyor. Bu üçü varsa gerisi rapor ayrıntısıdır. Kurumunuza özel bir çözüm değerlendiriyorsanız özel yazılım hizmetimize göz atın ya da mevcut sürecinizi anlatıp teklif alın.