Jeśli chcesz, żeby coś było zrobione dobrze, zrób to sam. Z AI.

Nasza strona ładuje się teraz w mniej niż sekundę. Błyskawicznie.

Na początku tego tygodnia, 21 października, uruchomiliśmy naszą całkowicie przebudowaną stronę. Ale wydajność nie była jedynym powodem tej przebudowy.

Jest kilka problemów, które rozpozna niemal każda mała firma i każdy zespół marketingowy.

Oczywiście chcesz opublikować treści jak najszybciej, wprowadzać zmiany po drodze i poprawiać to, co wygląda inaczej, niż sobie wyobrażasz. Twoje zmiany mogą jednak łatwo spaść na drugie lub trzecie miejsce na liście priorytetów. A nieoczekiwane zachowanie strony, złożoność techniczna czy potrzeba dodania kolejnych funkcji mogą opóźnić wdrożenie i zatrzymać Twoje pomysły w kolejce zadań.

Nasza stara strona była powolna, toporna i trudna w utrzymaniu. Z czasem nagromadziło się wiele usprawnień interfejsu oraz niespójnych komponentów. Tradycyjnie taka przebudowa odbywałaby się etapami: migracja istniejącej strony, ujednolicenie komponentów, a następnie wprowadzenie nowego projektu. Jednak mimo setek podstron postanowiliśmy zrobić wszystko za jednym razem.

Jak więc zostawiliśmy WordPressa i PHP za sobą i przeszliśmy na coś zgrabniejszego, szybszego i nowocześniejszego, z odrobiną klimatu pumpkin spice latte? Oto nasza droga do Next.js i Payload CMS, podczas której nasz projektant pracował nad nowym UI/UX, a Codex zajmował się generowaniem kodu, implementacją i wdrożeniem.

Problem nie dotyczył tylko strony

Przez mniej więcej rok tolerowałem problemy z naszą stroną — zarówno techniczne, jak i organizacyjne.

Większym problemem było jednak to, jak trudno było przekazywać naszą wiedzę i pomysły bezpośrednio potencjalnym klientom.

Jako właściciel i założyciel firmy regularnie rozmawiam z klientami, poznaję ich potrzeby i uczestniczę wraz z naszym zespołem inżynierskim w sesjach poświęconych architekturze rozwiązań technicznych.

Nasi inżynierowie pracują bezpośrednio z klientami. Wiedzą, z jakimi problemami się mierzą, co mogłoby usprawnić ich działalność, i często mają świetne pomysły, którymi warto się podzielić. To samo dotyczy naszego zespołu sprzedaży, który stale rozmawia z klientami i rozpoznaje ich problemy i potrzeby.

Pytanie brzmi: jak skrócić drogę między tymi pomysłami a klientem, zachowując pierwotną wizję i intencje autora?

Zrozumiałem, że AI może pomóc nam wyeliminować te zbędne etapy pośrednie.

A zmiany, które wcześniej zajmowały cały dzień, teraz mogą zająć zaledwie kilka minut.

Ten artykuł jest dobrym przykładem. Dyktuję swoje przemyślenia, które nie zawsze są szczególnie uporządkowane. Potem czytam wynik, sprawdzam go, przestawiam akapity, doprecyzowuję opisy problemów albo po prostu wydaję polecenie: „Pokaż te problemy jako osobne bloki na stronie”.

Właśnie takie doświadczenie chciałem stworzyć: stronę, na której osoby naprawdę znające temat mogą bezpośrednio przekazywać swoje pomysły, od razu je dopracowywać i publikować bez zbędnego przekazywania pracy kolejnym osobom.

AI powinno zbliżać osoby wykonujące pracę do klienta, a nie tworzyć między nimi kolejną warstwę.

Nudna część: naprawmy to, co już mamy

Prace nad przebudową strony rozpocząłem 1 października 2026 roku.

Pierwszy pomysł był prosty: uporządkować istniejącą stronę, zrefaktoryzować kod, usunąć zbędne duplikacje i poprawić wydajność.

Nie byłem jednak w stanie napisać tak dużej ilości kodu w krótkim czasie, więc postanowiłem skorzystać z Codex.

Przejrzałem kod PHP i zauważyłem, że niemal każdy szablon strony miał poważne problemy z powielaniem kodu.

Dzięki Codex mogłem wydzielić komponenty wielokrotnego użytku, wyeliminować powielanie kodu między stronami, zmniejszyć ilość kodu i poprawić wydajność.

Co ciekawe, prompty były całkiem proste.

Na przykład:

Weź tę sekcję, [podaj identyfikator sekcji z wyrenderowanej strony HTML], i zastąp ją, wydzielając komponent wielokrotnego użytku. Sprawdź wszystkie pozostałe strony witryny i zastąp na nich dotychczasową implementację nową. Następnie usuń cały stary i nieużywany kod oraz zweryfikuj swoją pracę.

W zasadzie tyle.

Po drodze znalazłem sporo innych problemów.

Na przykład niektóre ikony menu nawigacyjnego wyświetlane w rozmiarze 32 pikseli były w rzeczywistości plikami graficznymi ważącymi około jednego megabajta każdy.

Wyobraź sobie ładowanie obrazu o wielkości jednego megabajta tylko po to, żeby wyświetlić maleńką ikonę nawigacji.

Poprosiłem więc Codex:

Weź [obraz], przeanalizuj go, w razie potrzeby zwiększ rozdzielczość i przekonwertuj do formatu WebP. Zoptymalizuj go pod kątem szybkości ładowania strony, dopasuj do rzeczywistych wymiarów wyświetlania (na przykład 32 × 32 piksele) i maksymalnie zmniejsz rozmiar pliku bez pogarszania jakości obrazu.

Powtórzyliśmy to w całej witrynie, zastępując niepotrzebnie duże grafiki i porządkując kod.

I to zadziałało.

To robiło całkiem spore wrażenie.

Nad pierwszym etapem pracowałem od 1 do 10 października, poświęcając około czterech godzin w każdy dzień roboczy, z wyłączeniem weekendów.

W sumie było to około 28 godzin porządkowania kodu PHP i optymalizacji naszej istniejącej strony na WordPress.

W tym momencie myślałem, że zmiany techniczne są już zakończone.

Pozostało poczekać, aż nasz projektant ukończy nowe style, i mogliśmy ruszać dalej.

Zrobiłem więc przerwę od aktywnego programowania.

Ale sytuacja niespodziewanie się pogorszyła.

Incydent z 12 października: strona przestała działać

Między 10 a 12 października nie pracowałem aktywnie nad stroną, ale od czasu do czasu sprawdzałem wskaźniki naszego serwera.

Początkowo sądziłem, że mogły to spowodować moje ostatnie zmiany.

Zacząłem więc szukać przyczyny i skorzystałem też z ChatGPT, aby przeanalizować istniejącą stronę i konfigurację serwera.

Z ustaleń wynikało, że problem najwyraźniej nie był spowodowany moimi zmianami w kodzie.

Utrzymywaliśmy stronę na serwerze z 2 GB RAM i dwoma procesorami, co moim zdaniem powinno wystarczyć dla naszej witryny.

Nie twierdzę przy tym, że GTranslate jest złym produktem.

Problem prawdopodobnie wynikał z połączenia kilku czynników w naszej infrastrukturze. Wtyczka wymagała z naszej strony bieżącego utrzymania i dostosowywania konfiguracji, aby wszystko działało poprawnie.

Wiedziałem, że problem może powrócić. Mieliśmy też sporo wtyczek, których głównym zadaniem było uniknięcie pisania kodu dla stosunkowo prostych funkcji, takich jak formularze kontaktowe, tłumaczenia i kilka innych rozwiązań.

Wiele z tych wtyczek można było bez trudu usunąć lub zastąpić, najlepiej przenosząc ich funkcje bezpośrednio do nowego CMS.

Jeśli chcieliśmy samodzielnie utrzymywać i rozwijać naszą stronę, sensowne było odejście od PHP na rzecz czegoś, co każdy programista Salesforce zna na wylot: JavaScript.

Dlatego po stronie serwera wybraliśmy Node.js.

Przebudowa z Node.js, Next.js, React i Payload CMS

Tak więc 12 października zacząłem przebudowywać stronę.

Chciałem ograniczyć zależność od wtyczek i stworzyć spójną platformę z systemem zarządzania treścią, zintegrowanymi tłumaczeniami i strukturą, nad którą miałbym kontrolę.

Dobrze znam JavaScript i Node.js, a wcześniej zrealizowałem z ich użyciem kilka projektów.

Dlaczego Payload CMS?

Ponieważ opiera się na Next.js, a Next.js wydawał mi się całkiem dobrym wyborem.

Chciałem rozwiązania, które pozwoli mi pracować ze znanym stosem technologicznym, zamiast wprowadzać kolejny zestaw narzędzi i zależności.

Payload i Next.js zapewniły nam też rozsądną podstawę architektoniczną, więc nie musiałem wymyślać wszystkiego od zera.

Tak, kusiło mnie, żeby po prostu powiedzieć agentowi:

Przepisz całą stronę WordPress, używając wybranego przeze mnie stosu Node.js, Next.js, React i Payload CMS. Zrób to poprawnie, zrób to dobrze, wszystko zweryfikuj, użyj subagentów i nie zawracaj mi głowy.

Musiałem jednak podejść do tego inaczej.

Pierwsza wersja alfa była zasadniczo migracją jeden do jednego, z wyjątkiem bazy danych.

Wprowadziliśmy kilka nowych encji i przeorganizowaliśmy zarządzanie treścią. Chciałem, żeby korzystanie z CMS przypominało bardziej Pipedrive lub HubSpot, z nawigacją po lewej i treścią po prawej.

Migracja istniejącej strony

Warto zaznaczyć, że nie tworzyliśmy całej strony od zera.

Mieliśmy już treści, struktury stron, pomysły projektowe i lata wcześniejszej pracy.

To prawdopodobnie już czwarta duża wersja naszej witryny.

W 2019 roku zaczęliśmy od motywu Flaton dla WordPress. Mieliśmy wtedy nawet inne logo.

Później stworzyliśmy własny motyw, aktualizowaliśmy go i dalej ulepszaliśmy interfejs.

Nasz projektant pracował też nad najnowszym systemem projektowym, zanim rozpoczęła się migracja.

Była to więc pełna migracja techniczna i przebudowa struktury istniejącej strony, a nie tworzenie całkowicie nowego produktu od podstaw.

Na potrzeby migracji treści wyeksportowaliśmy wszystko z WordPress i za pomocą agenta AI odwzorowaliśmy te dane w nowym modelu bazy danych Payload CMS.

Agent pomógł przekształcić treści tak, aby pasowały do nowej struktury, zamiast po prostu kopiować wszystko do innej bazy danych.

Agentów użyliśmy również do wdrożenia nowej strony, przełączenia ruchu z implementacji PHP oraz usunięcia starych plików PHP i konfiguracji z serwera.

Czy było to najbardziej eleganckie podejście?

Prawdopodobnie nie.

Ale dla nas był to najszybszy sposób, żeby wszystko przenieść i uruchomić.

Naprawianie tego, co nie przetrwało przepisywania

Po zakończeniu pierwszego przepisywania patrzyłem na praktycznie tę samą stronę, tylko z niewielkimi różnicami.

Wtedy zacząłem naprawiać błędy.

Gdzieś przestał działać slider. Gdzieś rozjechał się układ. Niektóre komponenty nie zachowywały się dokładnie tak jak wcześniej.

Podczas naprawiania tych problemów zauważyłem, że nie wszystkie komponenty zostały prawidłowo zastąpione.

Niektóre szablony stron nadal zawierały surowy HTML, a inne miały nowo utworzone komponenty, które tylko trochę przypominały te wielokrotnego użytku, które już mieliśmy.

Zacząłem więc identyfikować i katalogować te miejsca, a następnie poprawiać je jedno po drugim.

Prompt brzmiał mniej więcej tak:

Hej, oto sekcja [podaj nazwę lub identyfikator sekcji]. Zastąp ją istniejącym komponentem wielokrotnego użytku [podaj nazwę komponentu]. Zachowaj taką samą lub podobną semantykę i zachowanie, usuń starą implementację i wyczyść nieużywany kod.

Dalej zastępowałem stare implementacje, ulepszałem renderowanie po stronie serwera, wprowadzałem buforowanie i optymalizowałem komponenty.

Od 12 do 23 października poświęcałem na ten drugi etap około czterech godzin w każdy dzień roboczy, łącznie mniej więcej 32 godziny.

Jeden agent tworzy, drugi sprawdza, a człowiek decyduje

Innym ciekawym aspektem była organizacja prac programistycznych i wdrożenia.

Zamiast używać jednego agenta do wszystkiego, utworzyłem kilku agentów o konkretnych obowiązkach: jednego do zbadania starej implementacji, kolejnego do odtworzenia istniejącego interfejsu na nowej platformie, innych do weryfikacji implementacji i jednego do obsługi wdrożenia.

Stworzyłem też umiejętności wielokrotnego użytku — skills — zawierające instrukcje dotyczące skryptów wdrożeniowych, testowania i weryfikacji, aby agenci mogli korzystać z tych samych procesów bez konieczności wyjaśniania wszystkiego od początku za każdym razem.

Te umiejętności zawierały instrukcje dotyczące poruszania się po naszym systemie projektowym, ponownego wykorzystywania tokenów projektowych i pracy z nowo wprowadzonymi frameworkami.

Dlaczego skills? Ponieważ pozwalają agentom ponownie wykorzystywać tę samą wiedzę i instrukcje bez tworzenia zbyt wielu ściśle wyspecjalizowanych agentów do każdego pojedynczego zadania.

Podczas przeglądu kodu w dużej mierze polegałem na porównaniach zmian w Git, sprawdzając, czy nie pojawia się powielony kod, zbędna złożoność lub niespójne implementacje. Gdy tylko coś takiego znalazłem, prosiłem agentów o poprawkę.

Ponieważ Next.js i Payload CMS oferują już sprawdzone wzorce architektoniczne, poleciłem agentom trzymać się tych konwencji, zamiast wymyślać własną architekturę.

Zlecałem też osobnym agentom przegląd implementacji.

Proces był dość prosty:

Jeden agent tworzy, drugi sprawdza, a człowiek decyduje, co jest dobre, a co nie.

A człowiek zwraca uwagę na samą stronę, nie tylko na kod.

Ręcznie sprawdzaliśmy interfejs, przyglądaliśmy się renderowaniu stron, testowaliśmy komponenty i wykrywaliśmy problemy wizualne, których sam przegląd kodu mógł nie ujawnić.

Około 30% czasu poświęciłem na przegląd kodu, sprawdzanie implementacji i weryfikację rezultatów.

Wprowadziłem też dodatkowe kontrole wykonywane przez agentów przed wdrożeniem, aby wykryć pozostałe problemy i usunąć kod pozostawiony po kolejnych iteracjach.

Bo AI generuje ogromne ilości kodu.

Jeśli nikt nie zwraca uwagi na to, co powstaje, łatwo po prostu zastąpić stary dług techniczny nowym.

Tłumaczenie strony za pomocą agentów AI

Kolejną ważną częścią wdrożenia były tłumaczenia.

Wcześniej korzystaliśmy z GTranslate do tłumaczenia treści w czasie rzeczywistym.

Tym razem chciałem obsługiwać tłumaczenia bezpośrednio w naszej platformie.

Wykorzystaliśmy agenta AI do przetłumaczenia angielskich treści na wszystkie pozostałe wersje językowe strony.

Prompt brzmiał:

Tłumaczysz treści z języka angielskiego na [język docelowy].

Przeanalizuj angielską wersję treści i zidentyfikuj nazwy marek, terminy specyficzne dla danej technologii, nazwy produktów i inne nazwy własne.

Przed tłumaczeniem upewnij się, że rozumiesz pierwotną intencję i dokładne znaczenie treści. Zachowaj je w tłumaczeniu możliwie najwierniej, przestrzegając jednocześnie zasad języka określonego jako [język docelowy].

W stosownych przypadkach zachowaj nazwy marek, produktów i terminologię specyficzną dla danej technologii.

Po przetłumaczeniu zweryfikuj swoją pracę: upewnij się, że znaczenie zostało zachowane, język brzmi naturalnie i nie pominięto żadnej treści.

Przetłumacz wszystkie treści, w tym tytuł artykułu, nagłówki, tekst główny i wszystkie powiązane metadane.

Nie chodziło jedynie o tłumaczenie słów. Chciałem, żeby treści były zgodne z zasadami danego języka i brzmiały naturalnie dla lokalnych odbiorców.

Oddzieliliśmy też informacje specyficzne dla marek od treści do tłumaczenia, aby nazwy firm, produktów i inne ważne terminy nie były tłumaczone błędnie.

Teraz możemy zarządzać tłumaczeniami bezpośrednio w naszym CMS, bez polegania na wtyczce tłumaczącej wszystko w czasie rzeczywistym.

Oczywiście tłumaczenia AI nie są idealne, zwłaszcza w przypadku treści technicznych dotyczących Salesforce, CRM i inżynierii oprogramowania.

Jeśli więc odwiedzicie naszą stronę w swoim języku i zauważycie, że coś brzmi nienaturalnie, jest źle napisane albo nie ma sensu, po prostu wyślijcie mi wiadomość prywatną.

Zajmę się tym.

Kiedy Figma, Codex i GPT-6 połączyły siły

W międzyczasie nasz projektant ukończył nowy system projektowy w Figma. I wtedy zaczęło się robić ciekawie.

Figma obsługuje integrację przez MCP, a my już korzystamy z OpenAI w połączeniu z Salesforce i innymi platformami. Połączyłem więc Figma ze swoim kontem OpenAI.

Dzięki temu mogłem wziąć link do węzła w Figma — przycisku, sekcji czy innego komponentu — i przekazać go do Codex działającego z modelem GPT-6. Codex pobierał projekt i wdrażał go bezpośrednio na naszej stronie.

Dzięki wcześniejszej pracy nad wydzielaniem komponentów wielokrotnego użytku mógł zastosować nowy system projektowy na wielu stronach, zamiast wdrażać te same zmiany wszędzie osobno. Zamiast ręcznie pisać CSS i dopasowywać każdy odstęp wewnętrzny, promień zaokrąglenia czy układ komponentu, mogłem wykorzystać pracę projektanta z Figma i zlecić jej wdrożenie w kodzie.

Oczywiście nie było to całkowicie automatyczne. Nadal musiałem sprawdzać kod, strukturę HTML, zachowanie komponentów i miejsca, w których OpenAI mogło pójść na skróty lub źle zrozumieć wymagania.

Średnio każdy komponent wymagał około dwóch iteracji.

I na tym skupiałem najwięcej uwagi.

Co rzeczywiście osiągnęliśmy

Dzięki nowej implementacji w Node.js, buforowaniu, renderowaniu po stronie serwera i innym optymalizacjom strony ładują się teraz średnio w mniej niż sekundę, w porównaniu z około pięcioma lub sześcioma sekundami przed przebudową.

Analizowaliśmy wskaźniki wydajności w przeglądarce, w tym renderowanie stron, Largest Contentful Paint i przesunięcia układu, a audyty Semrush wykorzystywaliśmy do oceny kondycji witryny, dostępności dla robotów, nawigacji i innych kwestii technicznych.

Ale oceniałem też wydajność w znacznie prostszy sposób.

Na starej stronie faktycznie widziałem opóźnienia, zarówno na telefonie, jak i na komputerze. Strony potrzebowały czasu na załadowanie, a korzystanie z nich nie było szczególnie wygodne.

Po nowym wdrożeniu różnica była widoczna od razu.

Strona po prostu sprawia wrażenie znacznie szybszej.

Oczywiście subiektywne wrażenie nie zastępuje pomiarów technicznych, ale było dla mnie ważnym wskaźnikiem, bo właśnie tego doświadczają prawdziwi użytkownicy.

Kolejną ważną poprawą było zmniejszenie liczby problemów technicznych.

We wrześniu i październiku Semrush zgłaszał około 2 000 problemów, a w szczytowych momentach ich liczba zbliżała się do 3 000.

Teraz mamy około 400 problemów, z czego mniej więcej 200 wynika z tego, że mechanizm ochrony adresów e-mail Cloudflare jest zgłaszany jako niedziałające linki wewnętrzne.

Nadal jest co poprawiać, ale w porównaniu z punktem wyjścia sytuacja wygląda zupełnie inaczej.

Od utrzymania strony do treści trafiających bezpośrednio do klienta

Wydajność nie była jedyną poprawą.

Osiągnęliśmy też coś być może jeszcze ważniejszego: znacznie wygodniejszy sposób tworzenia treści i zarządzania nimi.

Wcześniej zmiana strony wymagała, aby ktoś ręcznie zaktualizował szablony, dostosował treści i zajął się pracą techniczną.

Zamiast angażować wiele osób w przekształcanie naszych doświadczeń w treści na stronę, większość rutynowej pracy możemy wykonać za pośrednictwem platformy.

Inżynier nie musi zostawać copywriterem. Opiekun klienta nie musi zostawać programistą. A osoba, która ma pomysł, nie powinna czekać miesiącami, aż ktoś wdroży go na stronie.

I nie oznacza to produkowania bezwartościowych, sztucznych treści generowanych przez AI.

Weźmy choćby ten artykuł.

W rzeczywistości nie jest pisany ręcznie. Pomysły i przemyślenia są dyktowane, zamieniane na tekst, a następnie dopracowywane.

Możemy powiedzieć na przykład: „Przeredaguj to, popraw brzmienie tej części, usuń zbędne słowa, użyj uprzejmiejszego języka”.

Ale pomysły, doświadczenia i opowieść nadal są nasze.

AI pomaga nam zamienić myśli w czytelny tekst, podobnie jak pomogło przełożyć projekt i wymagania techniczne na działający kod.

I właśnie o taki sposób pracy nam chodziło.

To samo podejście może sprawdzić się w artykułach technicznych, historiach sukcesu klientów, opisach usług i innych treściach, którymi chcemy się dzielić.

Wcześniej w dużym stopniu polegaliśmy na copywriterach i administratorach strony, którzy zamieniali kilka słów ekspertów technicznych w pełne artykuły.

Ekspert techniczny przez kilka minut wyjaśnia, co zrobił, a copywriter zamienia to potem w tysiące słów.

Obszerne, efektowne artykuły z mnóstwem tekstu, wyjaśnień i — dość często — lania wody.

Tymczasem sam inżynier prawdopodobnie opisałby ten sam projekt w kilku zdaniach:

„Tak, zrobiliśmy to. Było łatwo. Było ciekawie. Było fajnie”.

Może przy okazji wspomni o korzyściach biznesowych. Chociaż to opiekun klienta powinien umieć wyjaśnić je znacznie lepiej.

Chcemy, żeby nasi inżynierowie krótko wyjaśnili, co było ciekawego we wdrożeniu, co stanowiło wyzwanie techniczne i co było użyteczne, a potem wrócili do innej interesującej pracy.

Zamiast spędzać godziny na opisywaniu wszystkiego komuś, kto ostatecznie zamieni to w artykuł.

Właśnie taką rutynową pracę chcieliśmy wyeliminować.

To także mam na myśli, mówiąc o przybliżaniu realizacji usług do klienta.

AI może pomóc usunąć rutynową pracę pomiędzy tymi osobami, aby wiedza trafiała znacznie bardziej bezpośrednio od tych, którzy ją mają, do tych, którzy jej potrzebują.

Nakład pracy i koszty

Oczywiście nie oznacza to, że cała przebudowa strony kosztowała €245.

Ta kwota nie obejmuje mojego czasu, pracy naszego projektanta, infrastruktury ani lat wcześniejszych inwestycji w stronę.

Rozwijamy i ulepszamy naszą stronę od 2019 roku: zmieniamy motywy, odświeżamy projekty, tworzymy treści i dostosowujemy strukturę.

Podczas ostatniej migracji ponownie wykorzystaliśmy dużą część tej pracy.

Ciekawe jest jednak to, ile udało mi się osiągnąć przy około 60 godzinach własnego zaangażowania, wykorzystując AI do programowania, refaktoryzacji, testowania, wdrażania i przeglądu kodu.

Co zmieniło się w praktyce

Poniższe porównanie dotyczy czasu realizacji wdrożenia przy współpracy z programistą freelancerem, a nie budżetów projektowych ani bezpośredniego porównania liczby roboczogodzin.

Na przykład przygotowanie strony może wymagać około 40 godzin pracy programistycznej, rozłożonych na kilka tygodni pracy i bieżących ulepszeń.

Te szacunki dotyczą etapu po zdefiniowaniu pomysłu i wymagań. Opracowanie koncepcji i wymagań to ważne, odrębne etapy, których tutaj nie uwzględniamy.

Co dalej?

Podstawy techniczne są już gotowe.

Mamy platformę, którą możemy utrzymywać bez ręcznego edytowania każdej rzeczy na stronie.

Oczywiście nadal możemy edytować wszystko bezpośrednio, jeśli chcemy. Teraz jednak możemy po prostu powiedzieć agentowi utrzymującemu naszą stronę:

Hej, dodaj [artykuł], użyj [obrazów], utwórz na podstawie tej treści infografiki lub tabele i opublikuj ją jako [studium przypadku lub artykuł blogowy].

To samo dotyczy aktualizowania istniejących stron.

Na przykład:

Weź tę stronę [podaj adres URL lub tytuł strony], znajdź tę sekcję [podaj nazwę, tytuł lub identyfikator sekcji] i ją zaktualizuj. Zastąp obraz, popraw lub rozbuduj tekst zgodnie z moimi instrukcjami i upewnij się, że wszystko jest zgodne z naszym istniejącym systemem projektowym. Zachowaj funkcjonalność komponentu i zweryfikuj zmiany.

Niezależnie od tego, czy chcemy wymienić obraz, rozbudować opis usługi, opublikować artykuł czy zaktualizować całą sekcję, możemy wyjaśnić cel, sprawdzić rezultat i w razie potrzeby wprowadzić poprawki.

To oszczędza godziny rutynowej pracy, które możemy przeznaczyć na rozwijanie pomysłów, badanie potrzeb klientów i tworzenie użytecznych treści.

Tak, teraz sytuacja wygląda znacznie lepiej pod niemal każdym względem.

Infrastruktura jest gotowa. Platforma jest łatwa w utrzymaniu. Wystarczy jasno powiedzieć, czego potrzebujesz, a agent może dodać to w kilka minut. Łatwiej publikujemy treści i mamy znacznie większą kontrolę nad działaniem strony.

Teraz możemy skupić się na pomysłach zamiast na kwestiach technicznych.

Ważniejsza zmiana dotyczy jednak tego, jak możemy pracować z klientami.

Zamiast oddzielać inżynierów, opiekunów klientów, marketing i administratorów strony licznymi etapami i procesami, możemy znacznie usprawnić bezpośrednią wymianę wiedzy.

Osoby rozumiejące problemy klienta mogą dzielić się wiedzą, a osoby tworzące rozwiązania mogą usłyszeć, czego klienci naprawdę potrzebują.

Technologia nigdy nie miała być problemem, na którego rozwiązywanie poświęcamy większość czasu.

Miała pomagać nam przekazywać nasze pomysły klientom.

I wreszcie technologia przestała być utrapieniem.