Mehrere Standorte

Überblick

Ziptask hat kein eigenes „Standort”-Objekt — und für die meisten Betriebe mit mehreren Standorten braucht es das auch nicht. Teams sind die Standortgrenze. Ein Team grenzt ab, wer eine bestimmte Gruppe von Listen sehen und bearbeiten kann. Wenn du also jeden Standort (oder jeden Standort + jede Abteilung) als eigenes Team abbildest, bleibt die Arbeit jedes Standorts sauber getrennt innerhalb eines einzigen Kontos — mit einem gemeinsamen Login, einem Satz Vorlagen und kontoweiten Berichten für die Inhaber.

Dieser Leitfaden beschreibt das empfohlene Muster, wann du es einsetzt und welche Grenzen du vor dem Skalieren kennen solltest.

Voraussetzung: Feature-Flag teams_enabled aktiviert. Eigene Rollen (weiter unten erwähnt) erfordern den Starter-Tarif oder höher. Siehe teams.md, permissions.md und feature-flags.md.

Zuerst entscheiden: abgrenzen oder nur kennzeichnen?

Es gibt zwei unterschiedliche Bedürfnisse, die sich ähnlich anfühlen. Wähle das, das dazu passt, wie deine Mitarbeitenden tatsächlich arbeiten — es bestimmt die gesamte Einrichtung.

Du möchtest…	Verwende	Warum
Dass die Mitarbeitenden jedes Standorts nur die Listen ihres eigenen Standorts sehen und bearbeiten	Teams	Teams erzwingen den Zugriff. Ein Teammitglied kann die Listen eines anderen Teams nicht sehen.
Ein gemeinsames Team, das zwischen Standorten wechselt, und du möchtest nur nach Standort filtern/berichten	Tags	Tags kennzeichnen und filtern Listen, schränken aber den Zugriff nicht ein — alle sehen weiterhin alles. Siehe tags.md.

Ein Kunde kann ebenfalls für einen Standort stehen, wenn der „Standort” in Wirklichkeit eine Kundenimmobilie ist, die du betreust (üblich bei Reinigung, Landschaftsbau und Immobilienverwaltung) — verknüpfe jede Liste mit dem Kunden und nutze den Verlauf des Kunden als standortbezogene Aufzeichnung.

Der Rest dieses Leitfadens geht davon aus, dass du Abgrenzung möchtest — getrennte Mitarbeitende pro Standort — was der übliche Fall für Filialen, Locations und Franchisebetriebe ist.

Das empfohlene Modell: Teams als Standort × Abteilung

Für einen Betrieb mit zwei Standorten, die jeweils eine Küche und einen Servicebereich haben, erstellst du vier Teams:

Standort A — Küche
Standort A — Service
Standort B — Küche
Standort B — Service

Weise dann Rollen danach zu, wie weit die Verantwortung einer Person reicht:

Person	Rolle	Teamzugehörigkeit
Mitarbeitende/Team an einem Standort + Abteilung	Team User	ihr einziges Team (z. B. `Standort A — Küche`)
Abteilungsleitung über ein Team	Team Admin	Dieses eine Team
Standortleitung über einen ganzen Standort	Team Admin	Beide Teams dieses Standorts (Küche + Service)
Inhaber / Regionalleitung (alle Standorte)	Admin oder Root	Keine Teamzugehörigkeit nötig

Zwei Dinge machen das möglich:

Mitglieder können mehreren Teams angehören. So erhält eine Standortleitung Admin-Rechte über beide Abteilungen ihres Standorts — füge sie beiden Teams als Team Admin hinzu. Siehe teams.md.
Root und Admin sehen alles kontoweit, unabhängig vom Team. Der Inhaber muss nicht zu jedem Team hinzugefügt werden — der Konto-Geltungsbereich deckt bereits alle Standorte ab. Reserviere die Zugehörigkeit zu mehreren Teams für die Standortleitungen, die sie benötigen.

Wenn du nur eine Standorttrennung benötigst (nicht Standort × Abteilung), fasse es zusammen: ein Team pro Standort (Standort A, Standort B).

Die Einrichtung

Aktiviere teams_enabled (Root, über die Kontoeinstellungen), falls noch nicht geschehen.
Erstelle die Teams — eines pro Standort oder eines pro Standort × Abteilung (Teams-Seite → Team erstellen). Siehe teams.md.
Füge Mitglieder zu ihren Team(s) hinzu und lege die Rolle jeder Person fest (Team User für Mitarbeitende, Team Admin für Führungskräfte). Eine Person in mehreren Teams erhält beim Erstellen von Listen eine Teamauswahl.
Erstelle die Listen jedes Standorts aus deinen Vorlagen. Erstelle die Liste aus einer Vorlage und weise ihr dann das richtige Standort-Team zu. Vorlagen werden kontoweit geteilt, sodass du die Checkliste einmal erstellst und pro Standort ausprägst. Siehe tasks.md.
Bei wiederkehrenden Routinen lege das Team auf der Master-Liste fest. Jede Instanz, die der Zeitplan erzeugt, erbt dieses Team automatisch — siehe unten.

Wie sich wiederkehrende Listen über Standorte hinweg verhalten

Eine wiederkehrende Master-Liste gehört zu einem Team, und jede Instanz, die sie erzeugt, erbt dieses Team. Eine Routine, die an beiden Standorten läuft, benötigt daher eine Master-Liste pro Standort-Team (z. B. eine nächtliche Abschluss-Master-Liste auf Standort A — Küche und eine weitere auf Standort B — Küche). Erstelle beide aus derselben Vorlage, damit sie identisch bleiben.

Dasselbe gilt für Zuweisungen: Wer der Master-Liste zugewiesen ist, wird automatisch auf jede erzeugte Instanz kopiert. So legst du das feste Team eines Standorts einmal auf der Master-Liste fest, und jede künftige Instanz übernimmt es. Siehe tasks.md und reminders.md.

Grenzen, die du kennen solltest

Eine Person hat eine Rolle pro Konto, die über alle ihre Teams hinweg gilt. Du kannst jemanden nicht in einem Team zum Team Admin und in einem anderen zum Team User machen — wenn jemand Team Admin ist, verwaltet er jedes Team, dem er angehört. Für die übliche Hierarchie (Führungskräfte verwalten ihre Standorte, Mitarbeitende arbeiten in ihrer Abteilung) ist das genau richtig; problematisch wird es nur, wenn jemand einen Standort verwalten, an einem anderen aber lediglich mitarbeiten soll.
Keine standortübergreifende Zusammenführung außerhalb von Root/Admin. Ein Team Admin sieht nur seine Teams. Kontoweite Sichtbarkeit und Berichte sind eine Root-/Admin-Ansicht (Inhaber). Siehe reporting.md und activity-log.md.
Teams sind die Abgrenzungseinheit — keine Abrechnungs- oder Datengrenze. Alle Standorte teilen sich ein Abonnement, ein Mitgliederverzeichnis, eine Bibliothek für Vorlagen/Tags/Kunden und einen Aktivitätsverlauf. Wenn du eine vollständig getrennte Abrechnung oder Datenhaltung pro Standort benötigst, verwende stattdessen separate Konten.

Support-Hinweise

Wenn eine Standortleitung die Listen eines Standorts nicht sehen kann, prüfe: (a) ob sie Mitglied der Team(s) dieses Standorts ist und (b) ob die Listen tatsächlich das richtige Team zugewiesen haben (sichtbar in der Seitenleiste der Listendetails). Listen ohne Team sind nur für ihren Ersteller und Root sichtbar. Siehe teams.md.
Wenn wiederkehrende Instanzen an einem neuen Standort nicht das richtige Team übernehmen, prüfe das Team und die Zuweisungen der Master-Liste — Instanzen erben beides beim Erzeugen von der Master-Liste, daher gehören Korrekturen auf die Master-Liste (und gelten für künftige Instanzen; bereits erzeugte werden einzeln bearbeitet).
Einen Standort umbenennen: Benenne das Team um (Teams-Seite). Bestehende Listen behalten ihre Zuordnung automatisch bei.
Einen Standort schließen: Das Löschen seines Teams entfernt das Team und seine Mitgliedschaften, aber nicht die Listen oder Aufgaben — weise diese Listen zuvor neu zu oder archiviere sie, wenn du sie aus dem aktiven Bestand nehmen möchtest.
Inhaber, die „die Standort-Funktion nicht finden”: Es gibt keine — dieses teambasierte Muster ist die Einrichtung für mehrere Standorte. Verweise sie auf diesen Leitfaden.