> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ferrufino-tech-solutions.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Ersten Case erstellen
> Schritt-für-Schritt Anleitung für Ihren ersten Case in FTS
Diese Anleitung zeigt Ihnen, wie Sie Ihren **ersten Case erstellen**. Wir werden einen echten Wartungsfall durchgehen – von der Idee bis zur Veröffentlichung.
## Szenario: Motorlager-Austausch
Stellen Sie sich vor, Ihr Team hat gerade ein Problem mit einem defekten Motorlager behoben. Sie möchten diesen Lösungsablauf für zukünftige Techniker dokumentieren.
## Schritt 1: Case initiieren
Loggen Sie sich in FTS ein und gehen Sie zum **Dashboard**
Klicken Sie in der Seitenleiste auf **Neuer Fall**
Wählen Sie optional eine **Vorlage** (z.B. "Wartungsverfahren") oder starten Sie leer
Sie sehen ein leeres Case-Formular
## Schritt 2: Grundinformationen ausfüllen
Das Formular hat genau diese Felder. Die beiden mit `*` sind Pflicht — ohne sie
lässt sich der Fall nicht speichern:
Der Bereich **Vorlage verwenden** über den Feldern ist kein Feld des Falls: Er
belegt Schweregrad, Kategorie, Tags sowie Beobachtung und Lösung vor, und jeder
vorbelegte Wert bleibt änderbar. Angelegt werden Vorlagen im
Einstellungsbereich **Fall-Vorlagen**.
*Diese Seite hat die Vorlage immer genannt; die englische Fassung tat es lange
nicht, obwohl sie dort „genau diese Felder" behauptete (offener Punkt #349).*
| Feld | Pflicht | Beispiel |
| ----------------------------------- | ------- | --------------------------------------------------------- |
| **Arbeitsbereich** | ja | Instandhaltung |
| **Titel** | ja | Motorlager austauschen – schrittweise Anleitung |
| **Beobachtung / Symptome** | ja | Lager läuft heiß, Schleifgeräusch unter Last |
| **Ursache** | nein | Schmierfilm abgerissen, Lagerspiel außerhalb der Toleranz |
| **Lösung / Durchgeführte Schritte** | nein | Der Ablauf aus Schritt 3 |
| **Schweregrad** | nein | Hoch |
| **Kategorie** | nein | Hardware |
| **Tags** | nein | Motor, Lager |
| **Sprache** | nein | Deutsch |
**Eine frühere Fassung dieser Tabelle nannte zwei Felder, die es nicht gibt.**
Sie führte „Beschreibung" und „Priorität" — das Formular hat weder das eine noch
das andere: das Textfeld heißt **Beobachtung / Symptome** und ist Pflicht, und
die Auswahlliste heißt **Schweregrad**. Beide Pflichtfelder fehlten in der
Aufzählung ganz. Wer der alten Tabelle folgte, konnte den Fall nicht speichern.
Die Werte für **Schweregrad** und **Kategorie** kommen außerdem aus den drei
Taxonomie-Listen Ihrer Organisation; „Wartung" stand dort als Beispiel, ist aber
in der Auslieferung kein Kategoriewert. Siehe [Taxonomie](/de/features/taxonomy).
## Schritt 3: Schritte schreiben
Die Schritte gehören in das Feld **Lösung / Durchgeführte Schritte**. Das ist ein
einfaches, mehrzeiliges Textfeld — Sie schreiben den Ablauf als Fließtext hinein.
Hier ein Beispiel:
```text theme={null}
1. Vorbereitung
- Motor abschalten und 15 Minuten abkühlen lassen
- Werkzeuge bereitstellen: Lagerschlüssel, kalibrierter Drehmomentschlüssel
- Motorblock mit Tüchern abdecken (Öl-/Metallspäneschutz)
2. Altes Lager entfernen
- Lagerschraube mit Lagerschlüssel entfernen (gegen Uhrzeigersinn)
- Altes Lager vorsichtig abziehen
- Motorbohrung mit Tuch reinigen
3. Neues Lager installieren
- Neues Original-Lager (Teil-Nr.: MOT-87654) auspacken
- Lager zentriert in Motorbohrung positionieren
- Lagerschraube handfest eindrehen
- Mit Drehmomentschlüssel auf 45 Nm festziehen
4. Qualitätsprüfung
- Lager auf Verschleiß-Geräusche prüfen (kurz hochfahren)
- Ölstand kontrollieren
- 10-minütige Testfahrt durchführen
```
**Eine „Schritte"-Sektion gibt es nicht, und Markdown wird nicht formatiert.**
Eine frühere Fassung dieser Seite schickte Sie in eine Sektion dieses Namens und
zeigte das Beispiel als Markdown mit `###`-Überschriften. Das Formular hat keinen
solchen Abschnitt — es gibt genau die drei Textfelder aus Schritt 2 — und alle
drei werden unformatiert ausgegeben, in der Anwendung wie im PDF-Export. Wer
Rauten schreibt, sieht später Rauten. Dasselbe steht auf
[Konzepte](/de/concepts): einfache Textfelder, kein Rich-Text.
Schreiben Sie konkret und checklisten-orientiert. Ziel ist, dass ein neuer Techniker EXAKT folgen kann.
## Schritt 4: Tags hinzufügen
Tippen Sie im Feld **Tags** die Wörter ein, unter denen Ihr Team den Fall später
suchen soll, und bestätigen Sie jedes mit Enter oder Komma:
* `wartung`
* `motor`
* `lager`
* `vorbeugende-wartung`
**Ein Tag, das es noch nicht gibt, entsteht dadurch, dass Sie es eintippen — in
jeder Rolle.** Sie brauchen dafür weder die Admin-Rolle noch einen bestimmten
Tarif; es genügt, Mitglied der Organisation zu sein. Tags sind freier Text und
werden beim Speichern in Kleinschreibung abgelegt (höchstens 50 Zeichen). Es gibt
auch **keine Tag-Gruppen**: Ein Tag hat einen Namen und sonst nichts, alle Tags
eines Falls stehen auf derselben Ebene.
**Eine frühere Fassung dieses Kastens sagte das Gegenteil** — Tags anzulegen
setze die Admin-Rolle voraus, sonst solle man den Workspace-Admin fragen. Das war
falsch und schickte Sie zu einer Nachfrage, die nichts bewirkt. Verwechselt
worden waren Tags mit den **drei festen Taxonomie-Listen** (Arbeitsbereichstypen,
Schweregrade, Kategorien): *die* zu ändern setzt tatsächlich die Admin-Rolle
**und** den Tarif Team oder Enterprise voraus. Siehe
[Taxonomie](/de/features/taxonomy).
## Schritt 5: Nachweise hochladen
Scrollen Sie auf der Case-Seite zum Bereich **„Nachweise"** — er steht dort als eigener Kasten, einen Reiter dafür gibt es nicht — und fügen Sie Bilder oder PDFs hinzu (Logdateien werden nicht angenommen):
1. Klicken Sie auf **+ Datei hochladen** oder ziehen Sie Dateien rein
2. Wählen Sie aussagekräftige Dateien:
* **Lager-Austausch-Schritt-2.jpg** – altes Lager
* **Lager-Austausch-Schritt-3.jpg** – Installation
* **Ölstand-Prüfung.jpg** – Qualitätskontrolle
3. Der Dateiname ist alles, was den Nachweis beschriftet — wählen Sie ihn
entsprechend
**Ein Feld für eine Bildbeschreibung gibt es nicht.** Eine frühere Fassung dieser
Seite bot an, optional Beschreibungen wie „Altes Lager zeigt Verschleiß"
hinzuzufügen. Der Nachweis-Bereich lädt die Datei und sonst nichts hoch; es gibt
kein Eingabefeld für Titel oder Beschreibung. Dasselbe steht auf
[Nachweise](/de/features/evidence). Sprechende Dateinamen sind deshalb der
einzige Weg, einen Nachweis zu benennen.
Dies ist eine Tatsache des Datenschutzes, kein Funktionshinweis. Ab dem
**Team**-Tarif liest FTS hochgeladene Bilder und PDFs kurz nach dem Hochladen
mit Texterkennung aus. Dabei **wird die Datei selbst zu Anthropic in die USA
übertragen** — dorthin, wo sie verarbeitet wird. Ihre Datenbank und Ihre
Dateien liegen in der EU; dieser eine Schritt nicht. Wenn ein Dokument die EU
niemals verlassen darf, laden Sie es hier nicht als Nachweis hoch. Einzelheiten
stehen unter [Nachweise](/de/features/evidence).
## Schritt 6: Review einreichen
Sobald der Case fertig ist:
Öffnen Sie den Fall und klicken Sie **„Zur Prüfung einreichen"** (nicht „Änderungen speichern")
Der Fall wechselt in den Status **„In Prüfung"** und erscheint in der Prüfliste
aller Mitglieder der Organisation mit der Rolle **Reviewer** oder **Admin**.
Zusätzlich werden diese in der Anwendung und per E-Mail benachrichtigt — Sie
selbst sind davon ausgenommen. In sehr großen Organisationen ist die Zahl der
verschickten Benachrichtigungen je Einreichung begrenzt; die Prüfliste zeigt den
Fall in jedem Fall allen Prüfberechtigten.
**Sie wählen keinen einzelnen Prüfer aus, und Sie können beim Einreichen keine
Nachricht mitgeben.** Das Einreichen benachrichtigt die Prüfberechtigten
gemeinsam; wer den Fall übernimmt, entscheidet Ihr Team. Möchten Sie eine
bestimmte Person ansprechen, tun Sie das außerhalb der Anwendung.
**Jeder Fall ist für jedes Mitglied Ihrer Organisation sichtbar — auch im Status
„Entwurf" und in jeder Rolle.** Es gibt keine Sichtbarkeitseinstellung je Fall
und keine Kennzeichnung „nur intern"; ein Tag ändert daran nichts. Ein Entwurf
ist ein **unfertiger**, kein **privater** Fall. Was das ganze Team nicht sehen
soll, gehört nicht in einen Fall.
Für den Ablauf gilt trotzdem: erst mit **„Zur Prüfung einreichen"** geht der
Fall in die Prüfung und kann danach veröffentlicht werden.
## Schritt 7: Reviewer-Feedback einarbeiten
Der Prüfer öffnet den Fall, klickt **„Prüfen"** und entscheidet sich im Dialog
für **eine von zwei** Möglichkeiten. Beide erlauben einen optionalen Kommentar.
### Verifizieren ✓
Der Fall wechselt in den Status **„Verifiziert"**. Sie erhalten eine
Benachrichtigung in der Anwendung und per E-Mail.
### Änderungen anfordern
Sie erhalten denselben Weg eine Benachrichtigung, dazu den Kommentar des Prüfers.
Bearbeiten Sie den Fall und reichen Sie ihn erneut ein.
**Verifiziert ist noch nicht veröffentlicht.** Das Veröffentlichen ist ein
eigener Schritt: Jemand mit der Rolle **Reviewer** oder **Admin** klickt
**„Veröffentlichen"**. Es geschieht nicht automatisch.
Es gibt außerdem **keine Frist und keine Erinnerung** — bleibt ein Fall liegen,
sprechen Sie die Prüfberechtigten selbst an. Und es gibt **keine
Inline-Diskussion**: Ein Prüfergebnis trägt genau einen Kommentar, keinen
Gesprächsverlauf.
## Schritt 8: Veröffentlichter Case
Nach dem Veröffentlichen:
* ✅ Case ist **suchbar** für Ihr ganzes Team
* ✅ Techniker können den Case als Anleitung nutzen
* ✅ Der Verlauf des Falls zeigt Einreichung, Prüfung und Veröffentlichung mit Datum
* ✅ Eine spätere Bearbeitung setzt den Fall auf **Entwurf** zurück — er muss erneut geprüft werden
## Best Practices
Halten Sie einen Fall auf einem Vorgang. Wird die Beschreibung so lang, dass sie
mehrere voneinander unabhängige Vorgänge behandelt, teilen Sie sie auf mehrere
Fälle auf. **Eine Zahl nennen wir hier bewusst nicht:** Eine frühere Fassung
empfahl „5-15 Schritte" — das Formular zählt keine Schritte, es hat ein
freies Textfeld, und die Empfehlung war unbelegt.
Hochwertige Bilder und gut lesbare PDFs sind wichtiger als viele Dateien. 3-5 gute Nachweise > 20 schlechte.
Nutzen Sie Ihr Team-Deutsch (formell/informal). Konsistenz hilft dem Verständnis.
Ist der Fall später überholt? Archivieren Sie ihn über **„Löschen"** — er
bekommt den Status **„Archiviert"**, verschwindet aus der Suche und bleibt für
den Verlauf erhalten. Über **„Wiederherstellen"** kommt er als **Entwurf**
zurück und durchläuft die Prüfung erneut.
Eine automatische Versionierung gibt es nicht: Eine neue Fassung ist ein neuer
Fall, den Sie bei Bedarf mit dem alten verknüpfen.
## Nächste Schritte
Laden Sie Kollegen ein, um Cases zu erstellen
Konvertieren Sie alte Excel-Listen zu Cases