Opieka techniczna WordPress w Amsterdamie

Polski zespół, który utrzymuje WordPressa dla firmy w Amsterdamie, nie dokłada „jeszcze jednego abonamentu aktualizacji”. Utrzymuje serwis, który stoi obok landingów fintech z Zuidas, sklepów D2C z De Pijp, stron korporacyjnych z integracją Exact Online, formularzy leadowych z webhookami do CRM i witryn NL/EN, na rynku, gdzie martwy formularz albo regresja checkoutu iDEAL w piątek przed King’s Day to temat na rozmowę z compliance officerem i z księgowością, a nie tylko z marketingiem. Ta strona opisuje opiekę techniczną WordPressa właśnie w tym układzie: polski delivery, amsterdamski kontekst fintech i e-commerce, bez cennika i bez obietnic dostępności w procentach.

Szerszy opis produktu opieki, niezależny od miasta, jest na stronie opieki technicznej WordPress. Tu schodzimy do Amsterdamu: B. Amsterdam, Adyen, AVG z holenderską Autoriteit Persoonsgegevens (AP), pytanie o hosting w EOG, koordynacja freeze na King’s Day i Black Friday oraz dziennik incydentów, który da się pokazać przy audycie. Sklep WooCommerce z checkoutem iDEAL to osobna ścieżka: programista WooCommerce w Amsterdamie. Budowa od zera albo przebudowa motywu idzie do programisty WordPress w Amsterdamie. Filary niezależne od miasta: programista WordPress i programista WooCommerce.

#Co oznacza opieka WordPress przy serwisie B2B, fintech albo e-commerce

Opieka to nie „włącz auto-update i miej nadzieję”. Dla strony korporacyjnej z Amsterdamu-Zuid, sklepu D2C z magazynem w Haarlem, platformy SaaS z B. Amsterdam albo serwisu NL/EN z integracją Mollie utrzymanie ma cztery twarde elementy: aktualizacje na kopii testowej, kopie zapasowe, które da się odtworzyć, WAF z sensownymi regułami oraz dziennik incydentów, który przeżyje pytanie audytora AP. Reszta - drobna zmiana w motywie, nowy formularz leadowy, poprawka Core Web Vitals na stronie z mapą biur - wisi na tym fundamencie. Bez niego kolejna wtyczka tylko powiększa powierzchnię ataku.

Serwis w Amsterdamie często zbiera dane, których nie wolno traktować jak treści bloga. Formularz zapytania B2B z numerem KVK, konto klienta z adresem dostawy w Beneluksie, zapis do newslettera po zgodzie cookie, panel partnera z danymi kontaktowymi, logowanie do strefy dystrybutora: każdy z tych ekranów po aktualizacji wtyczki potrafi się rozsypać ciszej niż strona główna. Dlatego regresja nie kończy się na „strona się ładuje”. Kończy się na ścieżce, którą kupujący, partner albo redaktor NL/EN naprawdę klika.

#Aktualizacje wyłącznie przez środowisko testowe

Rdzeń WordPress, wtyczki i motyw idą najpierw na środowisko testowe. środowisko testowe ma ten sam stos PHP, ten sam obiekt cache jeśli produkcja go ma, te same wtyczki płatności albo formularzy w trybie sandbox. Aktualizacja „od razu na żywo, bo to tylko patch” jest najkrótszą drogą do martwego checkoutu iDEAL w czwartek przed King’s Day albo do formularza leadowego, który przestaje zbierać dane w oknie kampanii Black Friday.

Po wgraniu łatek na kopii testowej idzie checklista, nie wyczucie. Logowanie wp-admin, zapis strony, formularz kontaktowy, koszyk i płatność iDEAL jeśli jest WooCommerce, cron, poczta wychodząca, webhooki CRM, purge cache po publikacji nowej oferty B2B, regresja wersji holenderskiej i angielskiej. Dopiero po tym produkcja. Ścieżka wycofania jest zapisana zanim ktokolwiek naciśnie deploy: która kopia, który tag, kto ma dostęp do hostingu. Jeśli tego nie ma na piśmie, to nie ma rollbacku, tylko improwizacja.

#Kopie operacyjne to nie archiwum compliance

Codzienna kopia WordPressa służy do odtworzenia serwisu po błędzie albo ataku. Archiwum compliance dotyczy czego innego: rejestrów przetwarzania, dowodów audytowych i możliwości wglądu organu nadzorczego. Kopia w panelu hostingu nie spełnia wymogów archiwum sama z siebie. Brakuje niezmienności, kompletności i dokumentacji procedury.

W praktyce utrzymania rozdzielamy trzy warstwy. Pierwsza: kopia operacyjna strony i bazy, z retencją zapisaną w runbooku, testem odtworzenia, nie tylko „backup job zielony”. Druga: logi zmian i incydentów, które pokazują kto, kiedy i co wgrał. Trzecia: archiwum compliance u klienta, zwykle w DMS albo u doradcy prawnego w Amsterdamie albo w Hadze. Trzymanie tych trzech warstw w jednym katalogu FTP kończy się tym, że po dwóch latach ginie ślad, który przydałby się przy kontroli, a zostaje stos plików bez adresata.

#WAF, monitoring i dziennik pod audyt

WAF (mod_security, Cloudflare WAF albo reguły u hostera) odcina typowe skany i wstrzyknięcia, zanim dotrą do PHP. To nie zastępuje aktualizacji. To kupuje czas. Skan malware i kontrola integralności plików łapie to, co WAF przepuścił albo co weszło skradzionym hasłem. Dwuskładnikowe logowanie do wp-admin i ograniczenie liczby kont z uprawnieniem administratora są tańsze niż forensics po kradzieży sesji.

Dziennik incydentów jest równie ważny jak sama tama. Zapis: czas wykrycia, czas ograniczenia, czas przywrócenia, przyczyna, lista zmienionych plików i wtyczek, kto był powiadomiony. Dla właściciela firmy z B. Amsterdam, operatora sklepu z De Pijp albo dyrektora IT z Zuidas ten plik jest surowcem do zgłoszenia. Agencja WordPress nie składa raportu do AP za klienta. Dostarcza oś czasu, której klient nie musi rekonstruować z pamięci.

#Amsterdam jako kontekst, nie jako ozdobnik w tytule

Amsterdam to największy ośrodek e-commerce i fintech w Holandii, dom B. Amsterdam w Amsterdamie-Zuidoost i siedziba Adyen przy Rokin. To nie jest Rotterdam z portem kontenerowym ani Haga z instytucjami dyplomatycznymi. Tu serwis WordPress często obsługuje landingi produktowe, sklepy D2C, formularze leadowe z integracją CRM albo strony employer branding dla firm z ekosystemu fintech, które muszą przeżyć aktualizację w tym samym tygodniu, w którym prawnik i tak pyta o AVG, hosting w EOG i cookie banner zgodny z holenderską interpretacją zgody.

#B. Amsterdam, fintech i e-commerce

B. Amsterdam w Amsterdamie-Zuidoost koncentruje setki firm cyfrowych: od D2C przez SaaS po marketplace. WordPress trzyma landingi produktowe, formularze demo, blogi techniczne i strony employer branding dla firm, które wyszły z inkubatora albo właśnie zamknęły rundę seed. Awaria po aktualizacji wtyczki formularza albo regresja w tłumaczeniach NL/EN boli w tygodniu demo day albo przed rozmową z inwestorem, nie w sierpniu.

Dla utrzymania wynika z tego prosta rzecz: aktualizacja wtyczki cache, integracji z HubSpot albo WPML musi przejść checklistę, która obejmuje formularz demo z polami KVK i panel partnera z mapą lokalizacji. środowisko testowe z tym samym stosem PHP i tymi samymi wtyczkami w sandbox to minimum, nie luksus. Founder z biura w B. Amsterdam nie akceptuje argumentu „strona główna działa”, kiedy formularz rejestracji zwraca 500 po aktualizacji wtyczki sesji.

Adyen jako pracodawca ustawia poprzeczkę dla dostawców łańcuchu: pytania o lokalizację danych i retencję logów pojawiają się wcześniej niż na typowym polskim rynku B2B. Uniwersytet w Amsterdamie (UvA) i Hogeschool van Amsterdam dostarczają ludzi, którzy umieją odróżnić motyw od wtyczki i wiedzą, że Polylang nie zastąpi procesu akceptacji EN.

#King’s Day, Black Friday i koordynacja freeze

Koningsdag (27 kwietnia) i okres Black Friday to okna, w których firma w Amsterdamie nie toleruje eksperymentu na produkcji. Runbook freeze zapisuje: brak deployów od tygodnia przed eventem, aktualizacje krytyczne bezpieczeństwa tylko przez środowisko testowe i okno nocne, osobny przegląd cache i limitów PHP przed szczytem ruchu. Marketing zaplanował kampanię na piątek rano; developer, który robi „drobny patch cache” w czwartek wieczorem, uczy się kosztu na własnej skórze, kiedy formularz kontaktowy zwraca 500 przy pełnym ruchu.

To nie preferencja developera. To decyzja operacyjna uzgodniona z klientem przed sezonem. Ten sam schemat stosujemy przy wdrożeniach B2B, gdzie portal musi zostać dostępny w oknie zamówień tygodniowych. Kto robi „drobny patch bramki” w czwartek przed Black Friday, uczy się tego na własnej skórze, kiedy iDEAL redirect zwraca błąd przy pełnym koszyku.

#Operacje specyficzne dla Holandii i EOG

Polski zespół zna WordPressa. Holenderski klient pyta o coś innego: gdzie leżą dane, czy serwer jest „w EOG”, jak długo trzymamy logi, kto jest administratorem danych, czy mamy Data Processing Agreement. Te pytania trzeba umieć obsłużyć procesem, nie sloganem o „zgodności z AVG”.

#AVG i holenderska AP

Holandia stosuje RODO jako AVG (Algemene verordening gegevensbescherming). Organ nadzorczy to Autoriteit Persoonsgegevens (AP). Dla WordPressa w Amsterdamie wynika z tego konkretny zakres utrzymania: lista podprocesorów (host, CDN, poczta, analityka, bramka płatności), umowa powierzenia tam, gdzie agencja przetwarza dane, procedura naruszenia w 72 godziny, minimalizacja danych w formularzach, privacybeleid zgodne z art. 13 AVG.

Utrzymanie nie zastępuje DPO klienta. Dostarcza logi, oś czasu i opis zmian po incydencie. Klient klasyfikuje, czy zdarzenie wymaga zgłoszenia do AP. Nikt po stronie agencji nie podpisuje się pod „jesteście zgodni z AVG, bo macie WAF”. To byłoby kłamstwo opakowane w produkt. AP publikuje wytyczne i narzędzia audytowe na autoriteitpersoonsgegevens.nl; runbook opieki powinien być z nimi zgodny co do tego, co agencja dokumentuje, a co zostaje po stronie administratora danych.

#Hosting w EOG

Dane osobowe pod AVG ciągną pytanie: w której jurysdykcji stoi serwer. AMS1 u TransIP w NL, AWS w Irlandii (eu-west-1), OVH we Francji, Hetzner w Niemczech to różne odpowiedzi dla compliance officer, ale wszystkie mieszczą się w EOG. Ashburn albo Oregon to Stany i zwykle veto bez Standard Contractual Clauses albo innej podstawy transferu.

Pytanie „czy hosting jest w Amsterdamie” wraca rzadziej niż „czy w EOG”. Odpowiedź operacyjna jest dwuczęściowa. Jurysdykcja: EOG, kopia nie wyjeżdża nocą na bucket w regionie US bez uzgodnienia. Latencja: origin w Holandii albo Irlandii plus CDN z terminałem TLS w EOG zwykle wystarcza dla użytkowników Beneluksu i w Europie Środkowej. Amsterdam ma centra danych w aglomeracji, ale origin WordPressa nadal często stoi u dostawcy z regionem holenderskim albo irlandzkim. To nie jest wada. To jest jawna decyzja rezydencji, którą trzeba opisać w runbooku.

Rozmowa o hostingu w onboardingu jest więc merytoryczna, nie wizerunkowa. Czy produkcja jest w EOG? Czy kopia wyjeżdża? Czy CDN kończy TLS w uzgodnionej strefie? Czy obiekt cache nie trzyma prywatnego koszyka ani nieopublikowanej oferty B2B? Utrzymanie, które „wrzuca wszystko na najtańszy VPS w USA”, nie przechodzi rozmowy z prawnikiem firmy z Zuidas ani z dyrektorem e-commerce przed Black Friday.

#Cookie banner, holenderska interpretacja zgody i oczekiwania rynku

Holenderski rynek jest wyczulony na cookie i tracking. AP wymaga świadomej zgody przed nieistotnymi plikami cookie. Wtyczki zgody (Complianz, Cookiebot, Iubenda) integrują się z GTM i Meta Pixel. Aktualizacja motywu albo wtyczki cache potrafi wyłączyć blokowanie skryptów do momentu, kiedy AP albo klient zauważy, że analityka leci przed zgodą. W opiece kwartalny przegląd bannera i tagów na kluczowych szablonach jest częścią runbooku, nie dodatkiem SEO.

#Redakcja dwujęzyczna NL/EN w utrzymaniu

Najczęstsze tarcie we współpracy Polska - Amsterdam nie jest w PHP. Jest w tonie i w parze języków. Holenderski UI strony firmowej używa formy grzecznościowej u. Angielska wersja nie może być dosłownym tłumaczeniem z polskiego briefu. Polylang i WPML rozwiązują hreflang i kopie językowe. Nie rozwiązują procesu: kto akceptuje holenderski tekst, kto angielski, zanim pójdzie na produkcję.

W opiece każda aktualizacja wtyczki wielojęzycznej przechodzi regresję obu wersji językowych na stagingu. Regresja „NL się zepsuło, bo ktoś edytował EN” wychodzi dopiero na porównaniu, nie w Lighthouse. Runbook zapisuje, czy akceptacja leży po stronie klienta w Amsterdamie, po stronie polskiego content leada, czy po obu równolegle.

#iDEAL, checkout i wysyłka, których nie wolno łatać w ciemno

Ta strona nie publikuje cen WPPoland. Opisuje, jak utrzymanie ma chronić checkout, nie jak go budować od zera. Sklep WooCommerce, który po aktualizacji wtyczki płatności gubi redirect iDEAL albo numer BTW na fakturze, produkuje incydent operacyjny, nie błąd UX. W utrzymaniu pilnujemy, żeby wtyczka płatności, pole podatkowe i PDF nie rozjechały się po patchu.

Polski runbook checkoutu nie przenosi się do Holandii jeden do jednego. W Amsterdamie obowiązują EUR, holenderski BTW, iDEAL, Bancontact, PostNL i inne bramki niż na rynku krajowym. Sklep z wysyłką do Belgii albo Niemiec wymaga osobnej checklisty po każdej aktualizacji wtyczki wysyłkowej. Opieka skopiowana z instalacji w Polsce wywala się na pierwszej fakturze z BTW i na etykiecie PostNL, której kurier nie skanuje w punkcie odbioru PakjeGemak.

Webhooki bramki i status zamówienia muszą przeżyć aktualizację WooCommerce. Aktualizacja wtyczki płatności, która na produkcji nadpisze mapowanie callbacków, zostawia magazyn z ręcznym klejeniem statusów zamówień. Dlatego te wtyczki nigdy nie idą w tym samym oknie co „drobna aktualizacja SEO”. Pełny zakres programowania sklepu opisuje programista WooCommerce w Amsterdamie.

#Reakcja na incydent bez pustych procentów

Obietnica dostępności zapisana procentem na stronie city to ozdobnik, nie kontrakt. Dostępność wynika z hostingu, DNS, CDN, wtyczek i ludzi. Opieka opisuje procedurę, nie talizman.

Wykrycie: monitoring syntetyczny plus alert z WAF albo z hosta. Triage: czy to treść, czy płatność iDEAL, czy wp-admin, czy cała produkcja, czy wyciek oferty przed King’s Day. Ograniczenie: tryb konserwacji, cofnięcie wtyczki, wyłączenie endpointu, rotacja haseł, twardy WAF, purge cache. Odtworzenie z kopii, jeśli pliki są spalone. Dokumentacja osi czasu. Post-mortem z przyczyną i z działaniem, które ma nie powtórzyć się za miesiąc.

Czas pierwszej odpowiedzi zapisujemy w umowie. W dniach roboczych priorytet zwykle zamyka się w oknie godzin, nie dni. Dyżur poza tym oknem jest wtedy, gdy umowa go obejmuje. Przy freeze King’s Day albo Black Friday okno bywa szersze niż w zwykłym miesiącu, bo koszt martwego landingu w kwietniu albo listopadzie jest wyższy niż koszt dyżuru. Ta strona nie sprzedaje uniwersalnego SLA w tabelce. Sprzedaje porządek: widać, kto wszedł, co zmienił, kiedy serwis wrócił.

Jeśli klient musi złożyć zgłoszenie do AP albo do wewnętrznego audytu, dziennik z opieki jest załącznikiem. Brak dziennika oznacza, że compliance składa raport ze zrzutów ekranu i ze wspomnień z Slacka.

#Przypadek: aktualizacja cache położyłaby formularz przed kampanią, środowisko testowe to zatrzymał

Serwis korporacyjny na WordPressie, firma fintech z Amsterdamu-Zuid, ruch z LinkedIn i newslettera, piątek 10:00 start kampanii z formularzem leadowym. W kolejce do produkcji leżała aktualizacja wtyczki cache obiektowego plus patch SEO, „drobny, na żywo, bo to tylko Redis”.

Na środowisku testowym, sklonowanym z produkcji razem z Redisem, formularz kontaktowy po wysłaniu zwracał błąd 500. Przyczyna: zmiana klucza sesji po patchu cache, stary fragment motywu wołał $_SESSION przed inicjalizacją WordPressa, CDN trzymał HTML formularza bez rozróżnienia zalogowany/niezalogowany. Na produkcji ten sam zestaw poszedłby w czwartek wieczorem. Kampania wyszłaby o 10:00, setki leadów utknęłyby bez zapisu, support dostałby ticketów zanim ktokolwiek zdążyłby cofnąć deploy.

środowisko testowe zatrzymał release. wycofanie zmian na kopii testowej potwierdził, że sama wtyczka SEO jest niewinna, gdy motyw inicjalizuje sesję przed hookiem WordPressa. Motyw dostał poprawkę, checklista formularza (wysłanie, mail potwierdzenia, zapis do CRM, purge cache) przeszła, dopiero potem produkcja. Nie ma tu nazwy firmy, bo to kształt zdarzenia, nie case study z logotypem. Jest mechanizm: najpierw kopia, potem produkcja.

Ten sam kształt wraca przy wtyczce consent, która po aktualizacji wysyła Meta Pixel przed zgodą cookie, przy polu KVK znikającym z formularza po patchu ACF i przy „drobnej” aktualizacji, która wyłącza webhook CRM. Amsterdam nie wybacza tego ciszej niż inny rynek. Wygląda to gorzej, bo obok siedzi ktoś, kto pyta o AP, o AVG albo o slot w kalendarzu kampanii.

#WordPress Amsterdam Meetup i praktyka, której nie widać w panelu hostingu

WordPress Amsterdam spotyka się regularnie w ekosystemie holenderskim (wpmeetupamsterdam.nl). To nie jest kanał sprzedaży. To jest miejsce, w którym widać, jak lokalni maintainerzy aktualizują Core, jak rozmawiają o uprawnieniach i o Mollie sandbox. Opieka, która nigdy nie wychodzi poza ticket, gubi ten kontekst: w Amsterdamie część zespołów i tak siedzi po stronie e-commerce i usłyszy te same pytania o AVG i iDEAL na meetupie w B. Amsterdam.

WP-CLI w utrzymaniu nie jest ozdobą meetupową. To sposób, żeby aktualizację, różnicę wtyczek i eksport listy użytkowników zrobić powtarzalnie, z logiem, bez klików wp-admin na produkcji. Po sesji o bezpieczeństwie w społeczności argument „zrobimy to ręcznie w panelu” brzmi jeszcze gorzej.

#Miesięczny rytm, onboarding i przejęcie bałaganu

Onboarding to audyt, nie kick-off z prezentacją. Inwentaryzacja wtyczek, wersja PHP, cron, poczta, SSL, WAF, czy kopia w ogóle się odtwarza, gdzie stoi serwer, kto ma dostęp SFTP i do wp-admin, czy są konta-widma po agencji, która zniknęła. Baseline Lighthouse na stronie głównej i na najważniejszym formularzu B2B, checkoucie iDEAL albo panelu partnera. Lista ryzyk z priorytetem: najpierw to, co psuje odtworzenie i bezpieczeństwo, potem to, co psuje konwersję albo publikację.

Pierwszy cykl aktualizacji na stagingu jest częścią onboardingu, nie „bonusem w miesiącu drugim”. Jeśli stagingu nie ma, jego postawienie jest pracą startową. Serwis B2B albo fintech w Amsterdamie bez kopii testowej nie wchodzi w stały abonament z otwartymi auto-update.

Miesiąc stały: okno aktualizacji poza King’s Day i Black Friday, skan, przegląd logów WAF, test odtworzenia kopii w uzgodnionym cyklu, krótki raport. Raport ma metryki (uptime z monitoringu, błędy 5xx, czas odpowiedzi, lista wgranych wersji), decyzje (wtyczka X zostaje, wtyczka Y do wymiany) i residualne ryzyko (host poza EOG, brak 2FA u redakcji, brak umowy powierzenia, cache bez reguły dla sesji, freeze King’s Day jeszcze nie wpisany). Bez residualnego ryzyka raport jest broszurą.

Przejęcie zaniedbanej instalacji zaczyna się od tej samej listy, tylko dłuższej. Stary PHP, wtyczka page buildera bez łatek, kopia tylko na tym samym dysku co produkcja, hasło admin we wpisie w Notion, checkout z trzema wtyczkami podatkowymi naraz, Redis, który trzyma sesje iDEAL w trakcie redirectu. Pierwszy miesiąc to remediacja. Stała opieka zaczyna się, gdy da się bezpiecznie wgrać łatki.

Budowa od zera albo przebudowa motywu to już inna usługa: programista WordPress w Amsterdamie. Sklep, checkout, iDEAL i BTW: programista WooCommerce w Amsterdamie. Opieka nie udaje, że jest projektem wdrożeniowym. Gdy w utrzymaniu wychodzi, że motyw trzeba napisać od nowa, to idzie jako osobne zlecenie, na piśmie.

#Wydajność przy skoku ruchu sezonowym i użytkownikach z Holandii

Origin w EOG nie naprawi ciężkiego motywu z galeriami produktowymi. HTTP/3, Brotli, AVIF, lazy load, który nie psuje LCP hero, cache, który nie trzyma prywatnego koszyka ani sesji iDEAL w trakcie redirectu, ograniczenie wtyczek z zapytań SQL na każdej podstronie: to nadal robota utrzymaniowa. Core Web Vitals mierzymy na realnych URL-ach z formularzami B2B, nie na pustej instalacji. INP psuje się od skryptów czatu, od Mollie.js ładowanego w złej kolejności i od tag managera, który marketing dodał poza ticketingiem. Opieka, która nie widzi GTM, będzie gonić „optymalizację obrazków” w nieskończoność.

Dla serwisu B2B albo e-commerce w Amsterdamie liczy się czas do pierwszego bajtu z sieci w Holandii i w Beneluksu, nie tylko z telefonu w centrum miasta. Monitoring z jednego regionu USA kłamie. Punkt pomiaru w EOG jest częścią kontraktu operatorskiego, nie dodatkiem. Strona z pełnoekranowymi zdjęciami produktów umiera na LCP od nieoszczędnych JPEG-ów szybciej niż od „słabego hostingu”. Przed King’s Day albo Black Friday idzie osobny przegląd cache, limitów PHP i CDN; po evencie idzie ścinka landingów, które mają zostać jako archiwum, i tych, które mają dostać 301.

#Bezpieczeństwo jako lista decyzji, nie jako plakietka

HTTPS z HSTS tam, gdzie infrastruktura to uniesie. Nagłówki ograniczające XSS. 2FA. Minimum kont administratorskich. Zakaz wtyczek „nulled”. Zakaz edytora plików wp-admin na produkcji. Rotacja haseł po odejściu freelancerów. Test odtworzenia kopii, bo kopia, której nikt nie odtwarzał, jest plikiem. Przy danych osobowych: umowa powierzenia, lista podprocesorów (host, CDN, poczta, analityka, bramka płatności), procedura naruszenia pod AVG.

To nie jest certyfikat ISO sprzedawany z abonamentem. To jest lista, którą da się odhaczyć przy onboardingowym audycie i wrócić do niej co kwartał. Klient z firmy w B. Amsterdam, z biura w Zuidas albo ze sklepu z De Pijp i tak przyniesie własną checklistę. Lepiej mieć swoją wcześniej. Dokumentacja hardeningu WordPress, niezależna od miasta, jest w WordPress Developer Handbook. Opieka w Amsterdamie dodaje do niej kalendarz freeze King’s Day i Black Friday, pytanie o AP oraz jawny opis rezydencji w EOG.

#Rodzeństwo w Holandii i w Beneluksu

Ten sam model opieki działa w innych holenderskich miastach i w sąsiednich stolicach Beneluksu, z tym samym runbookiem i innym kontekstem lokalnym:

• Opieka techniczna WordPress w Rotterdamie
• Opieka techniczna WordPress w Antwerpii
• Opieka techniczna WordPress w Brukseli

#Jak zaczynamy, bez zaliczek w procentach na stronie

Zakres, godziny reakcji i cena są indywidualne i lądują w umowie przed startem. Na tej stronie nie ma podziału płatności na transze procentowe i nie ma tabeli pakietów. Krótki opis serwisu, stacku, hostingu i tego, czy jest środowisko testowe, wystarczy, żeby zaproponować audyt onboardingu.

Kontakt: formularz. W zgłoszeniu przydaje się lokalizacja hostingu, lista wtyczek albo dostęp do stagingu, oraz informacja, czy serwis musi zostać w EOG i czy w najbliższych tygodniach jest King’s Day, Black Friday albo szczyt kampanii sezonowej. Z tego powstaje plan: co naprawiamy zanim w ogóle wejdziemy w miesięczny rytm, a co zostaje w kadencji.

Opieka w Amsterdamie ma sens, gdy serwis już niesie biznes i trzeba go nie zepsuć. Gdy trzeba go dopiero zbudować, wracamy do developmentu. Gdy trzeba go utrzymać przy King’s Day, formularzach B2B, checkoutcie iDEAL i AVG pod AP, zostajemy przy tym, co ta strona opisuje: środowisko testowe, kopia, WAF, dziennik, compliance po stronie klienta, hosting w EOG i runbook, który da się pokazać audytorowi bez rekonstruowania historii z pamięci.