Als bevorzugte Quelle bei Google hinzufügen
Du bist bereit, ein Update für eine WooCommerce-Erweiterung zu testen. Die KI hilft dir dabei, die Release-Notes durchzugehen, und du hast einen Entwurf für einen Testplan geöffnet. Dann fragt ein Kollege, ob das Update irgendwelche benutzerdefinierten Checkout-Regeln betrifft. Du weißt, dass einige Kunden-Shops solche Regeln haben. Aber welche genau?
Du fragst in Slack nach. Der Entwickler, der diese Shops kennt, ist bis zum Mittagessen in Besprechungen, also nimmst du dir in der Zwischenzeit ein anderes Ticket vor.
Eine andere Agentur nutzt dasselbe KI-Tool, aber ihr Entwickler kann die Ausnahmen beim Bezahlvorgang in den Notizen der einzelnen Shops finden. Es gibt eine Testbestellung zum Ausprobieren, neben der der erwartete Rabatt vermerkt ist. So können sie gleich mit der Überprüfung loslegen.
Da die KI die Zeit verkürzt, die du für die Vorbereitung von Änderungen aufwendest, haben diese alltäglichen Details einen größeren Einfluss darauf, wie viel Arbeit du erledigen kannst. Wir schauen uns an, wie du das Standortwissen deines Teams besser nutzbar machen kannst und wie du Entwicklern die notwendigen Informationen gibst, um KI-Vorschläge zu bewerten. Außerdem besprechen wir, wie du feststellen kannst, ob diese Verbesserungen in deinem gesamten Kundenportfolio Zeit einsparen.
Wo sich die Arbeit stapelt
Mit Hilfe der KI fertigst du einen Patch in zwanzig Minuten an und gibst ihn zur Überprüfung weiter. Dein technischer Leiter muss prüfen, ob dieselbe Anpassung auch auf der Website eines anderen Kunden funktioniert, kommt aber erst am Donnerstag dazu. Du arbeitest weiter. Bis er das erste Ticket eröffnet, warten bereits vier weitere Patches auf ihn.
Du erkennst das Problem an den Zeitstempeln der Tickets. Das Schreiben dauert Minuten, das Warten Tage. Ein weiteres KI-Abonnement ändert nichts an dieser Verzögerung.
In der Atlassian-Studie zur Entwicklererfahrung 2025 geben 50 % der Entwickler an, mindestens zehn Stunden pro Woche mit Nicht-Programmier-Arbeit zu verlieren, was größtenteils auf organisatorische Ineffizienzen zurückzuführen ist. Die Umfrage umfasst 3.500 Entwickler und Manager in sechs Ländern. Das Suchen nach Informationen zählt zu den Hauptursachen für Zeitverschwendung. Es handelt sich hierbei um berichtete Erfahrungen und nicht um gemessene Zeitaufzeichnungen, aber sie bieten Agenturen einen nützlichen Ansatzpunkt für weitere Untersuchungen.
Vielleicht verbringt jemand aus deinem Team einen Teil jedes Reviews damit, Repository-Links auszugraben oder Kollegen daran zu erinnern, auf welchen Seiten eine Anpassung genutzt wird. Selbst jemand, der bereit ist, sofort einen Test durchzuführen, muss möglicherweise warten, bis der Zugang gewährt wird.
Das lässt sich verhindern, indem man diese Details in den Website-Unterlagen festhält und sicherstellt, dass die dafür zuständigen Entwickler den nötigen Zugriff haben. Ein Kollege sollte in der Lage sein, die vorhandenen Testanweisungen zu finden und loszulegen. Der Projektleiter kann immer noch eingreifen, wenn sich eine Änderung unerwartet verhält, ohne jedes Mal die Frage „Wo ist der Code?“ beantworten zu müssen.
Das Standortwissen, das dein Team pflegt, wird wertvoller
Der Endpunkt für die individuelle Preisberechnung eines Großhandelsunternehmens braucht mehrere Sekunden, um zu antworten. Auf die Frage, wie man das beschleunigen könnte, schlägt ein KI-Assistent vor, die Antwort zehn Minuten lang zwischenzuspeichern. Das würde der Website ersparen, bei jeder Anfrage einen Preis neu zu berechnen.
Jeder Kunde hat jedoch einen ausgehandelten Preis. Wird eine gespeicherte Antwort an das falsche Konto gesendet, kann ein Einkäufer die Preise eines anderen Unternehmens einsehen. Der Entwickler, der den Endpunkt programmiert hat, weiß, warum dieser den gemeinsamen Cache umgeht. Jemand, der sechs Monate später ein Performance-Ticket übernimmt, sieht vielleicht eine Möglichkeit, die Website schneller zu machen, ohne zu erkennen, welche Risiken diese Änderung mit sich bringt.
Der Kommentar neben dem Endpunkt kann natürlich ganz einfach gehalten sein. Etwas wie: „Jedes Großhandelskonto hat seinen eigenen ausgehandelten Preis. Diese Antwort darf nicht in den gemeinsamen Cache gelangen“, würde gut funktionieren.
Verweise deine Kollegen im Website-Eintrag auf den Code und gib zwei Testkonten mit unterschiedlichen Preisen an. Nach einer Änderung können sie sich mit jedem Konto anmelden und den angezeigten Preis mit dem Tarif vergleichen, den der Käufer eigentlich erhalten sollte.
Das gibt deinem Kollegen einen Grund, eine vorgeschlagene WordPress-Caching-Änderung zu hinterfragen. Außerdem liefert es einem KI-Assistenten nützlicheren Kontext, wenn du ihn bittest, Alternativen zu prüfen.
Überleg dir, was du erwähnen würdest, wenn du eine Website an einen Kollegen übergibst:
- „Die Einkaufsabteilung nutzt diesen Bericht bei der Besprechung am Montag. Er muss bis dahin fertig sein.“
- „Die Datumsangaben im Import basieren auf der Zeitzone des Lieferanten.“
- „Wir warten noch auf die Behebung dieses Plugin-Problems, bevor wir die Notlösung entfernen.“ Füge den Link zum Problem hinzu.
Wenn ein Plugin-Update das Problem behebt, solltest du das notieren und das Datum hinzufügen. Die alten Anweisungen können bestehen bleiben, und eine KI-Zusammenfassung könnte weiterhin eine Umgehungslösung empfehlen, die deine Website gar nicht mehr benötigt.
Verwende das von deiner Agentur genehmigte KI-Tool und entferne alle Anmeldedaten aus allem, was du dort einfügst. Kundendaten können in der Regel ebenfalls weggelassen werden; füge sie nur hinzu, wenn die Frage dies erfordert. Füge neben der Antwort einen Link zum entsprechenden Code oder zu den Einstellungen hinzu, damit der nächste Entwickler überprüfen kann, ob alles mit dem auf der Website übereinstimmt.
Gute Diagnosen helfen Entwicklern, KI-Vorschläge schneller zu bewerten
„Der Bezahlvorgang fühlt sich manchmal langsam an“ lässt viel Raum für Spekulationen. Ein KI-Assistent kann sofort eine plausible Liste von Ursachen erstellen. Mit hilfreichen Diagnosedaten kannst du anfangen, diese auszuschließen.
Kleine Bestellungen laufen reibungslos ab. Legst du jedoch zwölf verschiedene Produkte in den Warenkorb, dauert die Neuberechnung des Gesamtbetrags sechs Sekunden. Ein Trace zur Überwachung der Anwendungsleistung weist auf die benutzerdefinierte Rabattfunktion hin. Für jede Zeile im Warenkorb greift sie erneut auf die Datenbank zu und ruft die Bestellhistorie desselben Käufers ab.
Jetzt hast du eine konkrete Frage: Kann die Funktion diese Historie einmal abrufen und während derselben Berechnung wiederverwenden? Du kannst die KI bitten, den Code unter Berücksichtigung dieser Einschränkung zu überprüfen.
Nachdem du die Änderung in der Staging-Umgebung vorgenommen hast, wiederhole den Test mit den zwölf Produkten und überprüfe die Anzahl der Abfragen. Vergewissere dich, dass der Rabatt korrekt bleibt, wenn du die Mengen änderst. Eine kürzere Antwortzeit bedeutet wenig, wenn der Kunde den falschen Gesamtbetrag erhält.
Wenn am nächsten Morgen jemand anderes aus dem Team die Untersuchung des Checkouts übernimmt, hat er zwar den Trace, aber würde er wissen, dass du den Test in der Staging-Umgebung mit einem Großhandelskundenkonto durchgeführt hast? Dieses Detail musst du im Ticket vermerken. Gib für die WordPress-Fehlerprotokolle das entsprechende Zeitfenster und die Zeitzone an, damit sie Einträge aus demselben Test finden können.
Das ist auch wichtig, wenn KI bei der Untersuchung hilft. Splunks „State of Observability 2025“ befragt 1.855 Observability-Experten, und 48 % nennen schlechte Datenqualität als ihr größtes Hindernis für die KI-Bereitschaft. Wenn du nicht angibst, welches Konto die Rabattregel auslöst, hat ein Assistent weniger Anhaltspunkte – egal, wie detailliert der Trace auch aussieht.
Außerdem verbessert es die Rückmeldung an deinen Kunden. Du kannst erklären, dass große Warenkörbe wiederholt denselben Bestellverlauf laden, und den Test beschreiben, mit dem du deine Korrektur überprüfst. Der Kunde erhält eine Erklärung für die Verzögerung, statt einer weiteren Nachricht, in der steht, dass du gerade ein paar Dinge ausprobierst.
Einheitliche Umgebungen machen Verbesserungen im gesamten Portfolio sinnvoll
Eine einzige Leistungsoptimierung kann auf mehreren Websites Arbeit sparen, vorausgesetzt, du weißt, wo du noch nachsehen musst.
Angenommen, ein Berichts-Plugin berechnet alle fünfzehn Minuten die Bestellsummen eines ganzen Jahres neu. Der Kunde öffnet diesen Bericht jedoch nur für ein wöchentliches Meeting. Du stellst fest, dass die wiederholten Neuberechnungen Datenbankzeit beanspruchen, und passt den Zeitplan an die Art und Weise an, wie der Kunde den Bericht nutzt.
Deine Agentur installiert dasselbe Plugin auf elf weiteren Shops. Mit einem aktuellen Bestandsverzeichnis kannst du diese identifizieren und ihre Einstellungen überprüfen. Ohne ein solches muss jemand die Dashboards einzeln öffnen oder Rechnungen nach dem Namen des Plugins durchsuchen.
„Wo speichert diese Seite ihren benutzerdefinierten Code?“ – diese Frage wird schnell langweilig, wenn du mehrere WordPress-Seiten verwaltest. Bekannte Dateipfade ersparen einem Kollegen das Suchen, ebenso wie Einträge, die für dieselbe Einstellung denselben Namen verwenden. Notizen zum Zeitplan können Fragen klären, die die Plugin-Einstellungen nicht beantworten, zum Beispiel, ob der Server WordPress-Cron-Jobs auslöst.
„Die Mitarbeiter überprüfen diesen Bericht den ganzen Tag über“ gehört neben die Aktualisierungseinstellung in den Website-Notizen. Würde man den Wochenplan eines anderen Shops kopieren, würde man mit veralteten Zahlen arbeiten. Füge in diesen Eintrag auch die installierte Plugin-Version ein. Ein Entwickler kann Zeit damit verschwenden, nach einer Planungsfunktion zu suchen, die zwar in einer neueren Version vorhanden ist, aber nirgendwo in den Einstellungen dieses Shops auftaucht.
KI kann dabei helfen, exportierte Einstellungen zu vergleichen oder eine Liste mit möglichen Übereinstimmungen zu erstellen. Vergleiche diese Liste mit den tatsächlichen Websites, bevor du die Änderung vornimmst. Übereinstimmende Plugin-Namen allein beweisen noch nicht, dass Kunden die Funktion auf die gleiche Weise nutzen.
Füge den Einrichtungshinweisen des Plugins die Frage „Wie oft nutzt der Kunde diesen Bericht?“ hinzu. Der Entwickler, der es im nächsten Shop installiert, kann den Zeitplan bereits während der Einarbeitung festlegen. Ein Bericht, den der Kunde montagmorgens öffnet, muss kaum die ganze Woche über alle fünfzehn Minuten neu generiert werden. Dein Team hat dieses Problem bereits einmal untersucht; die nächste Installation profitiert von der Antwort.
Beziehe KI in die Überprüfungen ein, die du ohnehin schon durchführst
Die Plugin-Überprüfung am Dienstag kann viel Zeit bedeuten, in der man die Changelogs offen hat. Für jede Website muss jemand die installierte Version mit der neuen Version vergleichen und herausfinden, welche Änderungen eine genauere Betrachtung verdienen. Zum Beispiel muss bei einem Shop mit einer benutzerdefinierten Rabattregel besonders auf alles geachtet werden, was die Preisberechnung an der Kasse verändert.
Das gibt einem KI-Assistenten eine konkrete Aufgabe. Anhand der installierten Version und einer Erklärung der Rabattregel kann er Änderungen herausfiltern, die sich auf die Berechnung auswirken könnten. Die Zusammenfassung muss Links zu den Release-Notes enthalten, damit dein Entwickler diese Einträge im Kontext lesen kann. Er entscheidet zwar immer noch, ob ein Update den Shop betrifft, muss aber zunächst weniger Material durchforsten.
„Überprüfe alle unsere Websites und sag uns, was Aufmerksamkeit erfordert“ gibt ihm viel weniger Arbeitsgrundlage. Es könnte einen beeindruckend aussehenden Bericht erstellen, der genau das eine Kompatibilitätsdetail auslässt, das dein Entwickler braucht.
Probier die enger gefasste Aufgabe an ein paar Websites aus, die du gut kennst. Vergleiche das Ergebnis mit deiner eigenen Überprüfung. Unterscheidet es zwischen einer vorgeschlagenen und einer bereits veröffentlichten Korrektur? Behandelt es eine fehlende Versionsnummer als unbekannt oder füllt es die Lücke mit einer Schätzung?
Das Skript vergleicht die installierte Plugin-Version jeder Website mit der verfügbaren Version. Außerdem markiert es fehlende Konfigurationsexporte.
Wenn eine Website ihre Konfiguration nicht zurückgibt, heißt es im Bericht: „Überprüfung unvollständig. Der Konfigurationsexport dieser Website fehlt.“ Durch diesen Eintrag bleibt die Website dann auf der To-do-Liste des Prüfers. Eine leere Zeile könnte leicht so aussehen, als hätte die Website die Prüfung bestanden.
Messe den Kapazitätsgewinn
Ein Nachmittag ohne eine Flut von „Wo finde ich das?“-Nachrichten verschafft deinem technischen Leiter Zeit, um Kundenaufträge abzuschließen. Du kannst den Nutzen schon lange erkennen, bevor du einen weiteren Kunden an Land ziehst.
Deine Projekt- und Support-Tickets können zeigen, ob die Verzögerungen, die du zu verkürzen versuchst, tatsächlich abnehmen. Je nachdem, was die Arbeit immer wieder aufhält, könntest du Folgendes nachverfolgen:
- Wartezeit bis zur Freigabe: Wie lange liegt eine fertige Änderung herum, bevor jemand sie überprüfen und freigeben kann?
- Untersuchungszeit: Wie lange braucht der Entwickler, um die Ursache eines gemeldeten Problems zu ermitteln?
- Wiedereröffnete Tickets: Wie oft tritt dasselbe Problem erneut auf, nachdem das Team eine Behebung als abgeschlossen markiert hat?
- Ungeplante Supportstunden: Wie viel der geplanten Projektzeit fließt in unerwartete Reparaturen?
Nehmen wir zum Beispiel an, es gibt sechs vergleichbare Wartungstickets, bei denen der Projektleiter jeweils Konfigurationsdetails herausfinden muss. Nachdem du die Website-Dokumentation verbessert hast, schau dir die nächsten sechs eingehenden Tickets an. Wenn die Teammitglieder fünf davon ohne diese Unterbrechung bearbeiten können und die Korrekturen halten, hast du den Beweis, dass die Hinweise helfen.
Wenn jemand ein Ticket schließt und die verbleibenden Untersuchungen an einen Kollegen weitergibt, muss das Team dennoch Zeit für diese Reparatur aufwenden. Entwickler neigen zudem dazu, Supportstunden zu niedrig anzugeben, wenn sie fünfminütige Unterbrechungen in ihren Stundenzetteln nicht eintragen. Diese Unterbrechungen unterbrechen ihren Arbeitstag dennoch, egal ob sie sie protokollieren oder nicht.
Mehrere Wochen mit vergleichbaren Tickets bieten dir eine bessere Grundlage, um zu beurteilen, ob sich etwas verbessert. Das Ticketvolumen spielt hier eine Rolle. Eine ruhige Woche lässt natürlich mehr Raum für Projektarbeit, unabhängig von Änderungen an eurer Dokumentation oder euren KI-Tools.
Deinem Teamleiter stehen nun zwei Nachmittage für Kundenprojekte zur Verfügung. Eine arbeitsreiche Supportwoche zeigt dir, ob du auf diese Zeit zählen kannst. Wenn er die geplante Arbeit erledigt, ohne die Hälfte davon in die nächste Woche zu verschieben, hast du eine solidere Grundlage, um einem weiteren Kunden zuzusagen.
Eine Hosting-Umgebung, die dein Team kennt
„Überprüfe die Logs“ setzt voraus, dass dein Kollege weiß, wo er sie findet. Wenn jeder Kunde einen anderen Host nutzt, verbringt er möglicherweise den ersten Teil eines Support-Tickets damit, ein unbekanntes Dashboard zu durchsuchen. Eine vertraute Umgebung ermöglicht es ihm, direkt mit der Untersuchung loszulegen.
Kinsta bündelt diese Aufgaben in MyKinsta. Wenn ein Shop langsamer wird, kann ein Entwickler Kinsta APM für einen Untersuchungszeitraum aktivieren und Transaktionen im Zusammenhang mit PHP, Datenbankabfragen und externen Anfragen überprüfen. Außerdem kann er die verfügbaren Logs der Website direkt über das Dashboard einsehen.
Der Entwickler kann diesen langsamen Warenkorb mit 12 Produkten auf einer WordPress-Staging-Seite mithilfe eines Großhandels-Testkontos nachbilden. Er weiß, wie hoch der Rabatt sein sollte, und kann so die überarbeitete Berechnung überprüfen, ohne Live-Bestellungen zu beeinflussen. Der Geschwindigkeitsvergleich erfordert etwas mehr Sorgfalt. Wenn die Staging-Umgebung andere Caching-Einstellungen verwendet oder über weniger Ressourcen verfügt als die Produktionsumgebung, liefern die Messwerte keinen verlässlichen Vergleich.
„Kannst du mir Zugriff geben?“ sollte nicht die erste Nachricht sein, die du erhältst, wenn ein Kollege den Support übernimmt. Mit der Benutzerverwaltung von MyKinsta kannst du ihm vorab Staging-Zugriff gewähren, während der Produktionszugriff demjenigen vorbehalten bleibt, der die Korrektur bereitstellt. Wenn dieser Kollege regelmäßig an verschiedenen Kunden-Websites arbeitet, kannst du ihm eine Rolle auf Unternehmensebene zuweisen, anstatt den Zugriff für jede Website separat einzurichten.
Wenn mehrere Shops deine Rabatt-Erweiterung nutzen, erleichtern Website-Labels das Auffinden dieser Installationen. Du kannst die Gruppe aufrufen, wenn ein Fix getestet werden muss, und dann im Projektdatensatz jedes Shops die jeweiligen Preisregeln nachschlagen. Das Label muss allerdings dem tatsächlichen Inhalt der Website entsprechen. Ein Geschäft, das die Erweiterung nicht mehr nutzt, sollte nicht mehr in dieser Liste erscheinen.
Wo du zuerst investieren solltest
„Warte immer noch auf Staging-Zugriff“ kann einen halben Tag lang in einem Ticket stehen, während eine Kassenkorrektur auf das Testen wartet. Wenn dieser Kommentar immer wieder in deinen aktuellen Tickets auftaucht, hast du ein konkretes Problem zu lösen. Die Entwickler, die für diese Shops zuständig sind, brauchen Zugänge, mit denen sie ihre Arbeit erledigen können, ohne darauf warten zu müssen, dass der Kontoinhaber wieder online ist.
Wenn jemand aus deinem Team sich selbst einloggt, erfährst du mehr als aus einer Liste der zugewiesenen Berechtigungen. Vielleicht gelangt die Person zwar ins Dashboard, hat aber dennoch keinen Zugriff auf die benötigte Umgebung. Wenn du das zwischen den Tickets herausfindest, hast du Zeit, das Problem zu lösen, ohne dass ein Kunde warten muss.
„Führe den üblichen Checkout-Test durch“ setzt voraus, dass dein Kollege den Shop genauso gut kennt wie die Person, die den Rabattcode verfasst hat. Er hat vielleicht keine Ahnung, welches Konto für Großhandelspreise berechtigt ist. Wenn du diese Kontoreferenz neben einem Link zur Rabattregel angibst, ersparst du ihm das Warten auf die Antwort des Autors.
„Ich bin angemeldet. Wie hoch sollte der Warenkorb-Gesamtbetrag sein?“ Ein solcher Kommentar im nächsten Ticket zeigt, wo Teammitglieder noch Hilfe brauchen. Der erwartete Betrag sollte bei deiner Antwort neben der Kontoreferenz stehen. Sonst fragt dich vielleicht derjenige, der nächste Woche den Checkout bearbeitet, dasselbe. Schon wieder.
Mach die nächste Website einfacher zu betreuen
Zurück bei den beiden Agenturen haben beide Entwickler um zehn Uhr ihre KI-generierten Testentwürfe fertig. Das Team mit der dokumentierten Ausnahme beim Bezahlvorgang kann seinen Entwurf direkt nutzen. Das andere braucht noch eine Antwort von jemandem, der gerade in einer Besprechung ist.
Diese kleinen Vorteile werden umso wertvoller, je mehr die KI deinem Team hilft, mehr Arbeit vorzubereiten. So kannst du die zusätzlichen Ergebnisse nutzen, ohne jede Frage an dieselbe Person weiterleiten zu müssen.
Such dir eine wiederkehrende Verzögerung aus und beseitige sie. Gib dann dem nächsten Entwickler genügend Informationen, damit er von der Lösung profitieren kann. Das Managed-WordPress-Hosting von Kinsta bietet deinem Team eine vertraute Umgebung, um Änderungen zu untersuchen und zu testen, während dein Kundenportfolio wächst.
Carlo ist ein leidenschaftlicher Liebhaber von Webdesign und Frontend-Entwicklung. Er beschäftigt sich seit über 10 Jahren mit WordPress, auch in Zusammenarbeit mit italienischen und europäischen Universitäten und Bildungseinrichtungen. Er hat Dutzende von Artikeln und Leitfäden über WordPress geschrieben, die sowohl auf italienischen und internationalen Websites als auch in gedruckten Magazinen veröffentlicht wurden. Du kannst Carlo auf X und LinkedIn finden.
