Ajanslar için Saat ve Karlılık Takibi Yapacak Bir Web Uygulaması Oluşturun
Dijital ajansların faturalandırılabilir saatleri, bütçeleri, kullanım oranını ve gerçek proje karlılığını net raporlarla izlemesini sağlayan bir web uygulamasının nasıl planlanıp inşa edileceğini öğrenin.

Hedefi tanımlayın: faturalandırılabilir saatler ve gerçek proje karlılığı
Ekranları tasarlamadan veya veri tabanı seçmeden önce, uygulamada her gün yaşayacak kişilerin için “başarı”nın neye benzediği konusunda net olun. Ajansların zaman takibinde başarısız olma nedeni özellik eksikliği değil, hedefin bulanık olmasıdır.
Kim kullanacak (ve ne önemser)
Ajans sahipleri şunu bilmek ister: “Bu retainer ile gerçekten para mı kazanıyoruz?” Müşteri, ekip ve aylar boyunca rolluplara ihtiyaçları vardır.
Proje yöneticileri kontrol ve hız ister: tüketimi bütçeyle karşılaştırmak, kapsam sürüşünü erken tespit etmek ve zaman çizelgelerinin zamanında onaylanmasını sağlamak.
Ekip üyeleri (ve taşeronlar) basitlik ister: zamanı hızlı kaydetmek, neye karşı kayıt yapacaklarını bilmek ve eksik girişler için kovalanmamak.
Tasarlanacak temel çıktılar
Ölçülebilecek çıktılarla başlayın:
- Doğru faturalandırılabilir saatler: daha az boşluk, ay sonu tahmini girişlerin azalması ve doğru müşteri/proje/göreve açık tahsis.
- Daha az kaçırılan fatura: onaylanmış süreler kopyala-yapıştır olmadan faturalamaya akar.
- Daha net marjlar: hangi işin ajansı finanse ettiğini ve hangi işin gizlice erittiğini görebilirsiniz.
Ajans için “karlılık” ne demektir
En azından karlılık şudur:
Gelir (faturalandırılan veya tanınan) eksi işçilik maliyeti (çalışanların iç maliyet oranları + taşeron ücretleri) eksi genel gider tahsisi (başlangıçta isteğe bağlı, ama gerçek marjlar için önemli).
Genel gideri ilk gün modellemeyecekseniz bile, hedefinizin proje marjı (sadece doğrudan işçilik) mi yoksa gerçek marj (genel gider dahil) mı olduğunu baştan kararlaştırın. Bu, ileride kafa karışıklığını önler.
Neden e-tablolar ve kopuk araçlar başarısız olur
E-tablolar ve ayrı zamanlayıcılar genellikle tutarsız kategorilere, eksik onaylara ve “gerçek”in eşleşmeyen sürümlerine yol açar. Sonuç tahmin edilebilir: eksik faturalandırılmış saatler, geç faturalandırma ve kimsenin işlem yapacak kadar güvenmediği karlılık raporları.
Ajansların zaten takip ettiği iş akışlarını haritalayın
UI tasarlamadan önce işin ajans içinde gerçekten nasıl aktığını—“zaman takip etmeliyiz”den “fatura ettik ve marjları gözden geçirdik”e kadar—haritalayın. Uygulamanız mevcut alışkanlıklara uyarsa benimseme kolaylaşır ve veri kalitesi artar.
Zaman girişi: insanlar gerçekte nasıl saat kaydediyor
Çoğu ajans zamanlayıcı tabanlı takip (derin çalışma için başlat/durdur) ve manuel giriş (toplantı sonrası, bağlam değişimi veya mobil çalışma) karışımı kullanır. İkisini destekleyin ve ekiplerin seçim yapmasına izin verin.
Ayrıca iş akışınızın günlük kayıt (daha iyi doğruluk, hafta sonu panik azalır) mı yoksa haftalık zaman çizelgeleri (onayların yaygın olduğu ajanslarda) mı merkezli olacağına karar verin. Pek çok ekip günlük hatırlatmalar ister ama haftalık bir gönderme adımı da ister.
Proje ve müşteri kurulumu: ajansların satış şeklini eşleştirin
Zaman takibi, projeler ajansların fiyatladığı şekilde kurulmuşsa işe yarar:
- Saatlik: basit görevler ve devam eden destek için
- Sabit ücret: teslimat maliyetini anlamak ve marjları korumak için zaman takibi
- Retainer: aylık bir kova içinde izleme, genellikle dahil edilen saatler ve aşım ücreti
Haritalama sırasında müşteriyi/projeyi kimlerin oluşturduğunu (ops, PM, hesap yöneticileri) ve neler gerektiğini not edin: hizmet hattı, roller, lokasyonlar veya tarife kartları.
Onaylar: sürtünmeyi azaltın, hesap verebilirliği koruyun
Onaylar genellikle öngörülebilir bir akışta (haftalık veya iki haftada bir) olur. Netleştirin:
- Kim gönderir (her kişi vs. ekip liderleri)
- Kim inceler (PM, hesap lideri, finans)
- Onaydan sonra zaman geç kaldığında veya düzenlendiğinde ne olur
Raporlama: karar vericilerin beklediği görünümler
Ajanslar genellikle proje, müşteri, hizmet hattı ve kişi bazında marjları gözden geçirir. Bu raporlama beklentilerini erkenden haritalamak daha sonra yeniden çalışmayı önler—çünkü hangi meta verinin giriş sırasında yakalanması gerektiğini belirler, sonradan değil.
Veri modeline karar verin: ne saklamanız gerekir
Veri modeliniz ürününüz, raporlarınız ve faturalarınız arasındaki sözleşmedir. Erken doğru kurarsanız, UI ve iş akışlarını kırmadan daha sonra değiştirebilirsiniz.
Çekirdek varlıklar ("kim" ve "ne")
Küçük, iyi bağlı bir nesne seti ile başlayın:
- Müşteriler: fatura adresi, para birimi, vergi ayarları ve ödeme koşulları dahil.
- Kişiler: müşteri başına birden fazla kişi (finans vs. proje lideri), e-posta ve rol bilgisi ile.
- Projeler: bir proje bir müşteriye ait; durum, başlangıç/bitiş tarihleri, varsayılan fiyatlandırma modeli ve isteğe bağlı bütçe saklayın.
- Görevler/Faaliyetler: “Tasarım”, “Geliştirme”, “PM”, “Toplantılar” gibi basit bir taksonomi raporlama için yardımcı olur. Esnek tutun (çalışma alanı bazında özelleştirilebilir).
Zaman girişleri (gerçek kaynağınız)
İlgili her rapor nihayetinde zaman girişlerine dayanır. En azından saklayın:
- Tarih (veya daha sonra zamanlayıcı isterseniz başlangıç/bitiş zaman damgaları)
- Süre (yuvarlama sorunlarını önlemek için dakikada saklayın)
- Faturalandırılabilir bayrak (faturalandırılabilir vs. faturalandırılamayan)
- Notlar (ne yapıldı)
- Bağlantılar/ekler (isteğe bağlı: URL, dosya referansı veya entegrasyon ID'leri)
Ayrıca yabancı anahtarları yakalayın: kişi, proje, görev/faaliyet—ve denetlenebilirlik için değişmez created_at/updated_at zaman damgalarını ekleyin.
Tarifeler (zamanın gelir olmasına nasıl dönüşeceği)
Ajanslar nadiren tek bir saatlik ücret kullanır. Tarifeleri üst üste koyulacak şekilde modelleyin:
- Role dayalı tarifeler (ör. Tasarımcı, Kıdemli Geliştirici)
- Kişi bazlı tarifeler (belirli personele istisnalar)
- Müşteri özel tarife kartları (müzakere edilmiş fiyatlar, bazen rol bazında)
Pratik bir kural: onay anında zaman girişine uygulanan tarifeyi saklayın ki tarife kartları düzenlense bile faturalar değişmesin.
Maliyetler (zamanın marja nasıl dönüştüğü)
Karlılık için sadece faturalandırılabilirlik yetmez; maliyet gerekir:
- Kişi başına iç maliyet oranları (saatlik maliyet)
- Taşeron maliyetleri (saatlik veya sabit, bir satıcıya bağlı)
- Giderler (kategori, tutar, para birimi, makbuz referansı, faturalandırılabilir/faturalandırılamaz)
Bu parçalarla, ajansları tek bir katı iş akışına zorlamadan gelir, maliyet ve marj hesaplayabilirsiniz.
Ajansların gerçekte kullandığı fiyatlandırma modellerini destekleyin
Sadece saatlik faturalamayı destekleyen bir uygulama varsa, insanlar aracı gerçeğe uydurmak için genellikle e-tablolar kullanır. Ajanslar genelde karışık portföyler (saatlik, sabit, retainer) işletir; uygulamanız bu üçünü de ekiplerin zaman kaydetme şeklini değiştirmeden desteklemeli.
Saatlik projeler (klasik durum)
Saatlik işler kağıt üzerinde basittir: faturalandırılabilir zaman × tarife. Zor olan taraf tarifelerin değişken olmasıdır.
Roller (Tasarımcı, PM) bazında, kişi bazında, müşteri veya proje bazında tarife kartlarını destekleyin. Sonra kontrollü düzeltmeler ekleyin:
- İndirimler (line-level write-downs) ve eklemeler (write-ups) zaman girişi veya fatura satırı başına
- Kimin, ne zaman ve neden ayarlama yaptığını gösteren açık bir denetim izi
Bu, faturalandırılabilir saat takibini doğru tutarken hesap ekiplerinin müşteri beklentileriyle eşleşmesini sağlar.
Sabit ücretli projeler (bütçe tüketimi ve marj görünürlüğü)
Sabit ücretli projeler, bütçeyi ne kadar hızlı tükettiklerine göre başarılı olur. Burada zaman takibi sadece faturalama için değil—proje bütçeleme ve erken uyarı için gereklidir.
Sabit ücretli projeyi şu şekilde modelleyin:
- Toplam bir ücret (gelir)
- İçeride saat, maliyet veya her ikisinde bir hedef bütçe
- Opsiyonel bir hedef marj
Sonra “bütçe karşısında tüketimi” zaman içinde gösterin: hafta hafta tüketim, bitime tahmin, ve kapsam değiştikçe proje marjlarının nasıl trend gösterdiği. Bir projenin bugün karlı olduğunu ama sürüklenmekte olduğunu görünür kılın.
Retainerlar (tahsisler, devreden haklar ve aşım)
Retainerlar tekrar eden ve kural ağırlıklıdır. Araç, ekiplerin bir aylık tahsisat (örn. 40 saat/ay) belirlemesine izin vermeli, sonra ay sonu için kuralları tanımlamalıdır:
- Devretme yok (kullanılmayan saatler sona erer)
- Sınırlı devretme (X saate kadar veya X ay boyunca devredebilir)
- Sınırsız devretme (nadir ama gerçek)
Zaman tahsisatı aşıldığında, genellikle standart tarifenin farklı olduğu bir aşım ücreti ile faturalayın. Matematiği şeffaf tutun ki müşteriler toplamları güvenle kabul etsin.
Faturalandırılamayan zaman (ajans karlılığı için hâlâ önemli)
Ajansların iç çalışma, satış öncesi, yönetim ve eğitim gibi faturalandırılamayan kategorilere ihtiyacı vardır. Bunları gizlemeyin—birinci sınıf zaman tipleri olarak ele alın. Bunlar kullanım oranı ve ajans raporlaması için önemlidir ve “meşgul” olmanın her zaman karlı olmadığı açıklamalarını güçlendirir.
Kilit metrikleri ve formülleri seçin (basit tutun)
Zaman + karlılık uygulaması, herkes sayılarına güvendiğinde başarılı olur. Bu, küçük bir metrik seti seçmeyi, onları bir kez tanımlamayı ve aynı formülleri her yerde kullanmayı gerektirir (zaman çizelgeleri, proje görünümleri ve raporlar).
1) Faturalandırılabilir temel: saatler, tutar ve EHR
Her ajansın anlayacağı üç alanla başlayın:
- Faturalandırılabilir saatler: faturalandırılabilir müşteri projesine kaydedilen saatler (politikaya göre)
- Faturalandırılabilir tutar: bu saatlerin faturalandırma tarifesiyle değeri
- Etkili Saatlik Ücret (EHR): saat başına gerçekte kazandığınız miktar
Formüller:
- Faturalandırılabilir tutar =
billable_hours × bill_rate - EHR =
revenue ÷ hours_logged(veya zaman & malzeme içinbillable_amount ÷ billable_hours)
EHR iyi bir “akıl kontrolü” metriğidir: aynı tarife kartına sahip iki proje farklı EHR gösteriyorsa, bir yerde sorun vardır (kapsam sürüşü, indirimler, silmeler).
2) İşçilik maliyeti ve brüt marj
Karlılık için maliyet gerekir; basit tutun ve ilk aşamada sadece işçiliği dahil edin:
- İşçilik maliyeti =
internal_labor_cost + contractor_cost - Brüt marj =
(revenue − cost_of_labor) ÷ revenue
İç maliyeti saatlik bir maliyet oranı (maaş + vergiler + yan haklar, saatlik sayıya bölünmüş) olarak tanımlayın ki uygulama zaman çizelgelerinden otomatik hesap yapabilsin.
3) Kullanım oranı ("kullanılabilir" tanımı açık)
Kullanım oranı kafa karıştırıcı olabilir; bu yüzden “kullanılabilir saatleri” açıkça tanımlayın.
- Kullanılabilir saatler: çalışma saatleri eksi tatiller ve onaylı izinler (isteğe bağlı olarak ayrı takip ediliyorsa iç toplantılar hariç)
- Kullanım oranı =
billable_hours ÷ available_hours
Bu tanımı uygulama içinde belgelendirin ki raporlar tartışmaya dönüşmesin.
4) Bütçe vs. gerçekleşen ve aşım uyarıları
Bütçeleri saat ve para biriminde izleyin:
- Saat sapması =
actual_hours − budget_hours - Harcamа sapması =
actual_revenue_or_cost − budgeted_revenue_or_cost
Eşiklerde basit uyarılar tetikleyin (örneğin: %80 tüketildiğinde, sonra %100 aşıldığında) ki proje yöneticileri marjlar kaybolmadan önce müdahale edebilsin.
İnsanların kullanacağı bir zaman takip deneyimi tasarlayın
Zaman kaydı evrak işi gibi geliyorsa, insanlar bundan kaçınır—veya Cuma gecesi tahminlerle doldurur. Amaç, zaman girişinin ertelemekten daha hızlı olmasını sağlamak; yine de faturalama ve karlılık için güvenilir veri üretmek.
Zahmetsiz hissettiren hızlı zaman girişi
Hıza öncelik verin; görsel şovlardan ziyade işe yarar bir varsayılan “bir satır = bir giriş” (proje, görev/faaliyet, süre ve isteğe bağlı not) iyi bir başlangıçtır.
Yaygın eylemleri neredeyse anında yapın:
- Klavye-öncelikli giriş: “/” ile proje arama, “tab” ile alanlar arası geçiş, “enter” ile bir sonraki satırı ekleme.
- Son projeler ve görevler: son 5–10 öğeyi gösterin ve kullanıcıların favori olarak sabitlemesine izin verin.
- Akıllı öneriler: takvim etkinliklerine, sık kullanılan müşterilere veya aynı haftanın önceki girişine göre ön doldurma (her zaman düzenlenebilir).
İzleme (timer) özellikleri ama gözetleme olmadan
Bazı kişiler zamanlayıcıları sever; bazıları manuel giriş tercih eder. İkisini destekleyin.
Zamanlayıcılar için pratik tutun:
- Boşta kalma algılama ile nazik bir uyarı: “12 dakika uzak kaldınız—sakla, sil veya böl?”
- Yapılandırılabilir yuvarlama kuralları (müşteri veya çalışma alanı bazında): örn. 6 dakika, 15 dakika veya yuvarlama yok. Her zaman orijinal zamanı saklayın ki yöneticiler denetleyebilsin.
- Hatırlatmalar: rahatsız etmeyen uyarılar; gün sonu "eksik zaman" hatırlatması, isteğe bağlı push bildirimleri.
Zaman çizelgesi UX: haftalık temizliği kolaylaştırın
Haftalık zaman çizelgeleri benimsenmenin kazanıldığı yerdir.
Bir hafta görünümü sunun ve şunları destekleyin:
- Toplu düzenleme (birden çok satırda proje/görev değişikliği)
- Geçen haftayı kopyala (sonra düzelt)
- Satır içi doğrulama (“Bugün 6.5/8 saatlik giriş yaptınız”)
Notları isteğe bağlı ama faturalama için gerektiğinde kolay eklenebilir tutun.
Mobil için temel özellikler
Mobil her özelliğe ihtiyaç duymaz. Şunlara odaklanın:
- Bugünün girişlerini hızlı düzenleme
- Zamanlayıcı başlat/durdur
- Zaman çizelgelerini kısa bir yorumla onaylama/reddetme
Onaylar önemliyse, bunların bir dakikadan kısa sürede yapılabilir olmasını sağlayın—aksi halde faturalama tıkanır.
Roller, izinler ve onayları planlayın
Ajanslar kimin neyi görebileceğinden, düzenleyebileceğinden ve onaylayabileceğinden emin değilse sayılara güvenmezler. Roller ve izinler ayrıca “kazara muhasebe”yi (ör. bir taşeronun geçen ay onaylanmış zaman çizelgesini değiştirmesi) önler.
Küçük bir rol setiyle başlayın
Çoğu ajansın ihtiyaçlarının %95'ini beş rol karşılar:
- Admin: çalışma alanlarını, güvenlik ayarlarını, entegrasyonları ve küresel tarife kartlarını yönetir.
- Finans: onayları inceler, faturalamaya/muhasebeye dışa aktarır ve marj/gelir görünümlerine erişir.
- Proje Yöneticisi: projeleri, bütçeleri ve kendi projeleri için onayları yönetir.
- Üye: atanmış projeler için zaman ve gider kaydeder.
- Taşeron: Üye'ye benzer, ama görünürlük ve sadece kendi girişlerine erişim gibi daha sıkı sınırlar vardır.
V1'de bir “özel rol oluşturucu” yapmaktan kaçının. Bunun yerine birkaç geçiş (örn. “Zaman onaylayabilir”, “Finansal verileri görebilir”) ekleyin.
Karışık veriyi önleyecek onay kuralları
Onaylar tutarlılığı zorlamalı ama insanları yavaşlatmamalı:
- Gerekli alanlar: müşteri, proje, görev/tip, tarih, süre ve (isteğe bağlı) kısa not
- Dönem kilitleme: onaylandıktan sonra bir zaman çizelgesi hafta/ay salt okunur olur. Düzenlemeler Finans/Admin tarafından “kilit açma” gerektirir.
- Denetim izi: kim, neyi ve ne zaman değiştirdiğini kaydedin (giriş düzenlemeleri, onaylar, kilit açmalar). Bu anlaşmazlıklar ve uyumluluk için hayati önemdedir.
Müşteri/proje bazlı izinler
Ajanslar genellikle gizlilik sınırlarına ihtiyaç duyar. Atanmış vs. atanmamış proje erişimini ve ayrı bir finansal görünürlük (tarifeler, maliyet, marj) izni destekleyin. Pek çok ekip PM'lerin saatleri görmesini ister ama ücretleri görmemesini ister.
Kimlik doğrulama ve oturum güvenliği
Temel olarak e-posta/şifre ile güçlü sıfırlama akışları sağlayın. Daha büyük takımlara satıyorsanız SSO (Google/Microsoft) ekleyin. Onaylar ve finansal raporlar kaybolmuş bir dizüstü bilgisayar bulunduğunda açığa çıkmaması için güvenli oturumları zorunlu kılın (kısa ömürlü tokenlar, cihaz oturumu kapatma, isteğe bağlı 2FA).
Faturalamayı çift giriş olmadan faturaya bağlayın
Saatler ancak bir müşterinin anlayacağı şekilde bir faturaya akabildiğinde “faturalandırılabilir”dir. Çift girişten kaçınmanın en iyi yolu zamanı tek kaynak olarak kabul etmektir: insanlar işi bir kez kaydeder, ve faturalama, düzeltmeler, dışa aktarımlar, entegrasyonlar aynı girişlere referans verir.
Zaman girişlerini varsayılan olarak fatura hazır yapın
Zaman çizelgesi verinizi muhasebe ekiplerinin tam olarak kullandığı şekilde dışa aktarılabilir yapın. Müşteri → proje → kişi → görev (ve isteğe bağlı tarih aralığı) bazında gruplayıp ara toplam alabilen fatura-uygun dışa aktarımlar sunun.
Pratik bir yaklaşım, her girişe basit bir “faturalama durumu” eklemektir (örn. Taslak, Hazır, Faturalandı) ve faturaya gönderildiğinde bir “fatura referansı” eklemek. Bu, veriyi çoğaltmadan izlenebilirlik sağlar.
Eğer ürününüz zaten zaman takibini içeriyorsa, faturalamanın nasıl bağlandığını gösterin (ör. /features/time-tracking'den “Fatura hazırlığı” görünümüne) ki kullanıcılar uçtan uca akışı görsün.
Silme ve düzeltmeleri şeffaf takip edin
Ajanslar sık sık zamanı düzeltir: kapsam değişiklikleri, müşteri talepleri, iç hatalar. Bunu gizlemeyin—modelleyin.
Satır düzeyinde veya fatura düzeyinde düzeltmelere izin verin ve bir neden kodu zorunlu kılın: Kapsam dışı, Müşteri talebi, İç yeniden çalışma, İndirim gibi. Bu, ileride marj değişimlerini açıklamayı ve müşteri görüşmelerini kolaylaştırır.
Kullanıcıları kilitlemeden entegrasyonlar sunun
Birçok ajans hâlihazırda muhasebe veya faturalama araçları kullanır. Entegrasyon seçenekleri sağlayın:
- Onaylanmış faturalandırılabilir zamanı çekmek ve fatura ID'lerini geri göndermek için API uç noktaları
- Zaman çizelgeleri onaylandığında veya faturalandı olarak işaretlendiğinde harici sistemleri bilgilendiren webhook’lar
Küçük ekipler için temiz CSV/XLSX dışa aktarımlar sunun; büyüyen takımlar için /pricing sayfasındaki planlar ve entegrasyon yeteneklerine yönlendirin.
Mimarî ve teknoloji yığını seçin (pratik, trend değil)
Zaman takip uygulamasının yaşamı veya ölümü güvende: toplamların tutması, değişikliklerin izlenebilir olması ve raporların faturalarla eşleşmesi gerekir. Doğruluk ve bakımı kolaylaştıran kanıtlanmış, stabil bileşenleri seçin.
Prototipi hızlıca bir ajansın önüne koymak istiyorsanız, Koder.ai gibi bir vibe-coding platformu, yapılandırılmış bir sohbetten React ile Go + PostgreSQL backend üretmenize yardımcı olabilir—iş akışını, veri modelini ve raporları doğrulamak için faydalıdır.
Veri tabanı: sadece “en son değeri” değil, geçmişi tutun
İlişkisel bir veri tabanı (PostgreSQL yaygın bir varsayılan) kullanın çünkü faturalandırılabilir saat takibi temiz ilişkiler gerektirir: kişiler → projeler → görevler → zaman girişleri → onaylar → faturalar.
Tabloları şöyle yapılandırın ki “o anda neye inanıyorduk?” sorusuna yanıt verebilesiniz:
- Mümkünse zaman girişlerini değişmez kayıtlar olarak saklayın; bir şey değiştiğinde bir düzenleme olayı kaydedin (kim, ne zaman, neden).
- Tarifeleri ve tarife kartlarını (etkili tarih aralıklarıyla) versiyonlayın ki eski faturalar birebir yeniden oluşturulabilsin.
- Birden çok yerde hesaplanan toplamlardan kaçının; kaynaktan hesaplayın ve hız için yalnızca önbelleğe alın.
API: gerçek eylemler etrafında tasarlayın
Uç noktaları basit ve öngörülebilir tutun:
- Zaman girişleri: create, update, submit, approve/reject, lock/unlock
- Projeler: bütçeler, faturalama kuralları, atanmış kişiler, durum
- Tarifeler: kişi istisnaları, rol tarifeleri, müşteri özel tarifeleri
- Raporlar: kullanım oranı, proje marjları, bütçe vs. gerçekleşen
Create eylemleri için idempotentlik ve net doğrulama hataları ekleyin—insanlar birden çok cihazdan saat girecek.
Ön uç: daha az ekran, daha az bahane
Dört deneyime öncelik verin: hızlı zaman çizelgesi, yönetici onay kuyruğu, proje panosu (bütçe + tüketim) ve filtrelerle çalışan raporlama.
Arka plan işleri: sıkıcı işleri otomatik yapın
Hatırlatma e-postaları/Slack bildirimleri, planlı dışa aktarımlar, önbelleğe alınmış raporların yeniden hesaplanması ve gece veri kalite kontrolleri (eksik tarifeler, onaylanmamış zaman çizelgeleri, bütçe aşımları) için iş kuyruğu kullanın.
Önce MVP oluşturun, sonra gelişmiş karlılık ekleyin
Ajanslar karlılığı takip etmeyi özellik eksikliğinden değil, benimsemenin zor olmasından dolayı kaçırır. Küçük bir MVP ile ekiplerin zaten nasıl çalıştığını yakalayın, sonra veri kalitesi ve alışkanlıklar oturduktan sonra derinlik ekleyin.
Deneme verisiyle başlayın ki ekipler hemen deneyebilsin
Boş bir sistem hız öldürür. Yeni çalışma alanının modelini keşfetmesi için deneme verisi ile gönderin veya oluşturun:
- Örnek müşteriler ve projeler (retainer + sabit ücret + dahili)
- Temel bir tarife kartı (standart rol tarifeleri ve bir “istisna” örneği)
- Gerçekçi izinlerle takım rolleri (admin, yönetici, katkıda bulunan)
Bu, onboarding süresini kısaltır ve demoların somut hissettirmesini sağlar.
MVP kapsamı: değeri kanıtlayan en küçük döngü
MVP’niz bir kapalı döngü sonucu sunmalı: zaman kaydet → zaman çizelgelerini onayla → marjları gör.
İçermeli:
- Proje/görev, faturalandırılabilir bayrak, not ile zaman takibi (zamanlayıcı + manuel)
- Zaman çizelgesi onayları (haftalık gönderim, yönetici onay/red ve yorum)
- Proje başına basit bir marj raporu (izlenen maliyet vs. faturalandırılabilir değer)
Marj raporunu belirgin ve karar verici tutun: tek ekran, birkaç filtre ve “maliyet” ile “gelir”in net bir tanımı.
Hızlı inşa ediyorsanız, varlıkları, izinleri ve onay kurallarını önce Planlama Modu'nda (Koder.ai) tanımlamayı, sonra ilk uygulamayı üreterek yinelemeyi düşünün. Kaynak kodunu daha sonra dışa aktarabilirsiniz.
Faz 2: tahminleme ve kapasite planlama
Ekipler düzenli zaman göndermeye ve onaylamaya başladıktan sonra ileriye dönük araçlar ekleyin:
- Proje ve kişi bazında tahmin vs. gerçekleşen saatler
- Kullanım ve kapasite planlama (kim fazla/az ayrılmış)
- Gelişmiş izinler gerektiğinde (ör. tarifeleri yalnızca finans görebilsin)
Faz 3: entegrasyonlar ve otomasyon
Çekirdek iş akışı güvenilir hale gelince UI'ı şişirmeden genişletin:
- Entegrasyonlar (muhasebe, faturalama, bordro, takvimler)
- Özel alanlar (uzmanlık alanı, lokasyon, müşteri departmanı)
- Otomasyon kuralları (iç projeleri otomatik onayla, hatırlatmalar, bütçe uyarıları)
Kural: her yeni özellik ya veri doğruluğunu artırmalı ya da sistemi yönetme süresini azaltmalı.
Yaygın risklerden kaçının: doğruluk, uyumluluk ve performans
Zaman ve karlılık uygulaması yalnızca özelliklerden ibaret değildir. Güveni bozan en büyük tehditler ince ayrıntılardır: “saatlerim değişti”, “rapor yavaş”, veya “bunu neden saklıyorsunuz?” Bu riskleri baştan ele alın ki ajanslar tüm takıma açsın.
Gizlilik ve uyumluluk: daha az saklayın, daha çok kontrol edin
Zaman takibi nadiren hassas kişisel verilere ihtiyaç duyar. Kullanıcı profillerini minimal tutun (isim, e-posta, rol) ve açıklık getiremeyeceğiniz hiçbir şeyi toplamayın.
İlk günden saklama kontrolleri ekleyin: yöneticilerin ham zaman girişlerini, onayları ve faturaları ne kadar süreyle saklayacağını ayarlamasına izin verin. Denetimler için dışa aktarmaları kolaylaştırın ve ayrılan taşeronların verilerini anonimleştirip finansal toplamları koruma yolları sağlayın.
Doğruluk: yuvarlama, zaman dilimleri ve onay sonrası düzenlemeler
Küçük "matematik tuhaflıkları" büyük anlaşmazlıklara yol açar. Kurallarınızı belirleyip belgeleyin:
- Yuvarlama politikası (örn. en yakın 6 dakika) zamanlayıcı, manuel giriş ve içe aktarımlarda tutarlı uygulanmalı.
- Zaman dilimi yönetimi: zaman damgalarını UTC'de saklayın, kullanıcıya yerel zamanda gösterin ve onaylanan giriş için kullanılan zaman dilimini kilitleyin.
- Düzenleme politikası: onaylandıktan sonra değişiklikler sessizce üzerine yazılmamalı; yeniden onay gerektirmeli.
Ayrıca birleşik oturumlar (stop/start), çakışan girişler ve kullanıcının cihaz saatini değiştirmesi gibi durumları düşünün.
Performans: her şeyi canlı yeniden hesaplamadan hızlı raporlar
Ajanslar haftalık ve aylık görünümlerde yaşar—kullanım, proje marjı, müşteri karlılığı. Her pano ham girişlerden yeniden toplamlar hesaplayarak yüklenecek olursa darboğaza girersiniz.
Günlük/haftalık en yaygın dilimlerde ön-aggregasyon kullanın ve girişler değiştiğinde bunları kademeli güncelleyin. Pahalı "ne-olurdu" hesaplamalarını ana raporlama yolundan ayrı tutun.
Denetlenebilirlik: kim neyi, ne zaman değiştirdi
Parayı etkileyen her değişiklik izlenmeli: zaman girişi düzenlemeleri, tarife güncellemeleri, bütçe değişiklikleri, silmeler ve onaylar. Aktörü, zaman damgasını, önceki ve yeni değeri ve bir neden notunu yakalayın.
Bu sadece uyumluluk için değil—anlaşmazlıkları hızla çözmek ve yöneticilerin sayılara güvenmesini sağlamak içindir.
Yayınlayın, benimsemeyi yönetin ve başarıyı ölçün
Zaman takip uygulamasının kaderi ilk birkaç haftada belli olur. Yayını bir davranış değişikliği projesi gibi ele alın: sürtünmeyi azaltın, beklentileri belirleyin ve işi yapanlara ilerlemeyi görünür kılın.
Yayın kontrol listesi (1. gün tanıdık hissettirsin)
Net bir geçiş planı ile başlayın: hangi verilerin taşınması gerektiği (müşteriler, projeler, kullanıcılar, tarife kartları), hangi verilerin sıfırdan başlayabileceği (geçmiş zaman çizelgeleri) ve kimin onayladığı.
Şablonlar ve akıllı varsayılanlar hazırlayın ki ekipler boş formlarla karşılaşmasın:
- Önceden doldurulmuş faz/görevlerle ortak proje tipleri
- Varsayılan faturalandırılabilir vs. faturalandırılamayan kategoriler
- Rol/kıdem bazlı tarife kartı varsayılanları
- Kullanım için ön ayarlı haftalık kapasite (kullanım oranı için)
Bir faturalama döngüsü için kısa bir pilot çalıştırın, sonra ajans genelinde yaygınlaştırın. Uygulama içinde “60 saniyede nasıl zaman kaydedilir” kılavuzu bulundurun (örn. /help sayfası).
Benimsemeyi arttırma (rutinlere odaklanın)
Alışkanlık yaratmak için nazik otomasyon kullanın:
- Gün eksik günlere göre hatırlatmalar, genel spam değil
- Her Cuma haftalık özetler: kaydedilen saatler, eksik girişler, faturalandırılabilir/olmayan kırılım
- Yöneticiler için istisnaları vurgulayan panolar (gecikmiş zaman çizelgeleri, büyük aşımlar), her detayı değil
Onayları hafif tutun: bir yönetici haftayı dakikalar içinde onaylayabilmeli; yorumlar yalnızca bir şey yanlışsa gereksin.
Başarıyı ölçün (değer üreten metrikler)
Küçük bir operasyonel gösterge seti izleyin:
- Zaman çizelgesi tamamlama oranı (takım ve haftalık bazda)
- Faturalandırma gecikmesi (ay sonundan faturanın gönderilmesine kadar geçen süre)
- Marj görünürlüğü (güncel maliyet vs. bütçe içeren proje payı)
Geri bildirimle yineleyin (önce basitleştir, sonra otomatikleştir)
İlk ayda sürtünç noktaları kaldırmaya öncelik verin: daha az zorunlu alan, daha iyi varsayılanlar, daha hızlı giriş. Sonra tekrarlayan kısımları otomatikleştirin—önerilen görevler, devreden zamanlayıcılar, anomali bayrakları—gerçek kullanım verilerine dayalı olarak, varsayımlara değil.
SSS
Ajans zaman takibi ve karlılık uygulaması geliştirirken birincil hedef ne olmalı?
İyileştirmek istediğiniz çıktıları tanımlayarak başlayın:
- Faturalandırılabilir saatlerin daha doğru olması (eksik/tahmini girişlerin azalması)
- Onayların daha hızlı olması (hafta sonu kovalamacalarının azalması)
- Faturalamaya daha az gecikme (onaylanmış süre doğrudan faturalamaya akması)
- Güvenilir karlılık (tutarlı gelir ve maliyet hesaplamaları)
Eğer “başarıyı” ölçemiyorsanız, ekipler özellikler üzerinde tartışır; davranışı düzeltmezsiniz.
Bir ajans zaman takip sisteminin temel kullanıcıları kimler ve neyle ilgilenirler?
Üç farklı motivasyona sahip grup için tasarlayın:
- Sahipler: müşteri/proje/ay bazında rollup'lar ve net marjlar
- Proje yöneticileri: bütçe tüketimi, kapsam sürüşünü tespit etme, onaylar
- Ekip üyeleri/taşeronlar: hızlı, düşük sürtünmeli zaman girişi ve neyi takip edeceklerinin netliği
Bu ihtiyaçlar çatıştığında, günlük UX’i zaman girişi yapmak zorunda olanlar lehine önceliklendirin; yönetimsel karmaşıklığı raporlar ve izinlerde tutun.
Ajans içinde uygulamada “karlılık” nasıl tanımlanmalı?
En az aşağıdakileri saklayın:
- Gelir: fatura edilen/tanımlanan tutar (genellikle onaylanmış faturalandırılabilir zamanlardan türetilir)
- İşçilik maliyeti: iç saatlik maliyetler + taşeron maliyetleri
- (İsteğe bağlı) Genel gider tahsisi: “gerçek marj” için sonra ekleyin
Erken karar verin: raporlarınız proje marjı (doğrudan işçilik) mı yoksa gerçek marj (genel gider dahil) mı gösterecek; aksi halde raporlar çelişebilir.
Neden elektronik tablolar ve ayrı zamanlayıcılar genellikle ajanslar için başarısız olur?
Çünkü birden fazla “gerçek” versiyon yaratırlar:
- Tutarsız müşteri/proje/görev kategorileri
- Eksik onaylar ve geç düzenlemeler
- Faturalara manuel kopyala-yapıştır
- Sayılar değiştiğinde iz yok
Tek bir sistemle net iş akışları (kaydet → gönder → onayla → fatura/dışa aktar) sağlanır; bu da eksik faturalamayı önler ve karlılık raporlarını güvenilir kılar.
Uygulama hangi iş akışlarını desteklemeli (zaman girişi → faturalama arası)?
Pratik bir v1 iş akışı şudur:
- Günlük zaman kaydı (zamanlayıcı veya manuel)
- Haftalık zaman çizelgesi gönderimi (basit “onaya hazır” adımı)
- Onay/red ve yorum (PM/Finans)
- Dönemi kilitleme (düzenleme için açma + yeniden onay gerekir)
Bu, faturalama ve raporlama için temiz veri sağlar ve herkesi aynı kayıt tarzına zorlamadan çalışır.
Doğru izleme ve raporlama için hangi veri modeli varlıkları gereklidir?
Çekirdek varlıkları küçük ve iyi ilişkili tutun:
- Müşteriler, kişiler, projeler, görevler/faaliyetler
- Kişiler (çalışan/taşeron) ve roller
- Zaman girişleri (tarih/zaman damgaları, dakika cinsinden süre, faturalandırılabilir bayrak, notlar)
- Onaylar/kilit dönemleri ve denetim olayları
- Tarifeler ve maliyetler (etkili tarihlerle)
Raporlar öncelikliyse, gerekli meta veriyi giriş sırasında yakalayın (proje, görev/tipi, kişi) — sonradan raporda düzeltmeye çalışmayın.
Tarifeler nasıl modellenmeli ki faturalar ve raporlar beklenmedik şekilde değişmesin?
Tarifeleri net geçersiz kılma kurallarıyla modelleyin, sonra uygulanan tarifeyi onay anında zaman girişine dondurun:
- Role dayalı tarifeler (ör. Tasarımcı, PM)
- Kişisel istisna tarifeleri
- Müşteri özel tarife kartları (müzakere edilmiş fiyatlar)
Onaylanan girişe uygulanan fatura tarifesini (ve isteğe bağlı maliyet tarifesini) saklayın, böylece tarife kartları güncellendiğinde faturalar değişmez.
Saatlik, sabit ücretli ve retainer projeleri tek bir üründe nasıl desteklenir?
Hepsini, insanların zaman kaydetme şeklini değiştirmeden destekleyin:
- Saatlik: faturalandırılabilir zaman × tarife, satır düzeyinde düzeltme geçmişi ile
- Sabit ücret: bütçe tüketimi (saat/maliyet) ve zaman içindeki marj eğilimi
- Retainer: aylık tahsisatlar, rollover kuralları ve aşım ücretlendirme tarifeleri
Önemli olan zaman kaydetme biçimini fiyatlandırma ve raporlamadan ayırmaktır.
V1'de dahil edilmesi gereken en önemli metrikler ve formüller nelerdir?
V1 için küçük bir metrik seti seçin ve bunları tek bir kez tanımlayın:
- Faturalandırılabilir tutar =
billable_hours × bill_rate - EHR =
revenue ÷ hours_logged(veyabillable_amount ÷ billable_hours) - İşçilik maliyeti =
internal_labor_cost + contractor_cost - Brüt marj =
(revenue − cost_of_labor) ÷ revenue - Kullanım oranı =
billable_hours ÷ available_hours(“available” açıkça tanımlanmalı)
Aynı tanımları zaman çizelgelerinde, proje görünümlerinde ve raporlarda kullanın, tartışmaları önleyin.
İleri düzey karlılık özellikleri inşa etmeden önce bir MVP neleri içermeli?
Bir döngüyü kanıtlamaya odaklanın: zaman kaydet → onayla → marjları gör.
İçerik:
- Hızlı zaman girişi (klavye öncelikli, sık kullanılanlar, öneriler)
- Zamanlayıcı + manuel giriş, net yuvarlama ve boşta kalma işlemleriyle
- Haftalık gönderim ve onay kuyruğu
- Proje başına basit bir marj raporu (maliyet vs faturalandırılabilir değer)
Temel güven sağlandıktan sonra tahminleme, otomasyon ve entegrasyonları ekleyin. Ayrıca /help ve /pricing gibi yerlerde rehberlik sunun.