Kein eigener Plattformbetrieb
Betrieb und Updates der Plattform liegen bei uns. Ihr konzentriert euch auf die Prozesse eurer Kunden.
AdminsBuddy · Für Systemhäuser und IT-Dienstleister
Eure Kunden automatisieren. Wir betreiben die Plattform.
Ihr kennt die IT eurer Unternehmenskunden und ihre wiederkehrenden Aufgaben. AdminsBuddy macht daraus kontrollierte Services mit Rechten, Freigaben und Protokoll. Die Plattform betreiben wir, ausgeführt wird über einen POD im Netz des Kunden.
Eigene Instanz je Kunde
Ausführung im Kundennetz
Betrieb durch uns
Ablauf
So läuft eine Partnerschaft
-
Schritt 01
Kunden und Prozess auswählen
Gemeinsam wählen wir bei einem eurer Kunden einen wiederkehrenden IT-Prozess aus, zum Beispiel ein gesperrtes Konto entsperren, einen Teil des Onboardings oder eine Serverdiagnose.
-
Schritt 02
Erstgespräch und Proof of Value
Nach einem kurzen Erstgespräch folgt ein begrenzter Proof of Value beim Kunden: POD einrichten, Prozess als Service bereitstellen, Ergebnis im Bericht festhalten.
-
Schritt 03
Betriebsmodell wählen
Dedicated Cloud, betrieben von uns, oder Self-Hosted beim Kunden. Der POD läuft in beiden Fällen im Netz des Kunden.
-
Schritt 04
Ausbauen
Läuft der erste Prozess stabil, kommen weitere Automationen und Teams dazu. Wer was übernimmt, legen wir je Partnerschaft fest.
Nutzen
Was ihr davon habt
Vorhandene Skripte bleiben die Grundlage
Was beim Kunden schon als PowerShell läuft, wird zum Service mit Eingabeformular und Protokoll. Ein Neuschreiben ist nicht nötig. Wie das geht
Kontrolle für den Kunden
Rechte, Freigaben und Protokoll bleiben beim Kunden. Der Service Desk führt Aufgaben aus, ohne selbst Adminrechte zu brauchen.
Ehrlicher Einstieg
Wir starten mit einem Prozess und einem messbaren Ergebnis, nicht mit einem großen Versprechen. Das schafft Vertrauen beim Kunden.
Funktionen
Was die Plattform beim Kunden mitbringt
Katalog mit Eingabeformularen
Jede Automation erscheint als Service mit geprüften Eingaben. Wiederkehrende Aufgaben werden für berechtigte Personen startbar.
Rechte und Freigaben
Wer einen Service sehen und starten darf, regeln Gruppen. Kritische Schritte können eine Freigabe verlangen.
POD im Kundennetz
Die Ausführung bleibt beim Kunden. Der POD verbindet sich selbst nach außen, offene Ports sind nicht nötig.
Datasets für Zugangsdaten
Zugangsdaten und Konfigurationswerte liegen je Kunde getrennt und werden zur Laufzeit gelesen, nicht im Skript gespeichert.
Zeitpläne und REST-API
Regelmäßige Prüfungen und Berichte laufen nach Plan. Über die REST-API können Ticket- und Fremdsysteme Jobs anstoßen.
Agentic Control
Die KI arbeitet Schritt für Schritt und schlägt jeden Schritt vor, Policies entscheiden, was ausgeführt wird. Nur für begleitete, klar abgegrenzte Fälle. Mehr dazu
Transparenz
Ehrlich zum Stand
Wir versprechen nur, was heute geliefert werden kann. Darum steht hier auch, was es noch nicht gibt.
Partnermodell im Aufbau
Wir suchen wenige erste Partner und legen die Rollen gemeinsam fest.
Kein Sammelportal für viele Endkunden
Jeder Kunde hat seine eigene Instanz. Ein zentrales MSP-Cockpit über alle Kunden gibt es nicht.
Agentic Control ist Early Access
KI-gestützte Abläufe setzen wir nur begleitet und für abgegrenzte Fälle ein.
Häufige Fragen
Fragen von Systemhäusern und IT-Dienstleistern
Können wir AdminsBuddy als MSP für viele Kunden selbst betreiben?
Heute nicht als fertiges Angebot. Jeder Kunde bekommt seine eigene Instanz, als Dedicated Cloud bei uns oder Self-Hosted beim Kunden. Ein Modell, in dem Systemhäuser die Plattform für viele Endkunden selbst betreiben, ist nicht Teil des heutigen Angebots.
Welche Rolle übernehmen wir als Partner?
Ihr bringt den Zugang zum Kunden und das Wissen über seine Prozesse ein und könnt die Einführung beim Kunden begleiten. Betrieb und Updates der Plattform liegen bei uns. Die genaue Aufteilung legen wir je Partnerschaft gemeinsam fest.
Können wir Automationen für mehrere Kunden wiederverwenden?
Ja, als Vorlage. Resources aus der Library lassen sich in den Katalog eines Kunden übernehmen und dort anpassen. Zugangsdaten, Logs und Kundendaten bleiben je Kunde getrennt.
Braucht der POD beim Kunden eine feste IP oder offene Ports?
Nein. Der POD im Kundennetz baut die Verbindung zur Plattform selbst auf (ausgehend). Eingehende Verbindungen oder Portfreigaben in der Firewall des Kunden sind nicht nötig.
Wie wird der POD beim Kunden eingerichtet?
Die Plattform erzeugt ein Startskript für den jeweiligen Kunden. Es wird einmal auf einem Windows Server mit PowerShell 5.1 im Kundennetz ausgeführt und richtet den POD ein, einschließlich Heartbeat und Abgleich der freigegebenen Skripte.
Partnerschaft
Erste Partner gesucht
Wir arbeiten mit wenigen Systemhäusern zusammen, die Unternehmenskunden mit Microsoft- und Windows-IT betreuen. Lasst uns an einem konkreten Kundenprozess prüfen, ob das passt.
Weiterlesen