Ein internes Tool ist eine kleine, private Web-App, mit der Ihr Team Datensätze wie Lagerbestand, Anträge oder Kunden verwaltet. Mit einem KI-App-Builder beschreiben Sie Datensätze, Status und Rollen. Er baut Formulare, gefilterte Listen, Logins und einen Admin-Bereich und ersetzt die fehleranfällige gemeinsame Tabelle durch eine App, die Ihre Regeln durchsetzt.
- Ziehen Sie eine Tabelle in eine App um, wenn sich Kollegen gegenseitig überschreiben, Regeln in Zellkommentaren stehen oder niemand sagen kann, wer was geändert hat.
- Legen Sie Datensätze, Status und Rollen fest, bevor Sie den Prompt schreiben. Diese Übersicht ist schon der größte Teil des Prompts.
- Bestehende Zeilen übernehmen Sie, indem Sie eine CSV- oder XLSX-Datei anhängen und Wisy ausdrücklich bitten, sie zu laden.
- Logins, Rollen und ein Änderungsprotokoll sind Funktionen, die Sie beschreiben. Single Sign-on gibt es nicht, die Anmeldung mit Google funktioniert aber mit Ihren eigenen Zugangsdaten.
- Geplante Jobs für Übersichten laufen alle 30 bis 60 Minuten, nicht zu exakten Uhrzeiten.
- Kennen Sie die Grenzen vorab: Datenbankkapazität je Tarif, keine Volltextsuche über große Tabellen und kein Code-Export.
Anzeichen, dass Ihre Tabelle eine App werden sollte
Tabellen sind das beste Prototyping-Werkzeug, das die meisten Teams haben. Zum Risiko werden sie, wenn mehrere Leute einen Prozess über eine einzige Datei abwickeln. Achten Sie auf diese Anzeichen:
- Zwei Personen haben dieselbe Zelle bearbeitet, und eine Änderung ist stillschweigend verschwunden.
- Ein Zellkommentar sagt „Spalte F nicht anfassen“, und jemand hat Spalte F angefasst.
- In der Statusspalte stehen „Erledigt“, „erledigt“, „ERLEDIGT “ und „fertig“, also ist jeder Filter falsch.
- Niemand kann die Frage beantworten: „Wer hat diese Menge wann geändert?“
- Ein Lieferant oder Subunternehmer soll einige Zeilen sehen und bekommt deshalb die ganze Datei.
- Jemand kopiert jeden Morgen Zeilen in eine E-Mail, um den anderen mitzuteilen, was überfällig ist.
Damit sind Sie nicht allein. Die European Spreadsheet Risks Interest Group führt eine fortlaufende Sammlung öffentlich gewordener Tabellen-Pannen und stellt fest, dass solche Berichte in den Medien weltweit in recht gleichmäßigem Takt auftauchen und die Probleme unkontrollierter Tabellennutzung zeigen.
Behalten Sie die Tabelle für Analysen, Modelle und Arbeit, die eine Person allein erledigt. Eine interne App ist für gemeinsam genutzte operative Datensätze gedacht, bei denen die Regeln wichtiger sind als die Freiheit der Formeln.
| Kriterium | Gemeinsame Tabelle | Interne App |
|---|---|---|
| Berechtigungen | Die ganze Datei teilen, mit Lese- oder Schreibzugriff | Rollen pro Ansicht und pro Datensatz, etwa „Mitarbeitende sehen nur ihre eigenen Anträge“ |
| Validierung | Optionale Regeln, die sich durch Einfügen umgehen lassen | Pflichtfelder und feste Auswahllisten, bei jedem Speichern durchgesetzt |
| Nachvollziehbarkeit | Versionsverlauf auf Dateiebene; einzelne Werte sind schwer zurückzuverfolgen | Ein Änderungsprotokoll pro Datensatz: wer, was, alter und neuer Wert, wann |
| Gleichzeitige Bearbeitung | Die letzte Änderung gewinnt; Zählerstände driften ab | Bestände und Zähler ändern sich in einem abgesicherten Schritt, und widersprüchliche Änderungen können abgewiesen statt still überschrieben werden |
| Benachrichtigungen | Manuelle E-Mails oder Skripte | E-Mails bei Ereignissen, dazu geplante Übersichten alle 30 bis 60 Minuten |
| Grenzen | Flexible Formeln und spontane Auswertungen | Exakte Filter statt Volltextsuche in großen Tabellen; Kapazität je nach Tarif |
Den Ablauf skizzieren: Datensätze, Status, wer was darf
Bevor Sie einen Prompt schreiben, übersetzen Sie die Tabelle in fünf Begriffe:
- Datensatz
- Eine Sache, die Sie erfassen: ein Artikel, ein Antrag, ein Kunde. Meist ein Tabellenblatt oder eine Art von Zeile.
- Feld
- Eine Spalte mit einem Typ: Text, Zahl, Datum, eine feste Auswahlliste, eine Datei oder ein Verweis auf einen anderen Datensatz.
- Status
- Wo ein Datensatz in seinem Lebenslauf steht, dazu die erlaubten Wechsel zwischen den Status.
- Rolle
- Eine Gruppe von Personen mit denselben Rechten, etwa Mitarbeitende, Führungskraft oder Buchhaltung.
- Ansicht
- Eine gefilterte Liste, die jemand täglich öffnet, etwa „meine offenen Anträge“ oder „unter Meldebestand“.
Nehmen Sie eine Tabelle für Bestellanforderungen als Beispiel. Antragsteller legen eine Anforderung an und reichen sie ein. Eine Führungskraft genehmigt oder lehnt sie ab. Die Buchhaltung markiert genehmigte Anforderungen als bestellt und später als eingegangen. Antragsteller sehen nur ihre eigenen Anforderungen, die Buchhaltung sieht alles. Schreiben Sie das in fünf Zeilen auf, und Sie haben das Gerüst der App.
Eine Designentscheidung zahlt sich später aus: Machen Sie aus Freitextspalten, wo immer es geht, feste Auswahllisten. Abteilung, Kategorie, Standort und Status sollten Listen sein, keine Tipparbeit. Die App filtert nach exakten Werten, und feste Optionen machen jeden Filter und jede Summe korrekt.
Bauen: Prompt-Vorlagen für drei typische Tools
- Skizzieren Sie den Ablauf wie oben beschrieben, auf einer Seite.
- Exportieren Sie eine saubere CSV- oder XLSX-Datei der aktuellen Daten, vorbereitet wie unten unter „Bestehende Daten übernehmen“ beschrieben.
- Fügen Sie eine Vorlage in einen neuen WisyLink-Chat ein, hängen Sie die Datei an und sagen Sie ausdrücklich, dass die Zeilen geladen werden sollen.
- Lesen Sie die Abschlussnotiz des Builds. Sie erklärt, wie Sie in den Admin-Bereich kommen, oft indem Sie sich als Erste oder Erster registrieren, und welche Integrationen, etwa E-Mail (SMTP), noch auf Zugangsdaten warten.
- Testen Sie jede Rolle. Legen Sie pro Rolle ein Testkonto an, probieren Sie jeden Statuswechsel und danach alles, was verboten sein sollte.
- Legen Sie einen Stichtag für die Umstellung fest. Setzen Sie die Tabelle auf schreibgeschützt, laden Sie die letzten Zeilen und verkünden Sie den Link. Beides parallel zu betreiben führt zu doppelter Erfassung.
- Verbessern Sie die App im selben Chat, jeweils mit einer gesammelten Änderungsliste.
Lagerverwaltung
Erstelle eine private Lagerverwaltung für [unsere zwei Lagerräume]. Datensätze: Artikel (Artikelnummer, Name, Kategorie, Lagerort, Menge, Meldebestand, Lieferant) und Lagerbewegungen (Artikel, Änderung, Grund: Wareneingang, Verkauf, Beschädigung oder Korrektur, wer, wann). Die Menge ändert sich nur über eine Lagerbewegung, angewendet in einem Schritt, damit zwei Personen nie doppelt zählen. Ansichten: Artikel gefiltert nach Lagerort und Kategorie sowie eine Liste „unter Meldebestand“. Rollen: Mitarbeitende erfassen Bewegungen, Führungskräfte bearbeiten Artikel und Meldebestände. Sobald ich die E-Mail-Einstellungen hinterlegt habe, schicke den Führungskräften jeden Morgen eine E-Mail mit den Artikeln unter Meldebestand. Lade die angehängte Datei inventar.csv als Artikel.
Genehmigungen
Erstelle ein Tool für Bestellanforderungen für [ein Unternehmen mit 30 Mitarbeitenden]. Status: Entwurf, eingereicht, genehmigt, abgelehnt, bestellt, eingegangen. Antragsteller legen ihre eigenen Anforderungen an, reichen sie ein und sehen nur diese. Führungskräfte genehmigen oder lehnen Anforderungen bis [2.000 €] ab; alles darüber geht an die kaufmännische Leitung. Die Buchhaltung markiert Anforderungen als bestellt und eingegangen. Jeder Statuswechsel hält fest, wer ihn wann vorgenommen hat, und benachrichtigt den Antragsteller per E-Mail, sobald ich die E-Mail-Einstellungen hinterlegt habe. Nur E-Mail-Adressen unter [unserefirma.de] können sich registrieren, und neue Konten warten auf die Freigabe durch einen Admin.
Schlankes CRM
Erstelle ein einfaches CRM für [unser Vertriebsteam mit vier Personen]. Datensätze: Firmen, Kontakte und Deals (Phase: Lead, kontaktiert, Angebot, gewonnen oder verloren; Wert; verantwortliche Person; nächster Schritt; Datum des nächsten Schritts). Alle sehen alle Firmen, aber jede Person bearbeitet nur ihre eigenen Deals. Ansichten: meine Deals nach Phase, Deals, deren Datum für den nächsten Schritt überschritten ist, und Pipeline-Summen nach Phase. Führe ein Änderungsprotokoll für Deals. Lade die angehängte Datei kontakte.xlsx als Firmen und Kontakte.
Im kostenlosen Community-Tarif ist der erste Build eine schlanke Version des Kernablaufs; Änderungsprotokoll oder E-Mail-Schritt können also noch fehlen. Fordern Sie sie in Ihrer nächsten Nachricht an. Weitere Muster finden Sie in unserem Leitfaden mit Prompt-Vorlagen.
Logins, Rollen und ein Änderungsprotokoll
Die App betreibt ihre eigenen Konten: Registrierung und Login mit gehashten Passwörtern, Sitzungen, Rollen und einen Admin-Bereich. Nichts davon wird mit anderen Apps geteilt, Ihr Team bekommt also einen Login mehr. So halten Sie das übersichtlich:
- Registrierung einschränken: nur Adressen Ihrer Firmendomain, und neue Konten warten, bis ein Admin sie freigibt und ihnen eine Rolle zuweist.
- Anmeldung mit Google anbieten, mit Ihren eigenen Google-OAuth-Zugangsdaten, eingetragen unter Integrationen. Ein Enterprise-Single-Sign-on (SAML) gibt es nicht.
- Offboarding mit einem Klick: Lassen Sie sich eine Schaltfläche „Deaktivieren“ einbauen, die den Zugang einer Person beendet, ohne ihren Verlauf zu löschen.
- Ein Website-Passwort ergänzen, wenn sogar die Login-Seite privat bleiben soll. Ein gemeinsames Passwort schützt dann jede Seite, sobald Sie es unter Integrationen festlegen; bis dahin bleibt die Website offen.
Das Änderungsprotokoll ist die Funktion, die Tabellen nie wirklich hatten. Lassen Sie bei jeder Änderung einen Eintrag anlegen: wer, welcher Datensatz, welches Feld, alter Wert, neuer Wert und wann, angezeigt bei jedem Datensatz und als Verlauf für Admins. Das Protokoll zählt gegen Ihre Datenbankkapazität; bei viel genutzten Tools lassen Sie daher einen geplanten Job Einträge löschen, die älter als ein von Ihnen gewählter Zeitraum sind. Zum Zurücksetzen von Passwörtern brauchen Sie Ihre SMTP-Einstellungen.
Bestehende Daten übernehmen
Hängen Sie Ihre Tabelle als CSV- oder XLSX-Datei mit bis zu 25 MB an und sagen Sie klar, dass die Datensätze beim Build geladen werden sollen. Der Builder ändert Live-Daten nur, wenn Sie das ausdrücklich verlangen. Bereiten Sie die Datei vorher vor:
- Eine Kopfzeile, ein Datensatz pro Zeile, keine verbundenen Zellen, keine Summenzeilen.
- Werte statt Formeln: Fügen Sie vor dem Export in einer Kopie nur die Werte ein.
- Durchgehend ein Datumsformat, am besten Jahr-Monat-Tag.
- Status und Kategorien einheitlich geschrieben. Bereinigen Sie „Erledigt“ und „erledigt “ jetzt.
- Ein Wert pro Zelle: Teilen Sie „rot, blau“ in getrennte Zeilen oder eine verknüpfte Liste auf.
Laden Sie zuerst etwa 20 Zeilen, prüfen Sie sie in der App und laden Sie dann den Rest. Importieren Sie regelmäßig, etwa die wöchentliche Preisliste eines Lieferanten, lassen Sie sich im Admin-Bereich eine Importseite für CSV-Dateien einrichten und testen Sie sie mit einer kleinen Datei. Rutschen Duplikate durch, bitten Sie im Chat darum, exakt doppelte Datensätze zu finden und zu entfernen; der Builder sieht sich die Live-Daten an, bevor er etwas löscht.
Andere Tools über ihre APIs anbinden
Ein internes Tool zahlt sich aus, wenn es keine Insel mehr ist. Jeder Dienst mit einer API lässt sich anbinden: Ihr Team-Chat, die Buchhaltungssoftware, ein CRM, ein Versanddienstleister. Jede Anbindung wird nach der aktuellen Dokumentation des Anbieters gebaut, und Sie tragen die Zugangsdaten einmal unter Integrationen ein, nie im Chat. Bis dahin bleibt diese Funktion inaktiv, und alles andere funktioniert.
Überlegen Sie, in welche Richtung die Daten fließen:
- Senden: Die App ruft ein anderes Tool auf, wenn etwas passiert, und postet etwa in einen Team-Kanal, sobald ein Antrag genehmigt ist.
- Abrufen: Ein geplanter Job holt alle 30 bis 60 Minuten Daten ab, etwa die Lagerbestände eines Lieferanten.
- Empfangen: Ein anderes Tool ruft die Webhook-Adresse Ihrer App auf, wenn auf seiner Seite etwas passiert.
Geben Sie der App einen eigenen API-Schlüssel mit den engsten Rechten, die der Anbieter erlaubt; so können Sie ihn widerrufen, ohne etwas anderes lahmzulegen. Schwanken Sie noch zwischen diesem Weg und einer Low-Code-Plattform, zeigt unser Vergleich No-Code, Low-Code und KI-App-Builder die Vor- und Nachteile.
Tagesübersichten und Aufräumen mit geplanten Jobs
Geplante Jobs übernehmen Arbeit, die niemand von Hand erledigen sollte: morgens eine Liste überfälliger Anträge, wöchentlich eine Pipeline-Übersicht, Anträge schließen, die 60 Tage lang unberührt blieben, abgelaufene Datensätze bereinigen. Sie laufen in einem festen Intervall von 30 bis 60 Minuten, das beim Build festgelegt wird, und versenden E-Mails über Ihr SMTP-Konto.
Einen Auslöser zu einer festen Uhrzeit gibt es nicht. Eine Übersicht „täglich um 8:00 Uhr“ funktioniert so, dass der Job bei jedem Lauf prüft und einmal sendet, sobald 8:00 Uhr vorbei ist; sie kommt also innerhalb von etwa einer Stunde nach dieser Zeit an. Zeitpläne haben keine eigene Zeitzone. Nennen Sie die Uhrzeit im Prompt daher in UTC oder geben Sie Ihre Abweichung an, in Deutschland also UTC+1 und im Sommer UTC+2. Jeder Lauf verarbeitet außerdem nur eine kleine Menge, eine große Bereinigung verteilt sich also auf mehrere Läufe. Alles Dringende, etwa eine Genehmigungsanfrage, sollte in dem Moment verschickt werden, in dem sich der Datensatz ändert, nicht per Zeitplan.
Grenzen, die Sie vorher kennen sollten
Interne Tools werden unbemerkt geschäftskritisch. Prüfen Sie deshalb diese Punkte, bevor Ihr Team von einem abhängt:
- Kapazität: Daten, Dateien und Bandbreite sind je Tarif begrenzt, und die Grenzen werden live durchgesetzt. Der Bereich „Ressourcen“ zeigt, wie stark jedes Kontingent ausgelastet ist.
- Suche: Eine Volltextsuche über große Tabellen gibt es nicht. Filter treffen exakte Werte, Bereiche und Auswahllisten. Eine Liste mit etwa 100 Zeilen lässt sich im Browser durchsuchen; darüber hinaus planen Sie Felder mit festen Optionen.
- Dashboards: Zählabfragen sind pro App begrenzt. Beschränken Sie ein Dashboard daher auf eine Handvoll Summen statt Dutzender Live-Kacheln.
- Rechenintensive Aufgaben: Anfragen sind kurzlebig; lang laufende Berichte und Massendatenverarbeitung passen nicht.
- Logins: kein SSO oder SAML; die App hat eigene Konten.
- Lebensdauer: Kostenlose Links werden nach 30 Tagen plus einer Woche mit Löschmarkierung gelöscht. Ein Tool, auf das Ihr Team angewiesen ist, gehört in einen kostenpflichtigen Tarif, ab 7 $ im Monat.
- Übertragbarkeit: Einen Code-Export gibt es nicht. Lassen Sie sich CSV-Exporte für jede Art von Datensatz einrichten und laden Sie sie in einem Rhythmus herunter, den Sie selbst bestimmen.
Und testen Sie Berechtigungen so, wie es ein Prüfer täte: Melden Sie sich in jeder Rolle an und versuchen Sie, Datensätze zu öffnen, die Sie nicht sehen dürften. Sie sind dafür verantwortlich, zu prüfen, was die KI baut. Brauchen auch Kunden statt nur Kollegen Zugang, lesen Sie, wie Sie ein Kundenportal ohne Code erstellen; für den Überblick beginnen Sie mit Was ist ein KI-App-Builder?
Ersetzen Sie Ihre erste Tabelle
Nehmen Sie die Tabelle, die die meisten Rückfragen auslöst, skizzieren Sie ihre Datensätze, Status und Rollen auf einer Seite und fügen Sie die passende Vorlage ein. Die Produktseite erklärt, wie jede App von allen anderen isoliert ist, und die Tarife zeigen, wie Kapazität und Build-Tempo mit jeder Stufe wachsen.
Beschreiben Sie Ihr Tool in einer Nachricht und erhalten Sie einen Live-Link: kostenlos mit Community starten, ohne Kreditkarte.
F.A.Q.
