Erfahren Sie, wie Sie eine Web-App planen und bauen, die Agenturen hilft, abrechenbare Stunden, Budgets, Auslastung und echte Projekt-Rentabilität mit klaren Berichten zu verfolgen.

Bevor Sie Bildschirme entwerfen oder eine Datenbank wählen, werden Sie konkret, wie „Erfolg“ für die Menschen aussieht, die täglich in der App arbeiten. Agenturen scheitern bei der Zeiterfassung weniger wegen fehlender Features als vielmehr, weil das Ziel vage ist.
Agenturinhaber wollen Sicherheit: „Verdienen wir mit diesem Retainer wirklich Geld?“ Sie brauchen Rollups über Kunden, Teams und Monate.
Projektmanager benötigen Kontrolle und Geschwindigkeit: Burn vs. Budget verfolgen, Scope Creep früh erkennen und Timesheets rechtzeitig genehmigen.
Teammitglieder (und Contractors) wollen Einfachheit: Zeit schnell erfassen, wissen, wofür sie erfassen, und nicht wegen fehlender Einträge verfolgt werden.
Starten Sie mit Ergebnissen, die Sie messen können:
Mindestens bedeutet Rentabilität:
Umsatz (fakturiert oder anerkannt) minus Arbeitskosten (interne Kostensätze für Mitarbeiter + Contractor-Gebühren) minus Overhead-Zuordnung (anfangs optional, aber wichtig für echte Margen).
Auch wenn Sie Overhead nicht am ersten Tag modellieren, entscheiden Sie, ob Sie auf Projektmarge (nur direkte Arbeit) oder echte Marge (inkl. Overhead) abzielen. Das klare Benennen verhindert später verwirrende Reports.
Spreadsheets und separate Timer führen meist zu inkonsistenten Kategorien, fehlenden Genehmigungen und unterschiedlichen „Wahrheiten“. Das Ergebnis ist vorhersehbar: unterfakturierte Stunden, verspätete Rechnungen und Rentabilitätsberichte, denen niemand genug vertraut, um zu handeln.
Bevor Sie UI entwerfen, kartieren Sie, wie Arbeit tatsächlich durch eine Agentur fließt – von „wir müssen Zeit erfassen“ bis „wir haben fakturiert und Margen überprüft“. Wenn Ihre App bestehende Gewohnheiten abbildet, ist die Adoption einfacher und die Datenqualität besser.
Die meisten Agenturen nutzen eine Mischung aus Timer-basierter Erfassung (ideal für fokussierte Arbeit und genaue Start/Stopp) und manueller Eingabe (nach Meetings, bei Kontextwechseln oder mobil). Unterstützen Sie beides und lassen Sie Teams wählen.
Entscheiden Sie auch, ob Ihr Workflow auf täglicher Erfassung (bessere Genauigkeit, weniger Panik am Ende der Woche) oder wöchentlichen Timesheets (üblich bei Genehmigungen) zentriert ist. Viele Teams wollen tägliche Erinnerungen, aber einen wöchentlichen Einreichschritt.
Zeiterfassung funktioniert nur, wenn Projekte so eingerichtet sind, wie Agenturen verkaufen:
Während des Mappings notieren Sie, wer Kunden/Projekte anlegt (Ops, PMs, Account Manager) und was sie brauchen: Service-Lines, Rollen, Standorte oder Ratecards.
Genehmigungen erfolgen typischerweise in einem vorhersehbaren Rhythmus (wöchentlich oder zweiwöchentlich). Klären Sie:
Agenturen prüfen häufig Margen nach Projekt, Kunde, Service-Line und Person. Das frühe Mapping dieser Reporting-Erwartungen verhindert Nacharbeit – denn es bestimmt, welche Metadaten bei der Zeiterfassung erfasst werden müssen, nicht erst im Nachhinein.
Ihr Datenmodell ist der Vertrag zwischen Produkt, Reports und Rechnungen. Wenn Sie es früh richtig machen, können Sie UI und Workflows später ändern, ohne die Rentabilitätsberechnungen zu zerstören.
Starten Sie mit einer kleinen, gut verknüpften Menge von Objekten:
Jeder Bericht, den Sie wollen, hängt letztlich von Zeiteinträgen ab. Mindestens speichern Sie:
Erfassen Sie außerdem Fremdschlüssel: Person, Projekt, Task/Activity – und immutable created_at/updated_at Timestamps für Auditfähigkeit.
Agenturen nutzen selten einen einzigen Stundensatz. Modellieren Sie Sätze so, dass sie sich gegenseitig überschreiben können:
Eine praktische Regel: speichern Sie den auf den Zeiteintrag angewendeten Satz zum Genehmigungszeitpunkt, damit Rechnungen sich nicht ändern, wenn Ratecards später editiert werden.
Rentabilität benötigt Kosten, nicht nur Umsätze:
Mit diesen Bausteinen können Sie Umsatz, Kosten und Marge berechnen, ohne Agenturen in einen starren Workflow zu zwingen.
Wenn Ihre Zeiterfassungs-App nur stundenbasierte Abrechnung unterstützt, werden Menschen das Tool verbiegen – meist mit Tabellen und manuellen Notizen. Agenturen betreiben oft gemischte Portfolios (Stunden, Festpreis, Retainer), daher sollte Ihre App alle drei unterstützen, ohne die Art der Zeiterfassung zu ändern.
Stundenarbeit ist auf dem Papier einfach: abrechenbare Zeit × Satz. Knifflig wird es, weil Sätze variieren.
Unterstützen Sie Ratecards nach Rolle (Designer, PM), nach Person, nach Kunde oder nach Projekt. Dann fügen Sie kontrollierte Anpassungen hinzu:
Damit bleibt die Verfolgung abrechenbarer Stunden akkurat, während Account-Teams Kundenerwartungen abbilden können.
Festpreisprojekte leben davon, wie schnell das Budget verbraucht wird. Hier dient Zeiterfassung nicht nur der Rechnungsstellung, sondern der Projektbudgetierung und frühzeitigen Warnung.
Modellieren Sie ein Festpreisprojekt mit:
Zeigen Sie dann „Burn vs. Budget“ über die Zeit: Woche-für-Woche Burn, Forecast bis zum Abschluss und wie die Projektmargen mit Scope-Änderungen verlaufen. Machen Sie sichtbar, wenn ein Projekt heute profitabel ist, aber driftet.
Retainer sind wiederkehrend und regelreich. Ihr Tool sollte Teams erlauben, eine monatliche Allokation zu setzen (z. B. 40 Stunden/Monat) und zu definieren, was am Monatsende passiert:
Wenn Zeit die Allokation übersteigt, unterstützen Sie Overages, die zu einem definierten Satz berechnet werden (oft anders als die Standard-Ratecard). Halten Sie die Rechenwege transparent, damit Kunden den Totals vertrauen.
Agenturen brauchen nicht-abrechenbare Kategorien wie interne Arbeit, Pre-Sales, Admin und Training. Verstecken Sie diese nicht – behandeln Sie sie als gleichwertige Zeittypen. Sie treiben Auslastungsraten und Reporting und erklären, warum „busy" nicht immer „profitabel" bedeutet.
Eine Zeit- + Rentabilitäts-App gelingt, wenn alle den Zahlen vertrauen. Das bedeutet: wählen Sie eine kleine Kennzahlenmenge, definieren Sie sie einmal und nutzen Sie dieselben Formeln überall (Timesheets, Projektansichten und Berichte).
Starten Sie mit drei Feldern, die jede Agentur versteht:
Formeln:
billable_hours × bill_raterevenue ÷ hours_logged (oder billable_amount ÷ billable_hours für time \u0026 materials)EHR ist ein guter „Sanity-Check": Wenn zwei Projekte den selben Ratecard haben, aber extrem unterschiedliche EHRs, stimmt etwas nicht (Scope Creep, Rabatte, Abschreibungen).
Rentabilität braucht Kosten, nicht nur Umsatz. Halten Sie es einfach und inkludieren Sie anfangs nur Arbeit:
internal_labor_cost + contractor_cost(revenue − cost_of_labor) ÷ revenueDefinieren Sie interne Kosten als Stunden-Kostensatz (Gehalt + Steuern + Benefits, auf eine Stundenzahl umgelegt), damit die App sie automatisch aus den Timesheets berechnen kann.
Auslastung sorgt oft für Verwirrung — definieren Sie „verfügbare Stunden" explizit.
billable_hours ÷ available_hoursDokumentieren Sie diese Definition in der App, damit Reports nicht zu Debatten führen.
Verfolgen Sie Budgets in Stunden und Geld:
actual_hours − budget_hoursactual_revenue_or_cost − budgeted_revenue_or_costTriggern Sie einfache Alerts bei Schwellwerten (z. B. 80% verbraucht, dann 100% Overrun), damit PMs handeln können, bevor Margen verschwinden.
Wenn das Erfassen von Zeit wie Papierkram wirkt, meiden Menschen es — oder füllen es freitags mit Schätzungen. Ziel ist, Zeiterfassung schneller als Prokrastination zu machen und trotzdem verlässliche Daten für Billing und Rentabilität zu liefern.
Setzen Sie Geschwindigkeit über ausgefeilte Visuals. Ein gutes Default ist „eine Zeile = ein Eintrag" mit Projekt, Task/Activity, Dauer und optionaler Notiz.
Machen Sie die häufigsten Aktionen fast instant:
Manche lieben Timer; andere bevorzugen manuelle Eingabe. Unterstützen Sie beides.
Für Timer halten Sie es praktikabel:
Wöchentliche Timesheets sind entscheidend für Adoption.
Verwenden Sie eine Wochenansicht, die unterstützt:
Notizen optional, aber leicht hinzufügbar, wenn sie für die Rechnungsstellung erforderlich sind.
Mobile braucht nicht jede Funktion. Fokus auf:
Wenn Genehmigungen wichtig sind, machen Sie sie in unter einer Minute machbar — sonst werden sie zum Flaschenhals für Billing.
Wenn Agenturen nicht vertrauen, wer Zeit sehen, bearbeiten und genehmigen kann, trauen sie auch den Zahlen nicht. Rollen und Berechtigungen verhindern zudem „versehentliche Buchhaltung“ (z. B. ein Contractor, der genehmigte Timesheets des letzten Monats bearbeitet).
Die meisten Agenturen decken 95% der Bedürfnisse mit fünf Rollen:
Vermeiden Sie in v1 einen vollständigen Custom Role Builder. Besser ein paar Toggles (z. B. „Kann Zeit genehmigen“, „Kann Finanzdaten sehen") für Randfälle.
Beginnen Sie damit, die Ergebnisse zu definieren, die Sie verbessern wollen:
Wenn Sie „Erfolg“ nicht messen können, streiten sich Teams später über Funktionen statt das Verhalten zu ändern.
Entwerfen Sie für drei Gruppen mit unterschiedlichen Interessen:
Wenn diese Bedürfnisse kollidieren, priorisieren Sie die tägliche UX für die Personen, die die Zeit erfassen müssen, und halten Sie Management-Komplexität in Berichten und Berechtigungen.
Mindestens sollten Sie speichern:
Entscheiden Sie früh, ob Sie Projektmarge (nur direkte Arbeit) oder echte Marge (inkl. Overhead) berichten, damit sich Berichte später nicht widersprechen.
Weil sie mehrere „Wahrheiten“ erzeugen:
Ein einziges System mit klaren Workflows (log → submit → approve → invoice/export) verhindert Unterfakturierung und macht Rentabilitätsberichte vertrauenswürdig.
Ein praktischer V1-Workflow ist:
Das liefert saubere Daten für Billing und Reporting, ohne alle in denselben Erfassungsstil zu zwingen.
Halten Sie die Kernobjekte klein und gut verknüpft:
Wenn Berichte wichtig sind, erfassen Sie die benötigten Metadaten schon beim Eintrag (Projekt, Task/Typ, Person) statt später in Reports reparieren zu wollen.
Modellieren Sie Sätze mit klaren Überschreibungsregeln und „frieren“ Sie den angewendeten Satz auf dem genehmigten Eintrag ein:
Speichern Sie den angewendeten Abrechnungssatz (und optional den Kostensatz) auf dem Zeiteintrag zur Genehmigungszeit, damit Rechnungen nicht nachträglich durch Änderungen an Ratecards verändert werden.
Unterstützen Sie alle drei ohne das Logging-Verhalten zu ändern:
Die Trennung von wie Zeit erfasst wird und wie sie bepreist/berichtet wird ist der Schlüssel.
Wählen Sie eine kleine Menge Metriken und definieren Sie sie einmal:
billable_hours × bill_raterevenue ÷ hours_logged (oder billable_amount ÷ billable_hours)internal_labor_cost + contractor_cost(revenue − cost_of_labor) ÷ revenuebillable_hours ÷ available_hours (definieren Sie „available“ explizit)Verwenden Sie dieselben Definitionen in Timesheets, Projektansichten und Reports, um Debatten zu vermeiden.
Konzentrieren Sie sich auf eine MVP-Schleife: Zeit erfassen → genehmigen → Margen sehen.
Enthalten sein sollte:
Sobald Teams den Kern vertrauen, fügen Sie Forecasting, Automatisierung und Integrationen hinzu (und verweisen Sie auf Hilfen wie /help und /pricing).
Starten Sie mit einer kleinen Rollenmenge und einigen Schaltern für Sonderfälle:
Vermeiden Sie in v1 einen vollständigen „Custom Role Builder“; fügen Sie stattdessen ein paar Toggle-Optionen wie „Kann Zeit genehmigen“ oder „Kann Finanzdaten sehen“ hinzu.
Behandeln Sie Anpassungen nicht als unsichtbare Änderungen:
Erlauben Sie Write-offs/Anpassungen auf Zeilenebene oder als Rechnungsanpassung und verlangen Sie einen Reason Code wie Out of scope, Client request, Internal rework oder Discount. Das erklärt Margenänderungen später und erleichtert Kundengespräche.
Ein paar Regeln verhindern Vertrauensverlust:
Diese Regeln minimieren Streitpunkte über kleine Rechenfehler und sorgen für klare Prüfpfade.
Starten Sie mit einem klaren Migrationsplan: welche Daten müssen übertragen werden (Clients, Projekte, Nutzer, Ratecards), was kann neu beginnen (historische Zeiterfassungen) und wer signiert ab.
Stellen Sie Seed-Daten bereit, damit ein Workspace sofort klickbar ist:
Führen Sie ein kurzes Pilotprojekt mit einem Team für einen Abrechnungszyklus durch und rollen Sie dann agenturweit aus. Legen Sie eine „Wie man in 60 Sekunden Zeit erfasst“-Anleitung in /help ab.
Messen Sie eine kleine Menge Betriebskennzahlen:
In den ersten Wochen priorisieren Sie das Entfernen von Reibung (weniger Pflichtfelder, bessere Defaults). Später automatisieren Sie repetitive Aufgaben basierend auf realer Nutzung.