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.
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.
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.
Ölçülebilecek çıktılarla başlayın:
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.
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ı.
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.
Ç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.
Zaman takibi, projeler ajansların fiyatladığı şekilde kurulmuşsa işe yarar:
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 genellikle öngörülebilir bir akışta (haftalık veya iki haftada bir) olur. Netleştirin:
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 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.
Küçük, iyi bağlı bir nesne seti ile başlayın:
İlgili her rapor nihayetinde zaman girişlerine dayanır. En azından saklayın:
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.
Ajanslar nadiren tek bir saatlik ücret kullanır. Tarifeleri üst üste koyulacak şekilde modelleyin:
Pratik bir kural: onay anında zaman girişine uygulanan tarifeyi saklayın ki tarife kartları düzenlense bile faturalar değişmesin.
Karlılık için sadece faturalandırılabilirlik yetmez; maliyet gerekir:
Bu parçalarla, ajansları tek bir katı iş akışına zorlamadan gelir, maliyet ve marj hesaplayabilirsiniz.
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 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:
Bu, faturalandırılabilir saat takibini doğru tutarken hesap ekiplerinin müşteri beklentileriyle eşleşmesini sağlar.
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:
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 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:
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.
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.
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).
Her ajansın anlayacağı üç alanla başlayın:
Formüller:
billable_hours × bill_raterevenue ÷ hours_logged (veya zaman & malzeme için billable_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).
Karlılık için maliyet gerekir; basit tutun ve ilk aşamada sadece işçiliği dahil edin:
internal_labor_cost + contractor_cost(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.
Kullanım oranı kafa karıştırıcı olabilir; bu yüzden “kullanılabilir saatleri” açıkça tanımlayın.
billable_hours ÷ available_hoursBu tanımı uygulama içinde belgelendirin ki raporlar tartışmaya dönüşmesin.
Bütçeleri saat ve para biriminde izleyin:
actual_hours − budget_hoursactual_revenue_or_cost − budgeted_revenue_or_costEş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.
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.
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:
Bazı kişiler zamanlayıcıları sever; bazıları manuel giriş tercih eder. İkisini destekleyin.
Zamanlayıcılar için pratik tutun:
Haftalık zaman çizelgeleri benimsenmenin kazanıldığı yerdir.
Bir hafta görünümü sunun ve şunları destekleyin:
Notları isteğe bağlı ama faturalama için gerektiğinde kolay eklenebilir tutun.
Mobil her özelliğe ihtiyaç duymaz. Şunlara odaklanın:
Onaylar önemliyse, bunların bir dakikadan kısa sürede yapılabilir olmasını sağlayın—aksi halde faturalama tıkanır.
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.
Çoğu ajansın ihtiyaçlarının %95'ini beş rol karşılar:
V1'de bir “özel rol oluşturucu” yapmaktan kaçının. Bunun yerine birkaç geçiş (örn. “Zaman onaylayabilir”, “Finansal verileri görebilir”) ekleyin.
Onaylar tutarlılığı zorlamalı ama insanları yavaşlatmamalı:
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.
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).
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 ç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.
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.
Birçok ajans hâlihazırda muhasebe veya faturalama araçları kullanır. Entegrasyon seçenekleri sağlayın:
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.
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.
İ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:
Uç noktaları basit ve öngörülebilir tutun:
Create eylemleri için idempotentlik ve net doğrulama hataları ekleyin—insanlar birden çok cihazdan saat girecek.
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.
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.
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.
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:
Bu, onboarding süresini kısaltır ve demoların somut hissettirmesini sağlar.
MVP’niz bir kapalı döngü sonucu sunmalı: zaman kaydet → zaman çizelgelerini onayla → marjları gör.
İçermeli:
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.
Ekipler düzenli zaman göndermeye ve onaylamaya başladıktan sonra ileriye dönük araçlar ekleyin:
Çekirdek iş akışı güvenilir hale gelince UI'ı şişirmeden genişletin:
Kural: her yeni özellik ya veri doğruluğunu artırmalı ya da sistemi yönetme süresini azaltmalı.
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.
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.
Küçük "matematik tuhaflıkları" büyük anlaşmazlıklara yol açar. Kurallarınızı belirleyip belgeleyin:
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.
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.
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.
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.
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:
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ı).
Alışkanlık yaratmak için nazik otomasyon kullanın:
Onayları hafif tutun: bir yönetici haftayı dakikalar içinde onaylayabilmeli; yorumlar yalnızca bir şey yanlışsa gereksin.
Küçük bir operasyonel gösterge seti izleyin:
İ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.
İyileştirmek istediğiniz çıktıları tanımlayarak başlayın:
Eğer “başarıyı” ölçemiyorsanız, ekipler özellikler üzerinde tartışır; davranışı düzeltmezsiniz.
Üç farklı motivasyona sahip grup için tasarlayın:
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.
En az aşağıdakileri saklayın:
Erken karar verin: raporlarınız (doğrudan işçilik) mı yoksa (genel gider dahil) mı gösterecek; aksi halde raporlar çelişebilir.
Çünkü birden fazla “gerçek” versiyon yaratırlar:
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.
Pratik bir v1 iş akışı şudur:
Bu, faturalama ve raporlama için temiz veri sağlar ve herkesi aynı kayıt tarzına zorlamadan çalışır.
Çekirdek varlıkları küçük ve iyi ilişkili tutun:
Raporlar öncelikliyse, gerekli meta veriyi giriş sırasında yakalayın (proje, görev/tipi, kişi) — sonradan raporda düzeltmeye çalışmayın.
Tarifeleri net geçersiz kılma kurallarıyla modelleyin, sonra uygulanan tarifeyi onay anında zaman girişine dondurun:
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.
Hepsini, insanların zaman kaydetme şeklini değiştirmeden destekleyin:
Önemli olan zaman kaydetme biçimini fiyatlandırma ve raporlamadan ayırmaktır.
V1 için küçük bir metrik seti seçin ve bunları tek bir kez tanımlayın:
Bir döngüyü kanıtlamaya odaklanın: zaman kaydet → onayla → marjları gör.
İçerik:
Temel güven sağlandıktan sonra tahminleme, otomasyon ve entegrasyonları ekleyin. Ayrıca /help ve /pricing gibi yerlerde rehberlik sunun.
billable_hours × bill_raterevenue ÷ hours_logged (veya billable_amount ÷ billable_hours)internal_labor_cost + contractor_cost(revenue − cost_of_labor) ÷ revenuebillable_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.