Wat is er nieuw in Senly

stripeOnboarded-flag bleef false als de ?onboarding=complete callback niet kon voltooien (bv. door de 500-bug)

useSearchParams() zonder Suspense gooit een Next.js 14 error zodra Stripe terugredirect met ?onboarding=complete

Gebruikers konden inactieve klanten gewoon openen en gebruiken zonder te betalen (verdienmodel-lek)

Een nieuwe klant aanmaken kostte 5-10 minuten handwerk: naam, branche, kleur, doelgroep en tone-of-voice allemaal handmatig invullen — waardoor velden vaak leeg bleven.

De geanalyseerde tone-of-voice + doelgroep wordt opgeslagen in Client.toneOfVoice en Client.audience. Bestaande AI-features (captiongeneratie, content-kalender, maandrapport-narratives) kunnen dit profiel meelezen in hun system-prompts zodat alle gegenereerde content meteen op de stem van de klant aansluit zonder dat het bureau het handmatig hoeft te beschrijven.

Tags toepassen of contacten verwijderen moest één voor één.

Naast de zoekbalk verschijnt nu een Filters-knop die per user (en optioneel team-breed) zoek-query + sortering kan opslaan. Eén klik herstelt de filter.

Status-wijziging in een lead, ondertekend contract en Stripe-betalingen vuren nu ook outgoing webhooks. Webhook-receivers kunnen daarmee onboarding-flows, accounting-syncs of Slack-notificaties automatiseren zonder code.

Tags werden alleen als string opgeslagen op contacten en leads; bij import ontstond ruis (bv. `csv-import-2026-…`) en duplicates met varianten in spelling. Geen manier om kleur toe te kennen of in bulk op te ruimen.

Voor automatiseringen met Zapier, Make, n8n of een eigen backend was er geen out-of-the-box manier om Senly-events naar buiten te sturen.

Power-users met veel klanten of leads moesten elke keer dezelfde filter-combinaties handmatig instellen.

Bureaus willen data per klant of contact opslaan die niet in het standaard-schema past — NPS-score, contract-einddatum, branche-code, functie, regio, lead-bron-detail.

Klant-detail krijgt een collapsible "Eigen velden"-sectie onder Notities; CRM-contact-detail toont dezelfde velden in de slide-over. Beide secties verbergen zichzelf automatisch als er voor die entity nog geen velden gedefinieerd zijn — geen lege ruimte voor bureaus die deze feature niet gebruiken.

Bij CSV-import gingen kolommen die niet in het auto-detect-lijstje stonden verloren — terwijl ze vaak de waardevolste lead-context bevatten (functie, sector, lead-score).

De tekst op de groene "Dien commissieclaim in"-knop was zwart en moeilijk leesbaar

Het kopje "Aanbevolen voor jou" bleef zichtbaar ook al stonden er geen apps onder

De melding "niet gekoppeld" op de takenpagina noemt geen externe tool meer bij naam

Managers, setters en closers konden elkaars leads en contacten inzien in het CRM-systeem

De privacyverklaring miste een uitgebreide Google API Services sectie (vereist voor de Google OAuth verificatie van Analytics, Search Console en Bedrijfsprofiel). Verder waren veel features die er sinds de laatste update zijn bijgekomen niet beschreven: Google Insights, AI fallback ladder met 8 providers, Booking, Outreach + cookieloze tracking, Stripe + Stripe Connect, klantreview portaal.

De voorwaarden noemden verouderde prijzen (70/60 euro per klant tot 20 daarna) en ontbeerden de nieuwe Solo/Growth/Scale tiers met IP gebaseerde valuta detectie. Ook ontbraken vermeldingen van trial, refund policy, AI ondersteuning, Senly Connector eigen verantwoordelijkheid en API derden disclaimers.

Admin kon niet controleren hoe het portaal eruitziet vanuit het perspectief van een setter of manager.

Gemini stelde soms acties voor over een verzonnen pagina (bv "agency-alternatief") die niet in jouw Google Analytics of Search Console data zat. Minor hallucinatie, maar storend als je actiepunten letterlijk wilt opvolgen.

Een nieuwe prompt-versie zou pas na 24 uur effect hebben omdat de 24u-cache nog de oude samenvatting bevatte.

De widget toonde "Kon de samenvatting niet genereren". Twee oorzaken: (1) Gemini-flash is een thinking-model en het thinking at het output-budget op waardoor JSON truncated terugkwam, (2) ik gebruikte een directe Gemini-call zonder fallback naar de 7 andere providers die Senly al heeft.

Gemini gaf wel een response terug, maar maxOutputTokens stond op 600 wat soms te krap was voor een NL samenvatting plus 2 actiepunten in JSON. De output werd halverwege afgekapt en mijn JSON.parse faalde met "Unterminated string in JSON".

KPIs zijn handig maar abstract. Een eigenaar die snel wil weten wat er deze week gebeurde moest zelf grafieken interpreteren en actiepunten verzinnen. Voor agencies die dit voor klanten doen is dat herhaalbaar werk dat slim kan.

Het was nog niet vastgelegd hoe AI-output gepersisteerd of gerate-limited werd voor de Insights-toepassing.

De SVG-sparklines in Bezoekers, Bedrijfsprofiel en de nieuwe Zoekprestaties-widget waren paginalang uitgerokken zodra de widget breder dan ~150px was. De viewBox-ratio bepaalde de hoogte automatisch i.p.v. mijn bedoelde 50-70px.

Je kon de 5 nieuwe widgets (Website KPIs / Bezoekers / Bronnen / Nu online / Bedrijfsprofiel) aanzetten via Widgets beheren, maar zodra je naar een andere pagina ging en terugkwam stonden ze er weer NIET. De keuze ging dus niet naar de DB.

Op mobiel verschilde de hoogte van de detail-panel (eyebrow + titel + body + bullets) per feature omdat sommige meer/langere bullets hadden. Alles eronder (de "Krachtige extras"-sectie en verder) sprong elke wissel ~50-100px omhoog of omlaag.

De X-knop in het support-chat tooltip (rechtsboven) werd op iOS Safari verticaal uitgerekt — leek een ei i.p.v. een rondje. Width/height stonden beide op 20px maar UA-button-styling pushte de hoogte hoger.

De voorwaarden-pagina was NL-only en niet vindbaar voor bezoekers die niet door /partners of /affiliate kwamen.

Het partner-programma had nog geen publieke voorwaarden. Geen regels over wat wel en niet mag, geen uitbetaalvoorwaarden, geen termination clauses. Juridisch zwak en partners wisten niet waar ze aan toe waren.

Op mobiel in sticky-state stond de pill niet gecentreerd — links veel meer ruimte dan rechts omdat de "Senly" tekst de inhoud naar links duwde. Plus de padding was asymmetrisch (20px links / 14px rechts).

Na de v12.62-verkleining naar clamp(28, 3.7vw, 50) voelde de titel op desktop net te klein.

v12.70 voegde +67px ruimte toe tussen nav-row en eyebrow — gebruiker wilde nog ~45px extra erbij.

Mobiele hero had asymmetrische witruimte: 4px links/rechts maar 14px boven/onder. En de nav-row (Senly logo + Inloggen + NL pill) zat te dicht op de eyebrow-badge eronder.

Vorige iteratie maakte padding-top clamp(80, 12vh, 130) — gebruiker wilde de content nog hoger zien (zoals na ~30px scroll vanaf de standaard view).

De vorige fix toonde de hele tweede zin op mobiel — dat was te veel. De gebruiker wilde slechts ~2 woorden langer, niet 2 extra regels.

Op mobiel zat de titel ver onder de bovenrand door een te grote padding-top (clamp 130-200). En de subtitle was bewust ingekort tot alleen de eerste zin — voelde te kaal.

De 4 platform-tabs (Instagram, TikTok, LinkedIn, Facebook) pasten niet allemaal naast elkaar op mobiele schermen — Facebook viel deels of helemaal buiten beeld, en de tabs werden te krap geknepen.

Op mobiel zat de hero binnen relatief brede zijmarges en met een krappe padding-bottom van 48px. Daardoor oogde de content geknepen — de "Bekijk demo" knop en de checklist eronder eindigden te krap tegen de hero-rand.

De extra hero-lengte van v12.63 (padding-bottom clamp 140-180) was te lang — origineel 90px voelt beter. De sticky pill stond na scroll te dicht op de viewport-randen (17px lucht). En de hele nav (initial + sticky pill) zat met top:14 te dicht tegen de bovenrand.

Live meting op senly.io toonde: hero-top 18px, links 17px, rechts 17px witruimte, maar onderkant 0px — de hero raakte de volgende sectie direct. Asymmetrisch.

De grote titels op de homepage (Het all-in-one platform, Krachtige extras, Alles wat je nodig hebt, Live binnen een middag, etc.) waren clamp(32, 4.8vw, 64) en oogden te dominant. De pagina las als een aaneenschakeling van geschreeuwde headlines.

Bij scrollen sprong de nav-pill als een klap van de brede non-pill state (margins clamp 24-64) naar de smalle pill state (margins 14). Geen tussenliggende animatie. En ondanks scrollbar-compensatie leek de pill rechts ruimer dan links omdat .sn-nav zelf op left:14/right:14 stond, waardoor (100vw - 100%) binnen .sn-nav-inner de 28px gap meerekende i.p.v. alleen de scrollbar.

De vorige iteratie maakte de nav full-width edge-to-edge (v12.58) — dat was niet wat bedoeld was. Voor de v12.58-fix versmalde de pill op scroll naar max-width 760px in het midden.

De vorige nav was een gecentreerde "pill" met witte marges links/rechts en een morph-animatie bij scrollen. Voelde meer als een micro-component dan een echte website-header — en past niet bij "duur, premium" design.

Onder de Growth-calculator stonden twee bijna-identieke disclaimer-regels onder elkaar — één binnen de info-card en één los onder de card. Visueel lelijk en redundant.

De homepage secties zaten te krap op elkaar — voelde gehaast en weinig premium. Elegantie komt voor een groot deel van ademruimte.

De stats-rij oogde te plat — flat lichtgrijs blok met simpele iconen en tekst. Voelde niet als een duur, premium product.

De Growth-calculator op de homepage had per platform een kleurrijke gradient achtergrond, gradient tab-pill, gradient cijfers in de stats-rij en een platform-gekleurde CTA-knop. Te druk in vergelijking met de rest van de pagina.

Elke feature in de "Alles wat je nodig hebt"-carousel toonde alleen een statische screenshot. Voor sommige features (zoals het klantprofiel met brand kits) zegt een korte schermopname meer dan een stilstaand beeld.

Alle GA- en Bedrijfsprofiel-widgets toonden hardcoded 30 dagen. Wilde je vandaags piek of het kwartaaltrend zien, dan moest je naar Google.

Een KPI-getal op zichzelf is moeilijk te beoordelen — is 2.300 bezoekers veel of weinig? Je had geen referentie zonder GA open te klikken.

De rastertextuur (rgba 15,23,42 / 0.045) op de witte raster-kaarten was iets te aanwezig — leidde af van de content erin.

In de hero-titel "Wat is er nieuw in Senly" werd de schuine descender van de italic "y" rechts afgesneden. Oorzaak: padding-right van 0.1em op het accent-span was niet genoeg om de italic descender op te vangen onder background-clip: text.

Het signup-formulier ("Bedrijfsnaam", "Contactpersoon", "E-mail", "Type", "Klantvolume", "Status") stond als één lange lijst onder elkaar. Daardoor was de modal hoger dan de viewport en viel 'ie onder de top-nav weg.

Devtools-meting toonde aan dat in Chrome op macOS scrollbar-gutter: stable both-edges niet daadwerkelijk een gutter aan de linkerkant reserveert — body zit strak links, scrollbar zit 6px rechts buiten body. Daardoor was hero-rechts tot viewport-rand altijd 14+scrollbar (= 20) terwijl links 14 was. Visueel 6px scheef ondanks identieke CSS-margin-waardes.

Ondanks auto-margin en scrollbar-gutter bleef de hero in sommige browsers visueel asymmetrisch — rechterkant ruimer dan linkerkant.

Op sommige browsers werd de oude :root:has(.sn-root) selector niet matched of laat geparsed, waardoor scrollbar-gutter: stable both-edges niet altijd actief was. Dat kon de hero alsnog asymmetrisch t.o.v. de viewport positioneren — rechterkant oogde dan ruimer dan de linkerkant.

In fase 2 waren de 5 nieuwe widgets opgehangen aan PremiumDashboard, maar het actieve dashboard is TaskioDashboard met een eigen WIDGET_REGISTRY. Daardoor stonden de widgets nergens in "Widgets beheren" en kon niemand ze aanzetten.

Ondanks symmetrische margin (14px L+R) liep de rechterkant van de hero-kaart visueel verder van de viewportrand af dan de linkerkant. Oorzaak: in sommige browsers werkt scrollbar-gutter niet ideaal, waardoor 14px-margin niet 1-op-1 gerendered wordt.

Na een afgebroken Google-koppelpoging bleef ?gi_error=session_not_found in de URL staan. Elke refresh van de pagina toonde dan opnieuw de rode banner — ook al was de koppeling al lang succesvol.

De rasterachtergrond van de Platform- en Vergelijking-secties liep van rand tot rand. De hero zit juist als afgeronde "floating card" met 14px lucht aan beide zijden — visueel onsamenhangend.

.sn-nav-inner had padding 24px links en 14px rechts. Daardoor zat de rechtse content (Inloggen / NL) dichter op de pill-rand dan de linker logo+links — visueel asymmetrisch.

Na het verbinden met Google was er nog geen manier om aan te geven welke GA4-property of welke bedrijfsprofiel-locatie de data moest leveren.

Bureau-eigenaren konden hun website- en bedrijfsprofiel-statistieken niet in Senly zien. Switchen tussen Google Analytics en Bedrijfsprofiel kostte tijd en bleef vaak liggen.

De OAuth-koppeling was er, maar er was nog geen code om met de tokens daadwerkelijk data van Google op te halen.

Na de hero liepen meerdere kale-witte secties achter elkaar, zonder visueel ritme tegenover de teal-gradient secties (clock, pricing, testi). De rastertextuur die de hero zo herkenbaar maakt, kwam nergens terug.

De Uitbetaling-kaart op /affiliate kreeg eerder #eef0f2 als achtergrond. Solide, maar wat zwaarder grijs dan nodig op de witte pagina.

Na de vorige fix waren de strepen rond "SECTIE X" weg, maar boven elke nieuwe sectie liep nog een dunne grijze lijn (border-top) horizontaal door het grid-patroon. Bron: een latere light-theme override die de algemene fix overruled met !important.

De eyebrow boven elke statistieken-sectie had een 1px streep aan de rechterkant van de tekst en een border-top boven de header. Op de pagina met grid-textuur liepen die als slordige horizontale lijnen door het raster heen.

De "Uitbetaling"-kaart had in light-mode een achtergrond van rgba(255,255,255,0.02) — 2% opacity — waardoor het grid-patroon van de pagina dwars door de kaart heen liep.

Het kleine verplaats-icoontje (6 stippen) links van elke stage-titel was visueel ruis — de hele kolomkop is al sleepbaar, dus het icoon voegde alleen drukte toe.

De vorige fix gebruikte #f1f3f7 als kolom-achtergrond — die had een lichte blauwe ondertoon waardoor het bord er koeler/blauwiger uitzag dan de rest van de pagina.

De stage-kolommen op /onboarding en /crm hadden een halfdoorzichtige achtergrond (rgba 0,025). Daardoor lekte de grid-textuur van de pagina dwars door de kolommen heen — vooral zichtbaar bij hogere kolommen (twee-regelige titels) waar het patroon door de kolom liep.

Je kon contacten wel tussen kolommen slepen, maar de volgorde van de kolommen zelf zat vast op de volgorde waarin ze waren aangemaakt. Wilde je "Onboarding klaar" tussen "Start Feedback" en "Actief" zetten, dan moest je een nieuwe kolom maken en alles handmatig overzetten.

Een nieuwe flow kreeg z'n naam alleen bij aanmaken — typo of veranderd inzicht betekende dat je 'm moest verwijderen en opnieuw bouwen.

Sommige uitgaven betaal je per jaar (domeinen, jaarabonnementen, hosting). Voorheen moest je die zelf delen door 12 voordat je ze als maandbedrag invulde — anders klopten de portaalcijfers niet.

Ook na de eerste z-index-verhoging schoten de commissieniveau-titel ("30% standaard, 40% vanaf 10 bureaus"), de subtekst en de Standaard/Premium-cards nog door de popup-backdrop heen. Oorzaak: een element hogerop in de pagina-tree creëerde een lokale stacking-context (door een transform op de tier-cards), waardoor de popup-backdrop opgesloten zat in die lokale context en niet boven alle pagina-content uit kon komen.

De popup ("Meld je aan / Partner-aanvraag") verdween achter het sticky menu bovenaan, en de hero-tekst ("30% standaard, 40% vanaf 10 bureaus" + "Word nu partner") schoot tegelijk door de donkere overlay heen — onleesbare stapeling.

De footer zei "voor social media bureaus die willen schalen" — een nauwere positionering dan de homepage ("voor social media professionals"). Beide regels nu gelijk: "Het operating system voor social media professionals — zonder de tooling-chaos." Vertaald in NL/EN/DE/FR. Past bij de bredere doelgroep (bureaus, freelancers, content creators, in-house) die ook eigen landingspagina's hebben.

De demo-modal toonde "Naam / E-mail / Bereik" terwijl het echte formulier "Bedrijfsnaam / Contactpersoon / E-mail / Type / Klantvolume" vraagt — en alles was statisch waardoor de waarde van een "demo" beperkt was.

De feature-pillen op de homepage (Brand kits → Kalender → Meetings → … → Tools) krijgen er een tab "Takenbeheer" tussen Meetings en Activiteiten. Toont workload per team, deadlines/prioriteiten en de keuze tussen lijst, kanban of kalender. Per-taal screenshot (NL/EN/DE/FR) zoals de andere features, accent paars (#a855f7).

De Kortingscodes-pagina gebruikte hardgecodeerde donkere kleuren (rgba(226,232,240,…)), die in light mode bijna onzichtbaar werden — labels grijs-op-grijs, inputs zonder duidelijke contour.

De drie stat-cards stonden los naast elkaar in een vlakke rij — weinig samenhang en geen "automation"-gevoel.

De tools-rij is horizontaal scrollbaar; door een browser-eigenaardigheid clipte die scroll-container ook verticaal, waardoor de hover-schaduw van de kaarten aan boven- en onderkant werd afgesneden.

De knop-styling stond op een Next.js <Link>-component. styled-jsx voegt zijn scope-class alleen toe aan gewone HTML-elementen, niet aan React-componenten — waardoor de CSS de link nooit raakte (ook niet na cache legen).

Elke nieuwe tool heeft nu een eigen gradient-icoon in de tools-grid (hartje, grafiek, euro, pijl, schild, palet…), passend bij de kleur van de tool zelf.

Toegevoegd: Engagement-rate calculator (met benchmark per platform), Advertentie-statistieken (CPM/CPC/CPA/ROAS/break-even), Influencer-tarief calculator, Groei-projectie, Klant-ROI calculator, Instagram witregel-fixer, Fancy tekst generator (unicode bold/cursief), Formaat & safe-zones (export per social-formaat), Carousel-splitter, Kleurenpalet-extractor en een Brand-safety check. Allemaal direct, privacy-vriendelijk (alles client-side) en in 4 talen.

De vorige knop-styling was te subtiel en oogde nog als een gewone tekstlink.

De maandbalken hebben nu gradient-vullingen met diepte en een subtiele gloed, afgeronde vormen, een fijne scheiding tussen vast (recurrent) en eenmalig, een soepele opbouw-animatie en een duidelijker hover-effect (de maand komt omhoog en licht op). Toekomstige maanden tonen nu als een nette, vlakke projectie. Werkt in light- en dark-mode.

De labels (jan, feb, mrt…) waren hardcoded Nederlands en vertaalden niet mee met de taal van het portaal.

In Instellingen → Contracten staat "Bekijk alle verstuurde contracten" nu als smalle, omrande knop in plaats van een platte tekstlink.

Je moest een template eerst openen in de editor om een voorvertoning te zien.

In het overzicht zoek je nu direct op klantnaam of contract. En in de instellingen zet je met één vinkje de "contract bekeken"-melding aan of uit voor je bureau.

Je krijgt nu een in-app melding (belletje rechtsboven) zodra een klant je verstuurde contract voor het eerst opent. Uit te zetten per bureau.

Stel per template in dat een niet-getekend contract na X dagen automatisch een herinnering krijgt (dagelijkse cron). En kies "welkomstmail" als actie na ondertekenen, dan ontvangt de klant direct een persoonlijke welkomstmail van je bureau.

Je kon contracten alleen per klant bekijken. Geen totaaloverzicht van wat verstuurd/bekeken/getekend is.

Stuur in één keer hetzelfde contract naar meerdere klanten: kies een template, vink de klanten aan en verstuur. Klanten zonder e-mailadres worden netjes overgeslagen en gerapporteerd.

Tot nu tekende alleen de klant. Voor sommige overeenkomsten wil je dat beide partijen tekenen.

Zet "E-mailverificatie vereisen" aan op een template. De klant vraagt dan eerst een 6-cijferige code aan die naar zijn e-mailadres wordt gestuurd, en moet die invullen om te kunnen tekenen — een extra zekerheid dat de juiste persoon ondertekent.

Ondertekenen was alleen een vinkje + naam. Niet alle bureaus vonden dat genoeg, en de klant kon geen eigen gegevens toevoegen.

Bij ondertekening leggen we datum/tijd, e-mail, IP-adres én een SHA-256 documentcontrole (hash) vast — zichtbaar onderaan het getekende contract als bewijs dat er niets is gewijzigd. Een verlopen ondertekenlink wordt netjes geblokkeerd, en zowel klant als bureau kunnen het contract met één klik als PDF downloaden (via printen → bewaar als PDF).

Er was maar één standaard dienstverleningsovereenkomst. Voor andere situaties moest je alles zelf schrijven.

Je kon alleen de vaste variabelen (klantnaam, tarief, etc.) gebruiken.

Dupliceer een template met één klik als startpunt voor een variant. Per template stel je opties in: e-mailverificatie vereisen, het bureau laten tegen-ondertekenen, de ondertekenlink laten verlopen na X dagen, automatisch een herinnering sturen, en een actie na ondertekenen (welkomstmail).

Branches voorbij de top 8 werden gebundeld tot één "Overige"-segment met een doorzichtig-witte kleur. In de demo (waar elke klant z'n eigen branche heeft) werd dat een groot grijs blok, dat door een kleur-renderbug ook nog eens een zilveren verloop kreeg.

Bij veel branches/platforms werd de legenda scrollbaar en bleef de scrollbalk constant zichtbaar — een browser-eigenaardigheid liet zelfs een overbodige horizontale balk verschijnen.

De balken hebben nu gradient-vullingen met diepte, een subtiele gloed, afgeronde "zwevende" vormen, een fijne scheiding tussen gestapelde delen (actief/inactief), een soepele opbouw-animatie en oplichten-bij-hover. Werkt in light- en dark-mode — in dezelfde stijl als de vernieuwde ringdiagrammen.

De afkortingen (ma, di, wo…) waren hardcoded Nederlands en vertaalden niet mee met de gekozen taal.

De ringdiagrammen op de Statistieken-pagina hebben nu gradient-segmenten met diepte, een subtiele gekleurde gloed per segment, strakke scheidingen tussen de delen, een fijne binnenring, een teal-gloed met gradient-cijfer in het midden en een soepele opbouw-animatie. Beweeg je over een segment, dan licht dat segment op en dimmen de andere. Werkt in zowel light- als dark-mode.

In de e-mail-module stond boven een gesprek "2 {count} berichten in deze conversatie" — de placeholder "{count}" werd letterlijk getoond i.p.v. vervangen (een foutje uit de grote vertaalronde).

De nieuw aangemaakte taal-demo's (EN/DE/FR) hadden geen eigen logo, waardoor de zijbalk terugviel op het standaard platform-logo in plaats van het bureau-logo dat op de Nederlandse demo is ingesteld.

Elke taal heeft een eigen, volledig vertaalde demo-omgeving. Maar de taal-routing gebeurde alleen op het moment dat je op "Bekijk demo" klikte. Wisselde je daarna van taal terwijl je al in de demo zat, dan kreeg je wel de vertaalde interface maar bleef je op de Nederlandse demo-tenant — dus Nederlandse klanten, afspraken en CRM.

Veel onderdelen van het portaal stonden nog hardcoded in het Nederlands en bleven dus Nederlands voor wie EN/DE/FR had ingesteld — denk aan de tools (bezwaren-bibliotheek, QR-, ROI- en voice-memo-generator, reply-scorer, speedtest, enz.), de CRM- en onboarding-borden, de meetings-instellingen, de e-mail-inbox en diverse beheer- en klantprofiel-schermen.

Wie de demo in het Engels, Duits of Frans bekeek kreeg wel een vertaalde interface, maar de inhoud bleef Nederlands: Nederlandse klantnamen (Bloem & Stijl), een Nederlandse CRM-pipeline, Nederlandse taken, onboarding en mailbox. Een Franse bezoeker zag dus klanten en een CRM die hij niet kon lezen.

Het contract is een wit document, dus het pakte je logo voor lichte achtergrond. Had je alleen het standaard "logo donker" ingesteld (meestal een wit logo voor je donkere sidebar), dan stond er een wit logo op een witte achtergrond — onzichtbaar. De branding-preview in de instellingen oogde daardoor leeg.

In Instellingen → Contracten was de tekst van de primaire knoppen donker (bijna zwart) op de teal/petrol achtergrond, vooral in dark mode nauwelijks leesbaar.

Wie vanuit het portaal in dark mode uitlogde, zag het inlogformulier ~1 seconde in donker en daarna pas naar light verspringen.

In EN/DE/FR bleven diverse onderdelen Nederlands: de tabs Huisstijl/Abonnement en Identiteit/Kleuren/Domein/E-mail, de LinkedIn-tip en sectie "Platformen", de commissie/koppel-velden bij contracten, en de "AI brand-voice"-tab in het bewerk-venster.

In de Contracts-sectie van het klantprofiel duwde de uitlijning het decoratieve streepje, de titel en de knop uit elkaar, waardoor de titel midden in de balk zweefde.

Bij het versturen van een contract vanaf het klantprofiel toonde de voorvertoning alleen de kale inhoud, zonder je logo of accentkleur. Dat kwam niet overeen met de preview in de template-editor en gaf geen volledig beeld van wat de klant zou zien.

Het 64×64 raster-backdrop dat het dashboard zijn premium "blueprint"-uitstraling geeft, was in light mode praktisch onzichtbaar: de lijnen stonden op slechts 2,2% dekking én de content-laag dekte het raster volledig af met een dekkende crème achtergrond. In dark mode was het wél zichtbaar.

Bij het schrijven of bewerken van een contract-template zag je alleen de ruwe Markdown-tekst met {{variabelen}}. Je kon niet controleren hoe het uiteindelijke contract eruit zou zien zonder het eerst op te slaan en naar een echte klant te sturen.

De Launchpad toonde in EN/DE/FR een mix: de chrome (kopteksten, knoppen) was deels vertaald, maar de 35 onboarding-taken (titel, beschrijving, knoptekst, waarde-belofte), de 7 categorie-namen in de linkerkolom en een handvol UI-labels (Aanbevolen/Klaar/Overgeslagen, "Wat is nieuw?", hulp-tekst) stonden hardcoded in het Nederlands.

De ondertekenpagina toonde bovenaan alleen je bureaunaam als tekst — het logo werd wel opgehaald maar nergens getoond. Een contract zag er daardoor minder af en minder "van jou" uit.

De bedrijfsgegevens en de standaard-templates waren hard op de Nederlandse situatie gebouwd: vaste velden "KvK-nummer" en "BTW-nummer". Een buitenlands bureau (bv. een Amerikaans bedrijf) heeft geen KvK of BTW, maar een EIN en Tax ID — en kon dat nergens kwijt zonder dat het contract krom oogde.

De kleine kop-label (eyebrow) en de paginatitel toonden allebei hetzelfde woord "Contracten", waardoor het er dubbel uitzag.

De .calendar-page-container had in dark mode een semi-transparante achtergrond (rgba(255,255,255,0.025)). Daardoor scheen het vaste blueprint-raster van het portaal (.app-shell::before, 64px grid) door het paneel heen — een doubled "vakjes achter vakjes"-effect in en rond de header/agenda. In light mode speelde dit niet, want daar was het paneel al ondoorzichtig (#ffffff).

De taalkeuze zat alleen in een browser-cookie. Dat werkte op hetzelfde apparaat, maar je account "onthield" je taal niet: log je in op je telefoon of een andere browser, dan moest je opnieuw kiezen. En op een gedeelde computer kon de laatste bezoeker-keuze jouw taal overschrijven.

De vandaag-kolom (cel + dagheader) had een semi-transparante teal-achtergrond (rgba). De andere kolommen waren ondoorzichtig, maar door de transparante vandaag-cellen scheen het pagina-achtergrond-raster (80px grid) heen — bovenop de eigen rasterlijnen van de kalender. Daardoor zag je in die ene kolom twee niet-uitgelijnde sets lijnen over elkaar.

Je kon contracten al handmatig sturen, maar niet automatisch bij het aanmaken van een klant — wat je vaak juist wilt aan het begin van een samenwerking.

De useLanguage-hook startte altijd op 'nl' en las de werkelijke taal pas in een useEffect — dus ná de eerste paint. Voor een EN/DE/FR-gebruiker rendeerde elke client-component daardoor één frame in het Nederlands voordat de juiste taal werd toegepast. Extra zichtbaar na een taalwissel, omdat die een volledige reload doet en je dan de hele pagina even in NL zag.

Bureaus moesten contracten buiten Senly opstellen (Word/PDF), los mailen en handmatig bijhouden of een klant had getekend. Geen overzicht, geen audit-trail, losse tools.

Bedrijfsgegevens stonden nergens centraal en moesten in elk contract opnieuw worden getypt.

De systeem-optie testte op (prefers-color-scheme: light) en viel bij twijfel terug op donker — een systeem zonder harde voorkeur werd zo onterecht donker. Ook werd de thema-cookie niet bijgewerkt en schakelde het portaal niet live mee.

De changelog-pagina toonde de titel en knoppen wel in je taal, maar de honderden updates zelf bleven in het Nederlands staan. De vertaling hing af van een cache die via een trage achtergrond-taak werd gevuld en de gedeelde AI-quota telkens uitputte — waardoor het overgrote deel van de updates nooit vertaald raakte.

Affiliates zagen wel hun verdiende commissie per bureau, maar niet hoeveel actieve klanten een verwezen bureau op dat moment heeft — terwijl dat juist de commissie aanstuurt (30% van wat het bureau per klant aan Senly betaalt).

De changelog-titel, subtekst, statistiek-labels en filterknoppen werden eerst kort in het Nederlands getoond en klapten pas ná het laden om naar de gekozen taal. Die korte NL-flits liet de pagina "onvertaald" ogen, en zoekmachines zagen de Nederlandse versie.

Het `lang`-attribuut van de pagina stond altijd hard op "nl", ook als je EN/DE/FR had gekozen. Daardoor bleef de browser "deze pagina vertalen?" aanbieden en oogde de pagina onvertaald, terwijl de inhoud wél in de juiste taal stond. Op de changelog zag je bijvoorbeeld een Duitse titel maar een Nederlandse browser-vertaalprompt.

Oude bezoekers konden meerdere portal_locale-cookies tegelijk hebben (een legacy host-locked "nl" naast de nieuwe cross-subdomain keuze). De client koos daar soms de stale "nl" uit en herschreef de cookie terug naar NL, waardoor een net gekozen taal stilletjes terugviel.

De IP-geolocatie via ipwho.is gaf vanaf de Railway-server een 403 terug met "CORS is not supported on the Free plan" — die service staat server-to-server calls niet toe zonder betaald abonnement. Daardoor bleef de valuta null en viel 'ie terug op browsertaal. (Gediagnosticeerd via een tijdelijke debug-modus die het gedetecteerde IP + de rauwe API-respons toonde — IP-detectie zelf bleek correct.)

Het /api/geo-currency endpoint las het land uit edge-headers (cf-ipcountry e.d.), maar die komen niet door op app.senly.io (niet via Cloudflare geproxied). Resultaat: country was altijd null en de valuta viel terug op browsertaal — een Amerikaan met niet-Engelse browser kreeg euro's.

Het signup-formulier toonde de valuta op basis van browsertaal (EN → USD), maar de Stripe-afschrijving stond hardcoded op EUR. Een Amerikaanse bezoeker zag dollars maar werd in euro's afgeschreven — een mismatch tussen weergave en incasso.

De tariefberekening (lib/pricing) en alle Stripe-flows gingen uit van euro's.

Oude bezoekers konden twee portal_locale cookies hebben: een legacy host-locked (vaak nog "nl") naast de nieuwe cross-subdomain cookie (bv. "fr"). De server pakte er willekeurig één — meestal de oude "nl" — waardoor de changelog in het Nederlands bleef ondanks taalkeuze FR/EN/DE.

De cache-warming pakte alle versie-nummers uit de broncode, inclusief interne (verborgen) entries. Daardoor vielen juist een deel van de ZICHTBARE entries buiten de gewarmde set en bleven die in het Nederlands.

De quiz-banner toonde de juiste taal (bv. "FAST GESCHAFFT" in het Duits) maar het aanmeldformulier eronder bleef Nederlands. Oorzaak: twee gescheiden taalsystemen — de landing/quiz gebruikt de "senly-lang" bron, terwijl het formulier via useLanguage() de "portal_locale" cookie leest die op /signup nog op NL kon staan.

Een klant kon alleen Actief of Inactief zijn. Voor klanten die de dienstverlening even on hold zetten maar binnen enkele maanden terugkomen, was er geen passende status — je moest ze op Inactief zetten, waardoor ze niet meer te onderscheiden waren van echt beëindigde klanten.

Een volledige migratie van het isActive-boolean naar een enum zou 150+ plekken in de code raken — te risicovol.

De eerste opzet vertaalde de changelog client-side ná page-load. Dat bleek onbetrouwbaar: een service-worker serveerde oude bundles, en de fetch-trigger miste door een hydration-timing race regelmatig z'n moment. Resultaat: bezoekers in EN/DE/FR zagen alsnog Nederlands.

De embedded SignupForm in de quiz was 640px breed — voelde te smal en krap op grote schermen.

De affiliate-code in de badge had een witte transparante achtergrond (rgba(255,255,255,0.06)) — relic van het oude donkere thema, dus nagenoeg onzichtbaar op de lichte form-achtergrond. De code "PARTNERS" leek los te zweven.

Twee samenlopende oorzaken. (1) De runtime-translate fetch vuurde niet op natuurlijke page-load door een effect-volgorde race tijdens hydration. (2) Veel hardnekkiger: de service worker (cache senly-v27) serveerde de OUDE JS-bundle, waardoor zelfs na deploy van de fix de gefixte code nooit in de browser laadde — elke test draaide tegen verouderde code.

De Founder-korting was visueel zichtbaar via doorgestreepte prijzen, maar mistte een tijdscomponent — geen reden om NU te beslissen.

De laatste stap van de quiz (het 14-dagen aanmeldformulier) toonde een smalle witte card op een donkere mesh-achtergrond. Dat botste met de lichte quiz-stappen ervoor — het leek een aparte donkere tab midden op het scherm.

Na de v9.08 fix kreeg submitQuizAndAdvance een optionele Attribution-parameter, maar de onClick-handler op de Doorgaan-knop (bij "Anders"-flow) gaf het MouseEvent als argument door — TypeScript klaagde dat MouseEvent geen Attribution is. Railway-build crashte op "Type 'MouseEvent' is not assignable to type 'Attribution'".

In stap 4 (Waar gevonden?) bleef de quiz vast hangen na selectie. submitQuizAndAdvance() las data.attribution uit een stale closure (setData is async), waardoor de guard-clause de submit blokkeerde. Resultaat: bezoeker zit vast, geen signup-form, dropoff op laatste stap voor je conversie.

TikTok-platform-card op stap 3 ("Welke platformen beheer je?") had kleur #ffffff (wit) ingesteld voor donker-thema, maar de quiz heeft een lichte achtergrond. Logo verdween dus volledig in de witte card.

De pagina chrome (header, filters, labels) was vertaald, maar de inhoud van elke release-entry stond hardcoded NL in lib/changelog.ts. Een bureau-eigenaar die op EN/DE/FR het portaal gebruikt, zag de changelog in het Nederlands. Statisch vertalen van 600+ historische releases × 4 talen is ondoenbaar.

De v9.00 quiz had list-style opties met emoji-iconen op de SignupForm light-theme. Voelde inconsistent met de "premium" Higgsfield-feel die als referentie was gegeven. Plus de eerste donker-versie streek niet met de rest van Senly's lichte huisstijl.

De middelste pricing-card had alleen een teal-gradient als achtergrond zonder ondoorzichtige base. Op de marketing-pagina (lichte page-bg) schoof de page door de transparante gradient heen, waardoor de card bijna wit werd terwijl tekst + ondertitels + features op witte styling stonden — onleesbaar.

De grid-lijnen die in v8.94 zijn toegevoegd waren op sommige plekken net te aanwezig en concurreerden met de content-cards.

De "Start 14 dagen gratis" CTA stond altijd in LinkedIn-blauw, ongeacht of je op Instagram, TikTok of Facebook tab stond. Inconsistent met het platform-specifieke karakter van de info-cards.

IG en TT gebruikten een scrape die op productie vaak faalde (Railway IP geblokt), met als fallback een manual-input flow. Niet consistent met LinkedIn/Facebook die direct een info-card toonden. Bezoekers vonden de inconsistentie verwarrend.

TikTok-cijfers (+150-250 volgers/mnd) lijken laag vergeleken met Instagram. Bezoekers vroegen zich af waarom.

De component had ~200 regels dood code voor de scrape-flow, error-states, manual-input fallback, profile-rendering en result-state. Niet meer nodig nu alle 4 platforms statisch zijn.

De Facebook-stat "+200-400 nieuwe page-likes per maand" gaf alleen het eind-resultaat zonder context. Bezoekers vroegen zich af hoe Senly aan die cijfers komt.

Calculator had alleen Instagram, TikTok en LinkedIn. Veel bezoekers vragen ook naar Facebook-groei.

Bezoekers zagen "+19.976 extra volgers in 3 mnd" maar moesten zelf delen door 3 om te begrijpen wat dat per maand betekent. Per-maand is concreter voor de "wat krijg ik elke maand"-vraag.

De LinkedIn-blauwe CTA-knop werd door een generieke .sn-calc-card a-rule overschreven met witte achtergrond. Witte tekst op witte bg = onleesbaar tenzij je met de muis hovert. Conversion-killer.

Instagram blokt alle datacenter-IPs (Railway, Vercel én Cloudflare). De growth calculator viel terug op een nette "schakel over naar TikTok"-melding, maar IG-bezoekers die liever niet wilden switchen liepen alsnog vast zonder resultaat te zien.

Op verschillende publieke pagina's en in support-content stond nog "info@socialmediatools.nl" / "support@socialmediatools.nl" / "noreply@socialmediatools.nl". Inconsistent met de Senly-merknaam.

Bij het kiezen van LinkedIn in de growth calculator kreeg de bezoeker alleen een "binnenkort beschikbaar"-error. Niet ideaal voor conversie: bezoekers zagen direct dat een feature kapot was. LinkedIn heeft sinds 2018 geen publieke endpoint meer zonder OAuth, dus echt scrapen is geen optie zonder login-flow (wat conversie zou killen).

Bij snel verwijderen kwam de melding "0 verwijderen gelukt, 4 mislukt: Thread niet gevonden — mogelijk is de mail inmiddels al verplaatst". Maar als de mail er al niet meer was, is het eind-resultaat (mail weg uit inbox) feitelijk gewoon bereikt — onnodig om er een fout van te maken.

Het naam-veld toonde "Dylan van Dijk" als placeholder, het e-mail-veld "dylan@bureau.nl". Voor bezoekers oogde dat als pre-filled formulier (alsof er al iemand ingevuld stond) en het hint nergens naar wat er verwacht wordt.

Na de vorige fix (batched bulk-move) was de rate-limit weg, maar Gmail's eigen per-seconde quota zorgde dat individuele moves binnen een batch nog "Command failed" kregen. Resultaat: alert met "0 verwijderen gelukt, 1 mislukt".

De image-proxy stond alleen images toe van een whitelist (Metricool, Instagram, Facebook etc.). E-mails van GitHub, Railway, Cloudflare en eigenlijk iedere afzender met images werden geblokkeerd → broken-image-icoontjes in de inbox.

Als je snel achter elkaar de prullenbak op 20-40 mails klikte, sloeg de globale 120-req/min rate-limit aan en kreeg je "Te veel verzoeken". Sommige mails verdwenen wel uit de UI maar werden niet daadwerkelijk verwijderd.

De korte-tijdse avatar-vervang-checkbox is eruit; de inbox ziet er weer hetzelfde uit als daarvoor. Bulk via per-mail prullenbak-klik is met de queue snel genoeg dat aparte multi-select-UI niet nodig is.

De checkbox stond als extra kolom voor de avatar, wat de grid-layout van de thread-row brak: rijen kregen verschillende breedtes, geselecteerde rijen leken groter. Plus de "Verplaats naar prullenbak"-knop in de bulk-bar was zo lang dat de tekst over drie regels brak en de hele bar uitelkaar trok.

Na v8.64 was de wiskunde rondom de data al optimaal, maar React rendert standaard nog steeds het hele component-subtree bij elke state-wijziging. Concreet: 1 toetsaanslag in de zoekbalk triggerde een herrender van alle 12 maand-tabs, alle 8 categorie-tabs en alle 132 dag-kaarten (ook al was alleen de filter-output veranderd). Bij het uit/open klikken van 1 kaart herrenderden alle 132.

20 mails snel achter elkaar verwijderen liep tegen de globale 120-req/min rate-limit aan ("Te veel verzoeken"). En zelfs zonder rate-limit was elke mail per stuk klikken simpelweg te traag. Outlook en Gmail hebben dit al jaren.

Iedere thread-move was een aparte HTTP-call die door de middleware rate-limit ging. Bij 20+ acties tegelijk = direct 429.

De pagina had drie cumulerende issues: (1) "kapotte" memoization — `now = new Date()` binnen de render maakte elke render een nieuwe Date-instance, waardoor de useMemo dependency steeds verschilde en ALL_DAYS bij iedere render opnieuw werd geconcat + gesorteerd; (2) de maand-tab-bar deed bij elke render 12 × 132 = 1584 iteraties omdat de count per maand telkens via .filter().length werd berekend; (3) de page was force-dynamic en deed bij elke request een redundante getServerSession() DB-call ondanks dat alle data statisch is en de middleware de auth al doet.

De smooth-scroll werkte met een vooraf berekende targetY (genomen op klik-moment) en interpoleerde daar lineair naartoe. Maar tijdens de animatie kan de layout boven de doelsectie verschuiven: door de Framer Motion expand van CollapsibleSections, asynchrone re-renders, of resize-observers. Het resultaat: de scroll eindigde op een verouderde Y en kwam een aantal pixels (soms 50-150) tekort.

De scroll-spy werd gelockt voor 800ms na een tab-klik, om te voorkomen dat tussenliggende secties als actief gemarkeerd werden. Maar de smooth-scroll + CollapsibleSection expand-animatie kan langer dan 800ms duren — dan keek de spy halverwege "Content" als laatste-gepasseerde sectie en zette de pill daar, tot de scroll z'n doel bereikte en de pill weer naar Klantinfo schoot. Zichtbaar als een knipper.

De vorige fix paste alleen de base .client-tabs regel aan, maar twee verderop in globals.css stonden overrides die mijn padding terug op een waarde >0 zetten: een mobile mediaquery (padding: 8px 4px !important) en een .client-profile-container variant (padding: 6px !important). Die laatste is exact de selector die op de klant-detailpagina actief is — dus die override won altijd.

De .client-tabs container had padding: 5px en de pill een kleinere border-radius (16px vs bar 20px). Het resultaat: een dubbele "indent" — de pill leek alsof er bewust ruimte omheen was gelaten, wat onbedoeld een lossere relatie tussen pill en bar gaf.

De Maak klantmap-knop was teal tekst op een lichte teal-tint achtergrond — dat werkt in dark mode maar wast volledig weg in light mode. Op witte cards bijna onleesbaar.

Stel je klantprofiel staat per ongeluk gekoppeld aan een te brede map (bv. de hele "Klanten"-folder met daarin alle bureau-klanten). Dan zag je in de Drive-sectie alle andere klanten als submappen staan. Er was geen snelle manier om vanuit die weergave te zeggen: "deze ene submap is de echte klantmap van dit klantprofiel".

Na Drive-koppeling stond de root op je hele Drive ("Mijn Drive"). Daardoor scanden auto-koppeling en de folder-picker ALLE top-level mappen — inclusief vakantiefoto's, Inbox, etc. Bij een klant als "Noes Fiolet Studio's" zocht Senly tussen al die top-levels, vond geen match, en je moest manueel per klant doorklikken.

De folder-picker bij Klant > Content > Google Drive toonde alleen de top-level mappen in je Drive — geen manier om in een map "Klanten" of "Studio X" te kijken om de juiste submap te koppelen. Niet bruikbaar bij geneste structuren.

Bij de eerste versie van de bureau-eigen Drive-koppeling vroeg Senly alleen de `drive.file` scope: toegang tot files die Senly zelf had aangemaakt. Resultaat: bureau's zagen na koppelen een lege "Senly Klanten"-folder en moesten al hun bestaande klantmappen handmatig verslepen. Onbruikbaar.

Google OAuth eist een statische redirect-URI whitelist. Als bureau X z'n portaal whitelabelt naar app.bureauX.nl, zou de Drive-callback ook daar moeten landen — maar die URL staat niet in onze Google OAuth-client. Resultaat: redirect_uri_mismatch error. Per bureau handmatig whitelisten schaalt niet.

Tenant krijgt een optioneel customDomain veld (unieke whitelabel-host). OAuthSession krijgt een returnUrl-veld voor de canonical-redirect flow. Dezelfde aanpak werkt straks voor Microsoft/OneDrive, Canva, GHL en elke andere OAuth-integratie — moet alleen per provider geretrofit worden.

In het e-mail-overzicht zag je wel je gekoppelde mailboxen, maar je kon niet filteren om alleen de mails van één specifieke inbox te zien.

Tot nu toe liep alle Drive-opslag via één centraal service account (mijn Drive). Klantbestanden van alle bureau's zaten in mijn account, en als het service account onderuit ging — zoals vanmiddag — viel ALLE Drive-toegang in één klap weg voor iedereen.

Een full drive-scope geeft toegang tot ALLES in iemand's Google Drive — vakantiefoto's, belastingaangiftes, alles. Voor een SaaS-integratie veel te ruim.

Schema: 1 koppeling per tenant (uniek), met accessToken/refreshToken/expiresAt/googleEmail/rootFolderId. Routes: /api/integrations/gdrive/{connect,callback,disconnect,status}. lib/gdrive.ts heeft nu een getDriveContext(tenantId) resolver die transparant kiest tussen tenant-OAuth en central service account — bestaande callers blijven werken zonder aanpassing.

De Terug-knop, titel en Download-knop in de viewer-topbar waren bijna onzichtbaar. De viewer zat onder de dashboard-header (Header + AppSidebar) en de gebruikte CSS-variabelen resolveden anders in light mode dan verwacht.

PDF-rapporten openden in een verse tab zonder geschiedenis, dus de browser-terugknop deed niets. Je moest m sluiten en de klantpagina opnieuw zoeken.

Doorheen een 30-pagina rapport scrollen voelde alsof Chrome elke pagina opnieuw moest downloaden. Klopte ook: de download-API leverde de hele PDF in een blok met no-store, dus geen progressive rendering mogelijk.

Na het uploaden van een analyserapport bij een evaluatiegesprek gaf de download-link een 404. Next.js production-server bouwt de static-files index bij startup; PDFs die na de build naar /uploads/evaluations werden geschreven werden niet langer geserveerd, zelfs niet met het Railway-volume gemount op /app/public/uploads.

Het oude pad /uploads/evaluations/eval-<clientId>-... was raadbaar — iedereen die de URL kende kon de PDF binnenhalen, ook zonder login.

De knop linkte naar /helpdesk, maar die route bestaat niet — klikken leidde nergens heen (404 of stille no-op).

Ook na verhuizing van PKCE-state naar DB (v8.20) bleef het koppelen falen, omdat we nog steeds een session_id-cookie nodig hadden om de DB-row te kunnen vinden. Bij cross-site OAuth-redirects worden zelfs kleine SameSite=Lax cookies door incognito en Chrome strict tracking blocking soms niet doorgestuurd. Bureaus die voor het eerst willen koppelen liepen hierop vast.

Bij het koppelen van een Canva-account zetten we PKCE code_verifier + CSRF state in HTTP-only cookies. Bij de redirect terug van Canva naar Senly werden die SameSite=Lax cookies door sommige browsers (incognito, Chrome met strict tracking-blocking) niet teruggestuurd → koppeling faalt. Symptomen: rode banner "verifier_ontbreekt" of "state_mismatch", terwijl alles aan onze kant correct was. Nieuwe bureaus konden hierdoor geen verbinding maken.

padding-top berekend als container-top (80px) + eyebrow-hoogte (12px) + eyebrow-margin (18px) + sa-title-row-margin (2px) zodat de h1 op dezelfde verticale positie staat.

20px extra horizontale padding toegevoegd aan lp-root zodat de afstand tot de zijbalk overeenkomt met pagina's die een .container wrapper gebruiken.

justify-content: center verwijderd van lp-root zodat de titel op dezelfde verticale hoogte staat als Takenbeheer en andere pagina's.

Titel gebruikt nu th2-title + sa-title-row, info-icoontje en popover zijn de gedeelde InfoPopover-component. Popover verschijnt altijd op de voorgrond via een hogere z-index op de titel-sectie.

Bij overdracht tussen social media managers ging persoonlijke kennis over de klant verloren — hoe iemand communiceert, voorkeuren, gevoeligheden. De bestaande "Notities & wensen" sectie is bedoeld voor schrijfinstructies aan de AI, niet voor het overdragen van mens-kennis.

Boven de voortgangsbalk staat nu "Launchpad" als paginatitel. Het info-icoontje ernaast opent een popover met uitleg over het doel van de Launchpad.

Onder Klantinfo verscheen voor elke klant de "Documenten"-sectie met een rode foutmelding "Geen lokale map gevonden voor X. Controleer BEDRIJVEN_FOLDER_PATH." De feature werkt alleen als de server-env var BEDRIJVEN_FOLDER_PATH is gezet en er een persistent volume aan dat pad gemount is — op productie zonder die setup heeft de sectie geen nut en geeft ze alleen visuele ruis.

Modal-titel had font-weight: 800 (extra bold) — voelde te zwaar voor een lichte glas-card.

Bij het aanmaken van een nieuwe onboarding-entry moest je alle contactgegevens (naam, bedrijf, email, telefoon) opnieuw intypen, zelfs als het contact al bekend was in het CRM. Duplicaat-werk + foutgevoelig (typo's, ontbrekende velden).

v8.06 fixte de data-fetch dubbel-load (server-side data), maar gebruiker zag de cards nog steeds twee keer komen. Oorzaak: .tx-rec-card had een fade-in animation van 0.6s met per-card stagger van 0.05s tot 0.45s. Voor 6 cards is dat een ~1 seconde wave per rij. Met twee rijen ("Recent gebruikt" + "Aanbevolen voor jou") tegelijk werd dat visueel ervaren als "dubbel laden". Plus tijdens hydration herstart de CSS animation, wat de flash versterkte.

In het Financieel-tabblad van het klantprofiel hadden de "Kies…"-dropdowns (Appointmentsetter / Closer / Sales Manager) een donkergrijze achtergrond in light mode — paste niet bij de witte cards eromheen.

ToolsIndex initialiseerde personal state met FEATURED_SLUGS-fallback (7 cards), daarna fetch /api/tools/personal in useEffect → setPersonal → re-render met DB-data. Resultaat: gebruiker zag de tool-cards twee keer achter elkaar laden (eerst fallback, dan API-data).

Bij het openen van een boekingslink (en de manage-link voor annuleren/verzetten) zag je ~1 sec ongestyled "Laden…" linksboven verschijnen voordat de echte pagina inviel. Oorzaak: de styles stonden in `style jsx global` die pas NA hydration actief wordt — voor die periode kreeg de browser dus puur HTML zonder CSS.

.user-card had grid-template-columns: 44px 1fr auto (3 kolommen), maar v7.98 voegde een vierde child toe (sessies-knop) naast de bestaande pijl. CSS Grid plaatste het 4e element (pijl) automatisch op row 2 col 1 — onder de avatar. Resultaat: elke card 28px hoger dan nodig.

Op het appointment-setters dashboard verscheen de "Mijn compensatie"-widget in dark mode als een groot WIT blok waardoor tekst (flat fee, commissie, totaal, tabel) niet leesbaar was. In light mode werkte het wel.

Op /admin/users zag je maar 3-4 user-cards per scherm. Veel verticale ruimte tussen elementen, grote avatar, dikke padding.

Na v7.95+v7.97 was de credentials-infrastructuur (secret-vault + Tenant-velden + UI) klaar, maar alle 13 aanroepende routes gebruikten nog de oude sync authHeaders/userId helpers die alleen env vars lezen. Een bureau dat via /admin/integraties/content-kalender z'n eigen Metricool-token instelde, zag nog steeds platform-quota gebruikt worden bij sync/post/analytics/calendar/canva-send/ai-content/ai-post-image/feed-style/monthly-report/calendar-aggregate/review.

Geen manier om te zien wie waar ingelogd is of om een gecompromitteerde sessie te beëindigen. Een admin die ontdekt dat een ex-medewerker nog ingelogd is, kon alleen het wachtwoord wijzigen en hopen dat de JWT verloopt.

2FA-data zat al in de DB (User.mfaEnabled + mfaSecret) maar werd nergens in admin/users getoond. Admin kon niet snel zien welke users 2FA hadden ingesteld.

Volledige IP-adressen opslaan = privacy-overweging onder AVG/GDPR. Vereist rechtvaardigingsgrond en kort bewaartermijn.

Per-tenant Metricool-credentials konden alleen via API (PATCH /api/integrations/metricool/credentials) ingesteld worden — geen UI. Bureaus moesten dus DevTools openen of een aparte client gebruiken om hun eigen token in te voeren.

De activiteiten-pagina haalde altijd 100 items op en filterde client-side. Bij grote tenants betekende dat: zodra je meer dan 100 events had, miste je de oudere — geen enkele zoekopdracht of filter kon erbij komen. Search en type-filter beperkten zich tot het 100-venster.

In dark mode verscheen een gloeiende cyaan→blauw→paars→rood gradient-line boven de Content sectie op klantprofiel. Alleen zichtbaar zonder taken (toevallig — de scroll-positie maakte het opvallend). Oorzaak: .platforms-card had alleen in light mode position: relative + overflow: hidden. In dark mode misten beide. De ::before (4px platform-accent strip met linear-gradient TikTok #25F4EE→#FE2C55, Instagram orange→pink→purple, etc.) en ::after (30px blur-glow) hebben position: absolute + top: 0; left: 0; right: 0. Zonder positioned ancestor zochten ze de dichtstbijzijnde — vaak meerdere niveaus hoger. 8 platforms-cards stapelden zo hun gradient-bars op TOP van de hele Content section → multi-color gloeiende horizontale lijn.

Tijdens de zoektocht naar de bron heb ik 5 diagnose-blokken in globals.css toegevoegd (v7.79: knop verbergen, v7.81: hele Content verbergen, v7.82: collapsible-stack + platforms + spacer, v7.85: alleen collapsible-stack, v7.90: alleen platforms-strip).

v7.85 wees uit dat de 4 CollapsibleSection cards NIET de bron zijn. Bron is dus de platforms-strip (Platformen-blok met platform-cards) of de spacer-div met margin-top: 72px.

Elke nieuwe pipeline kreeg automatisch dezelfde 17 hardcoded stages (Lead binnen → Gekwalificeerd → Gebeld → ... → Inactieve klant). Voor solo-bureaus of korte sales-cycli was dat overweldigend en moest je handmatig 10+ kolommen wegklikken om iets bruikbaars over te houden. Modal was bovendien een platte naam-input zonder enige indicatie van wat je kreeg.

De "Alle diensten"-dropdown stond altijd in de toolbar — ook bij flows met 0 contacten, mono-dienst flows (alles SM Beheer), of bureaus die per dienst al een aparte flow hebben (waardoor filteren binnen die flow zinloos was). Plus toonde de dropdown alle 9 SERVICE_TYPES opties terwijl er bijvoorbeeld alleen "SM Coaching" en "SM Beheer" in de flow voorkwamen — visueel cluttered.

Voor stappen zonder DB-detectie was de enige manier om ze van de actieve lijst te krijgen "Sla over" — wat ze visueel als "Overgeslagen" markeerde, ook als je de actie wel had uitgevoerd. Voelde niet eerlijk.

Backend had al een DELETE /api/onboarding/flows/[id]-endpoint, maar er was geen UI-knop om een flow te verwijderen. Gebruikers konden onbedoeld duplicaten of testflows niet kwijtraken.

v7.84 bevestigde dat een van drie elementen (cp-collapsible-stack / platforms-strip / spacer-div) de bron is. Nu testen we welke specifiek.

v7.81 test was succesvol: hele Content sectie verbergen liet de gradient-line verdwijnen. Bron is dus binnen Content. Maar binnen Content zitten 4 dingen: header-row (titel + knop), cp-collapsible-stack (4 cards), platforms strip, en een lege spacer-div.

De "Nieuwe flow"-modal had een platte <select>-dropdown waarin je een template kon kiezen — niet inzichtelijk wat je kreeg en gebruikers wisten niet welke template bij hun proces paste. Plus de modal was 440px breed met alleen een naam-input + dropdown, voelde meer aan als databank-formulier dan als productverkenning.

De launchpad miste een universele eerste stap die direct uitlegt hoe je het portaal het comfortabelst gebruikt.

Basisinstellingen kreeg: taal kiezen, notificaties instellen, dark mode proberen, valuta instellen (admin), eigen domein koppelen (admin). Klanten & werk kreeg: eerste taak aanmaken, eerste maandrapport versturen (beide bureau). Meetings & boeken kreeg: video-meeting app koppelen, booking-emails personaliseren. E-mail kreeg: email-handtekening instellen. Tools & integraties kreeg: cloud-opslag koppelen (admin). Sales-flow kreeg: lead-bronnen configureren (sales manager), eerste outreach-template (sales). Per rol zie je nu een veel completer onboarding-pad.

v7.79 verborg de Deel review-link knop in dark mode op klantprofiel om te testen of die de bron was van de gradient-line. Gebruiker meldt dat de lijn er nog is — knop is dus niet de bron.

De pseudo-element neutralisatie (v7.71) en de tweede shotgun-pass met overflow:clip + box-shadow weghalen (v7.76) hadden geen effect op de gloeiende gradient-line. Beter terugdraaien om de codebase schoon te houden.

Gebruiker vermoedt dat de Deel review-link knop de bron is van de gradient-line. Om dit te valideren zonder live DOM-inspectie nodig te hebben, verbergen we de knop tijdelijk in dark mode op klantprofiel.

De Onboarding-pagina had "ONBOARDING" als kleine eyebrow boven een grote "Flows"-titel. Gebruiker vond de hiërarchie logischer omgekeerd: het primaire onderwerp van de pagina is Onboarding, en Flows is de feature-naam — die hoort als label boven de titel.

v7.75 gebruikte een color-mix(accent 14% + diep donker) — leek wel groen maar matchde niet exact de meetings-kalender. Die ziet er groener uit door twee gestapelde lagen: var(--bg-elev) als solid basis + de .app-shell-main accent-radials (19/13/14% teal) die door transparante cellen heen schemeren.

v7.71 schakelde pseudo-elements uit op cp-section-header-row / client-section / cp-collapsible-stack — maar de lijn bleef. Gebruiker meldt dat de lijn alleen verschijnt wanneer Taken via EmptyState gerendered wordt (zonder taken). Kandidaten: empty-state-icon box-shadow glow, Deel review-link knop, overhangende shadow uit een sectie.

v7.74 gebruikte var(--bg-elev) (#161a21 = neutraal grijs) voor het gebied vanaf de filter-balk. Dat voelde te neutraal — geen relatie met de huisstijl.

v7.73 maakte de hele /changelog uniform bg-elev waardoor de hero ook plat werd — de portal-gradient die overal in dark mode te zien is verdween. Bedoeling was dat alleen ván de filter-balk t/m de releases die uniforme groen-zwarte kleur kreeg, en de hero erboven de gewone portal-sfeer behield.

De /changelog-pagina had in dark mode een stack van 6 radial-gradients als achtergrond (overgenomen van de portal-body). Daardoor waren er zichtbare lichtere/donkere zones tussen de hero, filter-balk en releases — onrustig.

In dark mode verscheen een gloeiende horizontale gradient-line (teal/cyaan → blauw → paars → rood) vlak boven de Content sectie op de klantprofiel-pagina. De exacte bron-selector was via grep niet te identificeren — kandidaten waren ::before/::after op cp-section-header-row, section[data-tour="klant-designs"], of cp-collapsible-stack.

v7.69 ving de auto-refresh op, maar bij een verse pagina-load (zonder cache) verspringde het scherm nog steeds naar een "Laden..."-tekst voordat het grid verscheen. Onrustig en onnodig.

Elke 90 sec (en bij tab-focus / op de refresh-knop) verving het hele kalender-grid voor een "Laden..."-tekst, ook al stond er al data. Het scherm verspringde dus regelmatig, wat onrustig oogt en je positie/zicht onderbreekt.

Wanneer een klantprofiel zowel een persoonlijke LinkedIn (/in/<naam>) als een zakelijke bedrijfspagina (/company/<id>) gekoppeld had, was er geen visueel onderscheid tussen de twee cards — beide toonden hetzelfde LinkedIn-logo. Plus: de twee accounts konden door de account-volgorde in de DB ergens in de platformen-rij verspreid staan, niet altijd naast elkaar.

Op de klantprofiel-pagina toonde de Instagram-card een actieve "AI-profielcheck"- + "Bekijk laatste"-knop, óók wanneer de extensie nog niet ingelogd was. Andere platforms (LinkedIn, TikTok) verbergen hun acties terecht zolang er geen sessie is — Instagram week af. Klikken op de knop in niet-ingelogde staat liep linea recta in een scraper-fout omdat het profiel niet bereikbaar is zonder cookie.

.cl-filters-wrap had in dark mode background: rgba(11, 14, 20, 0.85) — een ondoorzichtige donkere balk die over de portaal-radial-gradient lag. Daardoor was de zone met de filter-pills duidelijk donkerder dan de rest van de pagina (zichtbare horizontale "band" tussen hero en releases).

De rij rendert eerst met defaultSuggested (fallback), dan herrendert met API-data. Bij die wissel hield de track soms een non-zero scrollLeft vast — je zag dan de eerste card links half afgesneden i.p.v. vol vanaf de rand.

Gmail throttled bij rapid-fire deletes. Het frontend deed één request en toonde direct een alert bij elke transient error — dus elke 3e-5e delete kreeg "Kon thread niet verwijderen: Command failed".

De Exporteren-knop op /trends had een lege placeholder-handler (onClick={() => { /* placeholder */ }}). Click → geen download, geen feedback.

/changelog had in dark mode een eigen radial-gradient-stack met paars-accent en hardcoded #070a0f/#0b0e14 basis. Voelde subtle "anders" dan de portaal-pagina ernaast — niet als één geheel.

/api/tools/personal filterde recent-gebruikte tools uit FALLBACK_SUGGESTED (7 items). Als 2+ tools al "recent" waren, bleven er 5 over — niet genoeg om de 6-kolommen rij te vullen. De fallback-check triggerde alleen bij <4 items.

.rv-share-trigger-btn had background: var(--card, #fff) en color: var(--text, #1a2332). --card was nergens gedefinieerd, dus de knop viel terug op #fff en #1a2332 — witte knop met donkere tekst op een donkere pagina-achtergrond.

.ml-app had margin: 20px 0 24px met height: calc(100vh - 160px). Bij een ~70px topbar gaf dat 20px ruimte boven maar ~46px gat onder de shell — visueel scheef.

De klant-detail pagina (/klant/[slug]) erfde de standaard .container max-width van 1320px. Op brede schermen voelde dat krap — vooral de brand-kit kleur-cards en het overzicht-blok hadden veel ongebruikte witruimte links en rechts.

v7.57 ging te ver: naast de echte oorzaak (saturate(150%) op alle <header> elementen) had ik ook .app-shell-main solid donker gemaakt + z-index:1. Daardoor verdween de subtiele teal branding-glow op het dashboard volledig — alles werd platvloers donker.

Door HEEL het portaal verschenen in dark mode lichtere/blauwige rechthoekige patches achter cards en boven section-titels. Bug bestond letterlijk sinds dag 1 (eerste 40 uur van het project). Eerdere pogingen om body-radials of .app-shell-main-accent te verzwakken hielpen niet omdat de daadwerkelijke oorzaak op TWEE plekken zat tegelijk.

In de takentabel zag je bij "Verantwoordelijke" een rondje met de eerste letter van de naam — niet de echte foto. Voelde minder persoonlijk en minder herkenbaar dan bv. de meetings-pagina waar avatars wel verschijnen.

De Takenbeheer-pagina toonde alleen de takenlijst (eventueel als Kanban). Er was geen high-level overzicht of dag-gericht kalender-zicht — terwijl admins juist zoiets gevraagd hebben.

.th2-chip filter-knoppen hadden in light mode een transparante achtergrond met dunne border — voelde plat en goedkoop vergeleken met de KPI-cards rechtsboven die wel duidelijke witte rechthoekjes zijn.

Mijn v7.54 zette padding-top op 16px in een vroeg blok, maar later in globals.css stond een tweede .container.financieel-container regel met padding-top: 64px !important die door CSS-cascade later won (gelijke specificiteit, latere wint). Resultaat: Statistieken op 16px, Financieel op 64px — nog steeds inconsistent.

Net zoals Statistieken in v7.52 — de Financieel-pagina erfde 80px top-padding van de default .container, tabs begonnen pas halverwege de viewport.

.meet-week-slot border was color-mix(in srgb, var(--border) 70%, transparent). In light mode is var(--border) al rgba(12, 36, 34, 0.09) — 9% opacity. De 70%-mix bracht dat naar ~6% effectieve opacity, onder de drempel waar browsers een 1px-border betrouwbaar renderen. Bij scroll, zoom of subpixel-shift verdween een deel van de uurlijnen waardoor je ze "soms wel, soms niet" zag en moest refreshen om ze terug te krijgen.

.container.home-container erfde de default .container padding-top van 80px. Resultaat: een grote witruimte tussen de top header-bar en de eerste tabs (Health check / Klanten / Team / Systeem). Voelde onnatuurlijk leeg vergeleken met Meetings.

.ml-reader::before tekende twee radial-gradients (paars rechtsboven, teal linksonder) bedoeld als premium "glow", maar in light mode op een witte ondergrond zag dat eruit als een lichtgrijze / mauve tint i.p.v. pure wit — niet wat de gebruiker verwachtte naast de witte sidebar en threadslijst.

.ml-reader had background: var(--mlnx-bg) — in light mode is dat #f7f8fa (off-white), een tintje donkerder dan body's #ffffff. Daardoor zag het reader-paneel er grijs uit naast de witte sidebar en threadslijst.

In light mode trok de "Zoek campagnes..."-input een opvallende grijze omlijning op de pagina — terwijl de KPI-cards ernaast veel subtieler oogen door hun box-shadow.

De pravatar.cc-portretten waren artistiek/casual (man met lang haar, vrouw met sjaal, persoon met zonnebril) — past niet bij de "Plan een demo met ons team"-context.

De gridlijnen waren op 60% (uren) / 30% (slots) van --border opacity gezet. In sommige browsers + sommige scroll-posities renderde de subpixel-anti-aliasing dit zo subtiel dat de lijnen visueel "wegvielen" (glitching look). Plus ze waren überhaupt te zacht om als duidelijke structuur te dienen.

Gebruiker wilde de widget-shell iets meer transparant zodat de portal-bg duidelijker doorschijnt en de cards minder "vast" op de bg liggen.

De drie kleur-bolletjes met initialen zijn vervangen door <img>-tags die portretten ophalen van i.pravatar.cc (open-license stock). Drie vaste indices die typisch Noord-Europees ogen. Alt-tekst bevat Nederlandse demo-namen voor accessibility. De "+8"-badge blijft staan voor het idee van een groter team.

Na v7.43 (frosted-glass !important rule weg) viel .taskio-card terug op var(--bg-elev) (vlak #161a21). Gebruiker wilde echter precies dezelfde look als de Kalender-shell ("Bekijk agenda van — Social Media Tools"), met subtiele wit-glas laag die de portal-bg laat doorshijnen.

v7.40 zette .taskio-card op var(--bg-elev) maar de blauwerige tint bleef zichtbaar. Reden: op regel 59166 stond een verborgen @media (min-width: 900px) override met `background: rgba(16, 21, 30, 0.55) !important; backdrop-filter: blur(24px) saturate(145%);` die alle vorige fixes met !important overruled. De rgba(16, 21, 30) heeft B=30 > R=16 (duidelijk blauwerig) en de 55% opacity + saturate(145%) liet de portal accent-glow ook nog versterkt doorshijnen.

background: transparent vervangen door de radial-gradient-stack van v7.21/v7.26/v7.31. De teal-wash is weer zichtbaar in de e-mail-shell. Border 0 en box-shadow none blijven (was uit v7.31). Kolom-hairlines uit v7.34 blijven ook intact.

Een oude .lp-help { text-align: center }-regel uit globals.css (resterend van de login-pagina) lekte mee naar het Launchpad-card en gaf "Ons team staat klaar..." een ongewenste centrering.

Met background: transparent uit v7.37 schenen de teal radial-gradients uit .app-shell-main (3 ellipsen op 13-19% opacity in var(--teal)) door de widgets heen. De gebruiker zag dat als een "blauwerige" tint binnen elke widget — niet wenselijk.

De Launchpad-content stond bovenaan met een grote zwarte/witte plek onder de laatste taak. Op een normaal scherm voelde de pagina onaf doordat de blokken niet de viewport vulden.

De radial-gradient(75% 70% at 0% 0%, bg-tint-strong) gaf een sterke teal-hotspot links-boven op de e-mail-shell, waardoor het deel rond "Postvak IN" eruitzag als een aparte groen-getinte vak terwijl de rest donkerder bleef.

De buitenste widget-shell .taskio-card had nog een inset highlight rgba(255, 255, 255, 0.04) + drop-shadow die samen een vlak-illusie gaven, terwijl de gebruiker een volledig transparante container wilde. Wel moeten sub-elementen (deadline-vakjes met gekleurde glow, quick-action items met var(--bg-mid)) hun eigen achtergrondkleur behouden.

Donut iets vergroot (130×75 i.p.v. 110×62), cijfer iets compacter (16 px i.p.v. 18 px) en verder van de bodem gepositioneerd (8 px i.p.v. 4 px). Status-card kolom navenant verbreed naar 130 px zodat de donut past.

Zelfs de subtiele rgba(255, 255, 255, 0.025) glas-laag uit v7.33 voelde nog te aanwezig op de donkere portal-bg. Gebruiker wilde de achtergrondkleur er helemaal uit.

De kolom-scheidingslijnen waren een solide donker grijs-blauw (#262c34 = --mlnx-border) die zichtbaar als donkere verticale lijnen tussen sidebar/thread-lijst/reader zichtbaar waren. Visueel deed het lijken alsof de middelste kolom een andere achtergrond had.

De dashboard widgets waren in dark mode bijna pikzwart door een 4-laagse radial-gradient (var(--bg-tint-strong) + var(--bg-tint) + var(--bg-tint-soft) op var(--bg-elev)). Resultaat: vrijwel onzichtbare cards op de donkere portal-bg. De Kalender-pagina ("Bekijk agenda van — Social Media Tools") had daarentegen een veel lichtere, transparant-witte glas-laag die mooi door de portal-bg heen scheen.

Sinds de hero op align-items: start stond, was de status-card rechts (met halve donut) langer dan de voortgangsbalk links — onevenwichtig.

De .ml-app shell had box-shadow: 0 8px 24px -12px rgba(0,0,0,0.5) en border: 1px solid rgba(255,255,255,0.06) — gaf zichtbare donkere randen aan elke kant van de e-mail-sectie, alsof het paneel naar voren werd geduwd.

.ml-threads-search wrapper had background rgba(255,255,255,0.04) + border #262c34. Resultaat: zwarte rechthoek-look bovenop de teal-glas shell.

Na het verwijderen van de raket-illustratie bleef de hero-grid in 3 kolommen (1fr 280px 280px) staan — daardoor zat er een leeg gat tussen de voortgangsbalk en de "Waar sta je nu?"-card. Plus de progress-wrap werd via margin-top: auto naar de onderkant van een uitgerekte hero-kolom geduwd, waardoor er witruimte boven het blok ontstond.

De raket-SVG in de hero, de "Snel aan de slag"-quick-list (Bekijk onboarding video / Download mobile app / Helpdesk-link) in de rechter sidebar, en de "Pro tip"-card met "Meer tips bekijken"-knop zijn weg. Hero is nu compacter; rechter sidebar bevat alleen nog "Hulp nodig?" en "Wat is nieuw?".

De "Launchpad"-titel met info-icoon en de regel "Jouw persoonlijke setup voor een succesvolle start" zijn weg. De hero begint nu direct met de voortgangsbalk; categorieën verschijnen meteen daaronder.

Commit 20d9aaf draaide v7.21 terug: de drie radial-gradients (bg-tint-strong/tint/soft) op var(--bg-elev) basis die de e-mail-shell zijn karakteristieke donker-teal wash gaven, werden verwijderd. E-mail dark mode oogde daardoor te plat en zonder die premium glas-look die op Meetings wel zichtbaar is.

De Launchpad had padding: 80px 20px 120px en max-width: 1320px met centrering — dat gaf veel witruimte aan de bovenkant en links/rechts. De Meetings-pagina staat juist edge-tot-edge tegen de header en zijkant.

De .ml-app radial-tint-laag die in v7.21 werd toegevoegd om de Meetings-look te imiteren is verwijderd. Dark mode keert terug naar de configuratie van v7.17: panels transparent, body-gradient schemerend, geen extra teal-wash binnen een afgeronde shell.

De Launchpad was een 2-koloms layout met alleen categorieën + takenlijst. Geen visueel anker, geen contextuele hulp, geen onboarding-cues. De pagina voelde leeg en functioneel ipv premium.

v7.20 (wit-alpha overlay) voelde anders aan dan de E-mail-pagina die een specifieke radial-gradient teal-tinted shell heeft.

In dark mode had de e-mail-shell een nauwelijks zichtbare teal-tint (rgba 0.05). De gebruiker wilde de duidelijke donker-groene tint die op /meetings zichtbaar is — die komt daar van de body-radials maar werd op de e-mail-pagina niet doorgegeven.

v7.19 had subtiele teal-tint (3.5% -> 0.8%) wat het oog zag als te donker en niet light genoeg. Gebruiker wilde de transparante achtergrond veel lichter.

v7.16 had nog rgba(11,14,20,0.6) als solid base onder de teal-tint, waardoor de widgets nog steeds donker en relatief opaque oogden.

In dark mode liepen de drie e-mail-kolommen wel netjes door in de body, maar er was geen visuele card-omsluiting met ronde hoeken zoals op /meetings — daar staat het kalender-grid duidelijk in een teal-getinte wrapper met afgeronde hoeken.

In de vorige fix kregen alle drie de e-mail-kolommen een effen achtergrond (#070a0f). Dat dekte de body-gradient af — geen teal/violet tinten meer zichtbaar door de e-mail-pagina heen. Op andere pagina's zoals Meetings komt die wash juist wél door.

v7.15 gebruikte rgba(255,255,255) overlays wat een neutraal-wit washed-out gevoel gaf. Past niet bij de brand-stijl van het portaal — de Content-kalender heeft een veel meer teal-getinte donkere achtergrond.

In dark mode hadden de dashboard-widgets een vrij solid donkere achtergrond (var(--bg-elev)) terwijl elders op de site (zoals de Content-kalender) een glasachtige transparante stijl zit waardoor de body-gradient subtiel doorschijnt. Inconsistente diepte-look.

De vorige fix maakte de e-mail-reader gelijk aan body, maar de sidebar en threadslijst (--mlnx-panel) waren nog #11161e — een tintje lichter dan body. Daardoor was de overgang van body naar die kolommen alsnog zichtbaar.

.meet-settings layout had geen horizontale padding, waardoor de zijbalk plat tegen de linkerrand plakte zonder ronde hoeken aan top-left en bottom-left. Inconsistent met de Kalender-tab die wel 20px padding heeft en card-styling op zijn elementen.

Na v7.09 (portal-page-bg paarse aura's naar accent) bleef er een paars-roze gloed rechtsonder zichtbaar in dark mode op alle dashboard-pagina's (Launchpad, etc.). Bron: .app-shell-main op regel 59134 had een hardcoded rgba(139, 92, 246, 0.18) ellipse op positie 82% 82% — precies waar de chat-widget zit. Lichtmode-variant op regel 59144 had rgba(139, 92, 246, 0.04). Beide overleefden de v7.09-pass omdat ze in een andere selector dan tbv-page--portal zaten.

Bij tab-switch terug naar Meetings kwamen de linker en rechter zijbalken vaak weer terug, zelfs als de gebruiker ze net had dichtgeklapt. Oorzaak: useState(false) + read-effect was vatbaar voor een race — bij first render dropte de write-effect (state via closure = false) "closed" terug in localStorage VOORDAT de read-effect z'n setLeftSidebarOpen(true) propageerde. Bij een snelle remount-cyclus (auto-refresh visibility-handler) eindigde dat met een verkeerd-gepersisteerde of opnieuw-uitgelezen "open" voorkeur ondanks dat de gebruiker net had dichtgeklapt.

In dark mode was de e-mail-pagina-achtergrond #0d1117 terwijl de body #070a0f gebruikte — 6 helderheids-eenheden verschil. Dat gaf links en rechts van de e-mail-shell een zichtbare overgang alsof de achtergrond ophield. In light mode liep het wél door omdat body daar pure wit is en de e-mail-tegels nauwelijks afwijken.

De Launchpad-pagina (en alle andere portal-pagina's die .tbv-page--portal gebruiken) toonden een paars-roze gloed rechtsboven die uit de toon viel bij een teal/groene huisstijl. Op vier plekken in globals.css stond rgba(139, 92, 246, 0.22) hardcoded in dark mode + rgba(167, 139, 250, 0.28) in light mode — beide violet/lavender — als achtergrond-aura. De Launchpad eigen orbs gebruikten al var(--accent), maar de page-bg daaronder dus niet.

De twee zijbalken op /meetings (links: mini-kalender + agenda-filters, rechts: deze-week stats + up next) stonden altijd open. Op kleinere schermen of voor wie de kalender wil zien, is dat te druk.

De "Postvak IN" header en de subject-titel van een geopende mail zijn een tintje slanker gemaakt (bold → semibold). Voelt eleganter en past beter bij de premium look.

Het zoekveld bovenaan de campagnes-pagina had een dubbele border: de wrapper had de stijl-border, en de browser tekende daarnaast nog een eigen ronde border rond de <input type="search"> zelf (Safari/Chrome default voor search-inputs).

De "E-mail campagnes"-titel met envelope-icoon en de intro-zin ("Stuur klanten maandelijkse updates, nieuwsbrieven of aankondigingen met templates") zijn verwijderd. De breadcrumb "E-mail › Campagnes" blijft staan en geeft genoeg context; de pagina opent nu directer met de KPI-tegels.

Bij booking-create syncede Senly het event naar alle gekoppelde agenda's (Google/Outlook/Apple), maar de externe externalIds werden nergens vastgelegd. Bij cancel — via host DELETE, host PATCH→cancelled óf attendee self-service token — werd alleen de DB-status op CANCELLED gezet plus een cancellation-mail verstuurd. De gesyncede kopieën in de iPhone Apple Calendar, Google Calendar, etc. bleven staan en moesten handmatig opgeruimd worden.

Op de campagnes-pagina stonden nog drie placeholder-elementen: de verzonnen sparklines achter de 4 KPI's, een "Optimaliseer onderwerpregels"-card met een dode knop, en een "Beste verzendtijd — Donderdag 10:00"-card die uit de losse pols gehaald was.

Bij klik op "Annuleer boeking" werd de booking in de DB op CANCELLED gezet en kreeg de attendee netjes een cancellation-mail, maar het tile bleef vrolijk in de kalender hangen. Status badge in het popover toonde wel "CANCELLED", maar de visuele booking was nog steeds zichtbaar op zijn oorspronkelijke tijdslot. Andere code-paden in dezelfde file (Vandaag-strip, Up Next, MonthGrid telling) filterden cancelled wel weg, alleen de hoofd-render via filteredBookings → MonthGrid/WeekGrid/DayGrid niet.

De KPI-tegels en per-campagne statistieken op /email/campagnes waren placeholders. Je wist nooit hoeveel mensen je mail écht openden of doorklikten — alleen hoeveel mails er waren afgeleverd.

De vierde KPI was "Omzet gegenereerd" — verzonnen data. En de "Start re-engagement"-knop in AI Suggesties deed niets.

De "Annuleer boeking"-knop stond als 12px grijze text-only knop helemaal rechtsonder in de footer — vrijwel onzichtbaar. Gebruikers vonden de delete-actie niet en gingen via hun iPhone Apple-agenda het event verwijderen, maar dat haalde alleen de sync-kopie weg; de Senly source bleef staan en het event verscheen opnieuw in de kalender. Plus: de oude knop gebruikte een browser-confirm() popup, lelijk en out-of-style.

Op de Trends-pagina stond een teal FAB op fixed bottom: 24px right: 24px die conflicteerde met de chat-widget op dezelfde positie. Gaf een lelijke dubbele-cirkel look. Daarbij deed de FAB nog niets (placeholder voor toekomstige AI-assistent).

In BookingDetailPanel was de knop een <a> met meet-btn-primary class. Globaal a:hover { color: var(--text) } heeft specificiteit 0,1,1 > .meet-btn-primary (0,1,0). Resultaat: tekst alleen zichtbaar bij hover.

Als de gebruiker een event verwijderde via zijn iPhone/Apple Calendar, bleef het oude event in Senly staan tot hij naar een andere pagina navigeerde en terugkwam — soms minuten lang. Oorzaak: useEffect(() => load(), []) draaide alleen bij mount, geen polling en geen window-focus listener. De localStorage-cache van 2 min liep wel af maar zonder trigger gebeurde er niets.

Offline-pagina was plat: generic icoon, basic typografie, plain teal knop op donkere achtergrond.

Bij klik op een Google/Outlook/Apple-event in de meetings-kalender opende een read-only popover met enkel een tekstje "Dit event komt uit je gekoppelde X-agenda en kan alleen daar bewerkt worden." De gebruiker moest naar de externe agenda-app om iets te verwijderen — onnodig, want de provider-delete-functies (deleteGoogleEvent / deleteOutlookEvent / deleteAppleEvent) bestonden al voor onze eigen booking-cancel flow.

De campagnes-pagina was een afgeslankte kaartenlijst zonder overzicht: geen KPI's, geen filter, geen paginatie, geen statistieken per campagne. Vergeleken met de rest van het portaal voelde 't zwak en lui.

Widget toonde hardcoded statische waardes 2,4 GB / 10 GB / 24% met als comment "placeholder, echte byte-meting komt later". Misleidende UI — gebruiker dacht dat dit echte data was.

Twee nieuwe leftSidebarOpen + rightSidebarOpen states. .meet-cal-layout krijgt no-left en no-right modifier classes die grid-template-columns naar 0 1fr X of X 1fr 0 zetten. Smooth transition 320ms cubic-bezier(0.16, 1, 0.3, 1) op de grid-columns geeft een vloeiende slide-animatie. Inhoud van de sidebar fade-out + translateX 12px voor extra polish. Toggle-knoppen in de toolbar (links en rechts) met SVG icoon dat 180deg rotateert om de state te tonen. Beide sidebars staan default open zodat niets verandert voor bestaande gebruikers — kunnen op verzoek wegklikken voor maximale focus op de kalender. Mobile (max-width 900px) blijft full-width met sidebars verborgen.

Vorige iteratie had de titels naar weight 500 gezet, wat in de kleine event-blokken te dun was om vlot te scannen. Terug naar weight 600 — middenweg tussen "drukke 700" en "te dun 500". Toegepast op week-bk, week-ext, day-bk, day-ext.

.meet-upnext-info strong (Niura analysegesprek, Met mama mee naar het ziekenhuis, etc.) van font-weight 700 -> 500. .meet-dist-name (Gezinsagenda, Werk, Agenda) van 600 -> 500. Consistent met de stat-nummers en event-titels die ook 500 zijn.

Display-typografie van 28px/font-weight 600 verlaagd naar 22px/font-weight 500 voor de 4 stat-cards. Letter-spacing iets minder agressief (-0.025em ipv -0.035em). Event-blok titels (week-bk, week-ext, day-bk, day-ext) ook 600 -> 500. Resultaat: rustiger en eleganter, minder schreeuwerige cijfers en titels.

Vorige polish-ronde voegde subtiele 180deg gradients toe aan alle cards + 105deg diagonale gradient op event-blokken. Bij elkaar maakte dat de pagina visueel drukker i.p.v. eleganter — te veel beweging in het oog.

Cards en buttons voelden web-default aan met enkele 1px borders en simpele shadows. Numerieke typografie (11, 39%, 19u 40m) was te dik en zonder tabular nums. Geen subtiele gradients, geen multi-layer depth.

In iteratie 2 had ik de Spam-folder en de "Accounts beheren"-link verwijderd omdat ze niet op de mockup stonden — maar je had ze nodig om ongewenste mail te bekijken en om nieuwe Gmail/IMAP-inboxen toe te voegen.

Bij de visuele redesign was de Campagnes-link uit de sidebar verwijderd, en als gevolg was de mass-mailing-pagina (/email/campagnes) alleen nog te bereiken via een directe URL.

De fetch voor de vorige filter (bv. Met ster) kon ná de fetch voor je nieuwe filter ("Alle") binnenkomen en de resultaten overschrijven — visueel "glitchte" je dan terug naar gevlagde mails terwijl Alle actief was.

De actie-knoppen werden disabled tot de Gmail/IMAP-call klaar was. Bij een trage Gmail-antwoord kon het 30 seconden duren voor je weer kon verwijderen, ook al was de volgende mail al geopend.

Bij klikken op het prullenbakje wachtte je tot de Gmail/IMAP-call klaar was voor de mail uit de lijst verdween — plus een bevestigings-popup. Voelde lui en je bleef met een leeg lezer-paneel zitten.

De move-endpoint accepteerde alleen IMAP-accounts. Voor Gmail-accounts (zoals zakelijk@socialmediatools…) gaf de server een 400 "Alleen IMAP-accounts ondersteund" terug — visueel leek het alsof het prullenbakje stuk was, en hetzelfde gold voor archiveren en als-spam-markeren.

Een oudere .ml-app-regel zette padding: 0 20px op de grid-shell. Mijn override zei daar niets over en de oude padding overleefde — daardoor stonden de panels strak binnen een afgerond kader, met zichtbaar rechte hoeken in plaats van mee-afgeronde.

De 3-koloms mail-shell had een border van 1 px rond het geheel — die maakte een tweede lijn buiten de witte panels en gaf een opvulling waar je 16e niet wilde.

De 3-koloms mail-shell had een negatieve top-margin (-8 px) zodat 'ie direct tegen de top-rand van het hoofdpaneel stond — Meetings en andere tabs hebben juist visuele ademruimte rondom de content.

In het rechter mail-paneel was de subject één losse h1, en de mail-inhoud landde als platte tekst onder een grijze regel — geen scheiding, geen ademruimte, geen "lux" gevoel.

Hard 1px border + plat hover-effect maakten de blokken goedkoop ogen — meer web-app default dan premium calendar.

Bij scroll viel een kwart van de "Categorieën" sidebar-card weg achter de topbar — alleen de items waren zichtbaar, de titel niet meer.

De "The Future of Social Media 2026"-card in de sidebar was een statische promo waarvan de "Download rapport"-button geen onClick had — klikte je erop, gebeurde er niks. Tegelijkertijd zat de AI-samenvatting als 5e KPI in een rij die daardoor te druk en breed werd.

Vorige gradient (22% naar 4%) was nog te dominant — kleuren overheersten de tekst en het overzicht.

Inconsistente kop-typografie in de sidebar: Kalenders/Mijn agenda's waren uppercase 11px letter-spaced (label-stijl) terwijl Up next / Verdeling deze week / Deze week 14-16px regular case (title-stijl) waren.

De achtergrond was overal gelijk getint (12% kleur), wat te fel/zwaar voelde. Mockup-vibe wilde subtieler en gericht: feller bij de kleur-strip links, lichter naar rechts.

De pagina voelde druk, kinderachtig en goedkoop aan met cartoony 3D-floating tiles op blog-cards, gekleurde icon-vlakjes (blauw/mint/roze/paars) op KPI-cards, een fel-paarse AI-samenvatting card, een paars-violette featured rapport-banner, en volle gekleurde pill-tags. Niets daarvan zou je verwachten op een echt premium SaaS-product.

De toolbar en de week/dag/maand-grid zaten samen in één witte card met alleen een border-bottom als scheiding. Voelde plakkerig en niet zoals het mockup waar ze visueel apart staan.

De Categorieën-sidebar gebruikte een mix van platform-brand-logo's (mooi gekleurd) en losse emoji's (🎯 📊 🛠 📢). Stijlbreuk: emoji's zien er flat en OS-afhankelijk uit naast de strakke SVG-platform-logo's.

Twee plekken om hetzelfde logo in te stellen: de centrale Huisstijl-pagina (waar ook favicon staat) en een aparte per-booking-page override in Meetings → Branding. Verwarrend en redundant. Bovendien wilde gebruiker single source of truth voor logo+favicon.

.bp-host-card had margin-top: auto wat het flexbox naar de absolute onderkant duwde. Bij de form-stap (Naam/E-mail/Bedrijf/Telefoon/Toelichting fields) wordt het rechterpaneel veel langer, de shell rekt mee, en het host-blok zakte mee naar beneden zodat het pas onder de fold zichtbaar was. Visueel oneerlijk: host "schoof" tussen stappen.

Footer op /boek/[user] en /boek/[user]/[slug] gebruikte data.branding.portalName ("Bedrijfsportaal"), maar bureaus willen hun eigen naam zien (bv. "Studio X Marketing").

De 44px thumb links van elke rij was alleen een platte pastel-vlakje met een puntje "•" (bij algemeen) of klein flat platform-icoontje. Saai, en bij algemene rijen ontbrak elk visueel anker.

In de tijdzone-pill (Europe/Amsterdam) was een grijze rechthoek rond de tekst zichtbaar — browser-default focus border van het <select> element kwam door mijn appearance:none reset heen.

In BookingPage.tsx werd .bp-cal-grid gebruikt voor twee verschillende grids: de datum-picker (7 kolommen voor weekdagen) EN de "Toevoegen aan agenda" knoppen op de success-screen (3 kolommen voor Google/Outlook/Apple). Door CSS-cascade overschreef de tweede definitie (repeat(3, 1fr)) de eerste (repeat(7, 1fr)), waardoor de datum-picker met 3 kolommen renderde en alle weekdagen + dagen wrapten naar belachelijk grote vakjes.

De pagina voelde compact aan; KPI-cards, tabs, blog-grid en inzichten zaten te dicht op elkaar waardoor de cinematic premium-look verloren ging.

v6.56 voegde portalDomain toe als verplicht veld aan BrandingConfig interface, maar hooks/useBranding.ts had een DEFAULT constante getypeerd als BrandingConfig zonder dat veld. Railway deploy gefaald: Type error: Property portalDomain is missing.

De "Alle trends"-tab beweerde 50 items te bevatten, maar zichtbaar waren alleen 3 trending blogs + 8 inzichten — de overige 39 waren onbereikbaar zonder filter. De vaste slice(3, 11) kapte de lijst stilletjes af.

BookingLinkChip en TypesPanel gebruikten altijd window.location.origin voor de URL ("senly.io/boek/..."), ook als de tenant een eigen white-label domein had ingesteld in Admin > Instellingen. Voor wederverkoper-bureaus geen herkenbare URL voor hun klanten.

Na de pastel-gradient redesign waren cards mét platform mooi (Instagram-tile zichtbaar in het midden), maar cards zonder platform (categorie "algemeen") waren leeg — alleen pastel, geen visueel anker.

De Unsplash-foto's waren visueel druk en concurreerden met de tekst — leuke gezichten, maar niet "rustig premium". De gebruiker stuurde een mockup met een Instagram glass-tile op perzik, TikTok-logo's op wit en app-icons op licht-paars als referentie.

In plaats van pure witte achtergrond gebruiken alle event-blokken (week-bk, week-ext, day-bk, day-ext) nu color-mix met 12% saturatie van --block-color tegen var(--bg-elev). De border krijgt 20% saturatie van dezelfde kleur. De halve verticale kleur-strip blijft full color. Resultaat: doorzichtige achtergrond in dezelfde kleur als de strip — past beter bij de Apple-stijl met meer visuele samenhang.

De .meet-hero-title h1 en .meet-hero-sub p zijn uit JSX gehaald. Alleen de tabs (Kalender / Instellingen) en de publieke booking-link blijven nu in de header. Hero-padding verlaagd van 32px top naar 16px omdat de grote titel weg is. Direct meer ruimte voor de kalender zelf.

Event-blokken hadden pastel-tinted achtergrond + gekleurde border. User wilde de schonere Apple/Linear-stijl: witte achtergrond met slechts een kleine verticale kleur-strip linksboven die niet de volle blokhoogte beslaat.

Taak overzicht-sectie suggereerde een echt taken-systeem maar telde alleen booking-statussen (te-voorbereiden = confirmed, follow-ups = completed, etc). Verwarrend en bij gebruikers zonder Senly-bookings altijd 0.

Titel had -webkit-line-clamp: 2 wat 2 regels mocht innemen. Bij korte events (30 min = 30px) kwam de subtitle (locatie/Zoom-URL) daaronder en werd half afgesneden door overflow:hidden. Resultaat: regels die halverwege werden afgekapt — lelijk.

Browser-defaults op <button> elementen gaven text-align: center, waardoor de tekst in elk event-blok in het midden uitgelijnd was. Mijn text-align: left op de parent button werkte niet door naar de strong/span children, vooral niet bij display: -webkit-box (line-clamp).

Bij events met lange titels (zoals "Kennismakingsgesprek | Social Media Beheer / Groeiservice") en lange locatie-URLs liep de tekst door en werd half afgesneden. Plus de title-font was 700 wat te dik aanvoelde voor de kleine grid-tekst.

De sparkline (groene/roze trendlijn) lag over de volle breedte van elke KPI-card. Door de lichte opacity (0.55) scheen de lijn door de teksten "Trending nu / 50 / Actieve trends" heen — onleesbaar en visueel rommelig.

De Social Media Trends-pagina riep bij elk bezoek /api/trends opnieuw aan. Zelfs met de bestaande server-side cache betekende dat ~15 seconden wachten zodra de Node-proces was herstart (Railway redeploy / idle-scaling wipes _mem en .trends-cache.json).

colorForExternal() viel terug op event-titel voor de hash bij ontbrekende calendarName, terwijl de sidebar terugviel op "{provider} ({email})". Resultaat: zelfde sidebar-groep maar verschillende grid-kleuren per event. Ook waren de pastel-tints (12% saturatie) te licht waardoor het visueel niet duidelijk was dat groen=Werk en geel=Gezinsagenda overeenkwamen.

Het week- en dag-grid had hardcoded tijdrange 08:00-18:00 (11 rijen). Events die vroeg in de ochtend of laat in de avond startten werden niet gerenderd, maar wel meegeteld in "X Meetings" / totale tijd. Gevolg: stats zeiden "11 meetings" terwijl je er maar 8 in beeld zag.

Sidebar had één algemene "Externe events" toggle + een hardcoded "Verjaardagen" item. Maar gebruiker heeft meerdere agendas (Werk/Gezin/Privé/Gezinsagenda) en wil die los kunnen aan/uit zetten — net zoals in de Apple Calendar agenda-beheer modal.

Nieuwe fullscreen state op CalendarView. Wanneer actief krijgt .meet-cal-wrap een is-fullscreen class die hem omtovert tot position:fixed inset:0 met z-index 999 — bedekt sidebar, hero header, en alle andere UI. Zijkolommen (mini-cal/filters links, stats rechts) en de Vandaag-strip worden verborgen via display:none. Alleen de hoofd-kalender vult het scherm, met fade-in animatie. Toggle-knop met expand/collapse icon naast "+ Nieuwe meeting" doet hetzelfde. Sluiten kan met de toggle-knop OF de Escape-toets.

Externe events waren niet klikbaar (pointer-events: none) — frustrerend want je kon ze niet inspecteren. Senly-bookings hadden wel een slide-in panel maar dat zat aan de rechterzijde verstopt.

De maandag-berekening voor het week-label gebruikte `start.getDate() - start.getDay() + 1`. Op zondag is getDay() = 0, dus dat wordt `31 - 0 + 1 = 32` → 1 juni. Fout. Op andere dagen klopte het wel toevallig.

Elk item krijgt via ::after een 1.5px verticale lijn die naar het volgende item loopt, in dezelfde kleur als de dot (via CSS custom property --line-color). De dots krijgen een witte ring (box-shadow) zodat ze "boven" de lijn drijven. Duration wordt nu een afgeronde pill (15m, 30m, 60m) i.p.v. plain tekst. Exact als de mockup-timeline look.

Eerste versie telde alleen Senly bookings, en de trend-percentages (+12%, +8%, +5%, +3%) waren hardcoded uit de mockup. Wie alleen externe agenda gebruikt zag overal 0 staan met liegende trend-percentages eronder.

Mijn nieuwe teal FAB cirkel piepte rechtsonder bovenuit achter de bestaande chat-widget (Crisp/Intercom). Gaf een lelijke dubbele-cirkel look.

Alle secties stonden direct op de body achtergrond zonder visuele scheiding. Voelde plat en ongestructureerd, anders dan de mockup waar elke sectie een duidelijke card-container is.

Externe Google/Outlook events kregen allemaal dezelfde paarse tint, terwijl de design-mockup een gevarieerd kleurenpalet toont. Saaie one-color look.

Vorige poging gebruikte CSS accent-color, maar dat geeft browser-inconsistente render en lichte tint i.p.v. de volle kleur. Mockup heeft volledig groene/blauwe/oranje vakjes met wit vinkje.

De today-cards lijken nu visueel op de design-mockup: 3px verticale type-kleur strip aan de linkerzijde (via ::before), duration als afgeronde pill (60m, 30m) i.p.v. plain tekst, twee avatar-cirkels met initialen die overlappen, en sterkere hover-state met type-kleur border. Nieuwe-meeting empty-card heeft nu een subtielere look.

De 3 Trending Blogs-cards hadden een pastel pink/peach gradient als hero-image. Zag er goedkoop uit — gebruiker wilde echte social media foto's.

Eerste pas van de redesign had nog visuele resten van de oude layout: teal-streep links van datum-headers, "Accounts beheren"- en "Campagnes"-rijen in de sidebar, "Spam"-map zichtbaar, "Gevlagd"-label i.p.v. "Met ster", en de labels-lijst was uitgegrijsd.

De .support-fab had twee animerende pseudo-element rings (::before en ::after) die continu uitwaaierden in de huisstijl-kleur. Op een witte achtergrond zag dat eruit als een vlek of glow achter de knop — onrustig.

De light-mode body-background had een complexe radial-gradient stack met #f2f7f7 + teal/purple tints. Dat gaf overal een licht groen-gewassen sfeer — gebruiker wilde gewoon strak wit.

De v6.20 redesign had de juiste layout-structuur (3-kolom + vandaag-strip) maar de details week visueel af van het mockup: stat-cards waren te plat, toolbar-knoppen te basic, week-view bookings hadden solid kleuren i.p.v. pastel-tint, en de standaard view was Maand.

.smtr-root background is nu #ffffff i.p.v. de off-white tint van v6.24. Dark-mode override blijft staan zodat het portaal-thema in dark gewoon donker rendert.

De Trends-pagina had de standaard portaal-achtergrond met een groen-zweem, terwijl de mockup een rustig off-white toonde dat de witte cards beter laat ademen.

De oude EmailInbox voelde plat — geen visuele scheiding tussen mappen / lijst / lezer, geen sectie-groepering in de sidebar, en geen "ademruimte" rond de gelezen mail. Vergeleken met de mockup oogde 't functioneel maar niet premium.

De auteur-avatars op de Trending Blogs-cards toonden 2-letter-initialen op gekleurde cirkels. Zag er goedkoop uit en suggereerde fake-content.

De filter-chips en categorie-sidebar gebruikten emoji (📷 voor IG, 🎵 voor TikTok, etc.) die op verschillende OS-versies anders renderen en niet matchen met de huisstijl van elk platform.

De Meetings-pagina had een simpele 2-kolom layout zonder overzicht van statistieken, aankomende afspraken, of een dagweergave-strip onderaan.

De oude trends-pagina had geen samenhangende structuur — KPI's, trend-cards en bookmarks stonden los van elkaar zonder duidelijke hiërarchie.

Aparte stylesheet voor de trends-pagina, geïmporteerd vanuit page.tsx. Alle styling via design-tokens en color-mix() voor pastel-tints. i18n: 19 nieuwe keys (smt_*) in nl/en/de/fr. Pseudo-stats (leestijd, bereik %) zijn deterministisch op item-id zodat refreshes consistent zijn.

Na de eerste ronde (Dashboard, Kalender, Trends) hadden de overige pagina's nog hun oude padding: .container-pagina's 40px, Launchpad 40px, Onboarding/Affiliate 40px inline, Email 0px, Integratie-detail 28px. Hierdoor verschilde de inhoudsuitlijning per sectie.

De decoratieve <div class="lp-bg-decor"> met 3 animerende huisstijl-orbs is uit LaunchpadView.tsx gehaald. De CSS-keyframes blijven staan voor het geval we ze later opnieuw willen aanzetten — geen impact want het element wordt niet meer gerenderd.

Content-kalender had een eigen wrap met max-width: 1600px + 40px zij-padding + auto-margin, waardoor de inhoud op brede schermen gecentreerd werd met overdreven veel witte ruimte rechts (asymmetrisch t.o.v. de sidebar). Dashboard en Trends hadden weer 0 zij-padding op hun root, terwijl Meetings via .meet-topbar standaard 20px gebruikt. Effect: vier pagina's die naast elkaar inconsistent voelden.

.taskio-card-head h3 font-weight van 700 naar 600. Eén tandje dunner, oogt rustiger naast de gradient KPI-tegels en past beter bij de premium typografie van de rest van het portaal. Letter-spacing -0.015em blijft voor de optical correction.

De body heeft zelf al een teal-tinted gradient. Mijn extra orbs op 35% opacity met 80px blur en 32% kleurverzadiging vielen daar volledig in weg — je zag visueel niks veranderen.

Na de uitrol op admin-pagina's (v6.12) bleven nog vier pagina's achter met de oude lange uitleg-paragraaf onder de titel.

Onder de titel van die pagina's stond steeds een lange uitleg-alinea die ruimte innam en de hero "log" maakte. Op Launchpad en Takenbeheer was dat patroon al vervangen door een ⓘ-icoontje — dat moest naar de rest.

De Launchpad-pagina had een platte witte achtergrond — voelde leeg en weinig "wow" voor de eerste indruk waar gebruikers binnenkomen.

.lp-root had padding: 32px 0 64px — geen horizontaal padding. Daardoor plakte de "Launchpad"-titel tegen de menubalk-rand terwijl andere pagina's 40px margin van die kant kregen via .container.

Net als Launchpad had de Custom rollen-pagina nog de oude .container wrapper (max-width 1320px) waardoor de inhoud gecentreerd stond in een smaller frame i.p.v. mee te lijnen met de rest van het admin-deel.

De Launchpad-pagina werd geclamped op 1320px breed met 40px horizontale padding extra erbovenop. Op brede schermen (of zoals bij gebruiker met 80% Chrome-zoom) zag dat er ingesnoerd uit naast het dashboard dat wél de volle breedte gebruikt.

Doordat de uitleg-alinea verdween en achter het (i)-icoontje verschoof, plakten de actie-knoppen / stats / KPI-grid direct onder de h1 — voelde te krap, niet ademend.

Op Tools, Launchpad, CRM Leads en Social Media Trends stond de uitleg-alinea permanent in beeld onder de titel — terwijl je die info maar één keer hoeft te lezen. Verschillende stijlen tussen pagina's ook.

De deadlines-widget was visueel "vlak en saai": alle taken in een grijze rij met dunne 4px border-left, kolom-headers waren alleen tekst, "VANDAAG"-empty toonde een dood "—". Niet passend bij de premium look van de Maandwinst- en Klanten-widgets.

De heading op de Takenbeheer-pagina had margin-bottom: 14px ingebakken — daardoor stond de h1-box hoger dan z'n visuele tekst en kwam de (i)-knop met align-items: center optisch op de bodem van het tekst-blok terecht.

De subtitel onder "Takenbeheer" nam veel ruimte in en stond ongelukkig op "synchroniseert automatisch met GoHighLevel" — terwijl Takenbeheer prima standalone werkt, GHL is maar één van de optionele integraties.

De inline-uitklap (v6.01) maakte het dashboard heel lang scrollbaar als je 18+ klanten had — alles werd onder elkaar gepropt en duwde de rest van het dashboard naar beneden.

De "Bekijk alle 18 klanten →" knop was een Link naar /financieel. Voor een manager zonder viewFinance-permissie deed dat niets, en zelfs met permissie kreeg je de algemene financieel-pagina i.p.v. specifiek de klantenlijst met bedragen.

De uitleg-alinea onder "Verdien 30% MRR per verwijzing" nam veel verticale ruimte in voor informatie die je maar één keer hoeft te lezen.

Door de inline-flex op .sa-title-row zat de h1 op dezelfde regel als de "SOCIAL ACCOUNTS" eyebrow ernaast i.p.v. eronder.

De "72 slots · 0 gekoppeld · 5 verlopen"-regel was puur tekst met scheidings-puntjes. Niet meteen visueel onderscheidbaar.

Er bestaan twee admin "Maandwinst"-implementaties: één op /financieel (.monthly-bar-*, brede capsules) en één op het admin-dashboard (.taskio-revenue-*, smalle 8-18px pillen). v5.94 koppelde de manager-widget aan de eerste — daarom kreeg de manager BREDE rechthoeken in plaats van de smalle pillen die admin op zijn dashboard ziet.

De uitleg-tekst onder de titel "Massa-koppeling" nam veel verticale ruimte in voor info die je maar een keer hoeft te lezen.

De Jaar-overzicht widget had defaultSpan 2 — half scherm. Admin Maandwinst (revenueChart) heeft defaultSpan 3 — driekwart scherm. Daardoor oogden de bars op het manager-dashboard smaller dan op het admin-dashboard, ondanks dat de CSS sinds v5.94 1:1 gedeeld wordt.

Een staaf per maand toonde alleen het totaal — geen onderscheid tussen waar het inkomen vandaan komt. Manager kon niet snel zien hoeveel deel klant-fees vs flat fee was per maand.

Drie chips in de header (vergelijkbaar met legend van admin maar klikbaar). Klik "Klant-fees" → alleen die kolom getoond. Klik "Vast bedrag" → alleen flat fee. Klik "Beide" → terug naar gestapeld. Jaartotaal in de sub-header past zich aan op het actieve filter. Hover-detail toont altijd beide bedragen + totaal ongeacht filter.

mgrwidget_year_filter_all (Beide / Both / Beide / Les deux), mgrwidget_year_legend_clients en mgrwidget_year_legend_flat. CSS-class .mgr-year-chip toegevoegd voor de chip-styling (pill-shape, teal-active-state).

Vorige versies probeerden de admin-stijl te imiteren via aparte .mgr-year-* classes, maar het kwam visueel niet exact overeen (bar-hoogte, profit-label positie, hover-bubble, projectie-tonen).

De widgets namen veel verticale ruimte in. Het jaar-overzicht had 220px hoge bars, het inkomen-blok 18-26px padding rondom. Op normale schermen scrolde de rest van het dashboard daardoor te ver omlaag.

Cards krijgen nu een echte glass-look: backdrop-filter blur(10px) + saturate(140%), inset highlight bovenaan, drop-shadow voor diepte, en op hover een subtiele teal-glow ring. Bars zijn niet meer flat-teal maar een gradient (lichter teal bovenaan → teal mid → donker teal onder) met een witte inner-highlight aan de top, plus een drop-shadow eronder. Hero-cijfer gebruikt een gradient met drop-shadow filter voor luxe glow. Klant-rijen schuiven 2px naar rechts bij hover, sub-stat blokjes lichten subtiel op met teal-border, "Bekijk alle klanten" knop heeft nu een echte ghost-button stijl met teal border. Alles werkt in dark én light mode.

De manager Jaar-overzicht widget toonde donkergrijze pillen in plaats van teal staven, omdat de stack-background visueel overheerste over de teal segment. Plus de styled-jsx light-mode overrides werkten niet (zelfde scoping-issue als v5.90). De widget paste daardoor niet bij de admin Maandwinst-stijl.

De twee sub-stat-blokjes (Vast maandbedrag + Klant-fees) waren donkergrijs met onleesbare tekst in light mode.

Een manager kon nergens snel zien wat de huidige maand-inkomsten zijn — alleen via /financieel/tab=employees waar admins kijken. Geen eigen overzicht op het eigen dashboard.

Hetzelfde gemis aan trend-overzicht: hoe stabiel was mijn inkomen het afgelopen jaar? Welke maand was uitschieter? Niet zichtbaar.

computeManagerIncome(userId, periodMonth) + buildManagerYearSeries(userId, year). Period-overlap query voor FlatFeeAgreement (zelfde patroon als employee-cost-overview), één DB-call voor het jaar i.p.v. 12 losse queries. Pauze-detectie via Client.isActive. Beide widgets fetchen server-side in app/(dashboard)/page.tsx zodat het dashboard meteen rendert zonder client-roundtrip. 20 nieuwe i18n-keys × 4 talen = 80 strings. Widgets automatisch zichtbaar via audience: 'manager' in WIDGET_CATALOG.

De light-mode CSS-overrides stonden in <style jsx> binnen de componenten zelf. styled-jsx scope't echter de selector `html[data-theme="light"]` naar de component-instance i.p.v. het globale html-element — waardoor de overrides nooit aansloegen. Resultaat: donkere inputs op witte card-achtergrond (rgba(0,0,0,0.25) viel terug op de dark-mode default).

Voor een manager kon je geen vast maandbedrag per klant instellen. Sales attributie ondersteunt alleen percentages voor setter/closer/sales_manager — geen vast bedrag voor de operationele manager die de klant beheert.

Iedereen met MANAGER-rol zag álle klanten van het bureau — geen scheiding tussen wie welke account beheert. Voor bureaus met meerdere account managers gaf dat te veel ruis en privacy-issues.

Beide velden zijn optional dus geen risico voor bestaande klanten — die starten met managerId=null en blijven gewoon zichtbaar voor admin. Named relation "ClientManager" met onDelete: SetNull zodat een verwijderde User automatisch de koppeling losmaakt. Index op (tenantId, managerId) voor snelle visibility-queries. Railway pakt de schema-wijziging op via prisma db push bij deploy.

De pagina was één lange scroll met 7 secties achter elkaar (KPI's, grafiek, maand-override, dienstverlening, per klant, overige, eenmalig). Lastig om snel naar wat je nodig had.

Geen centraal overzicht voor de bureau-eigenaar van flat fees + commissies + verloopdatums per klant-koppeling. Risico: een commissie-afspraak loopt langer door dan afgesproken zonder dat het opvalt.

ClientSalesAttribution gebruikte fallback CSS-vars (var(--surface, white)) en hardcoded kleuren (#fde9e9, #f3f3f3, white text op buttons) die in dark mode niet meeswitch'ten — drie witte cards midden in een verder donker klantprofiel.

Het Flat-fee blok stond als 3-koloms (Rol + Bedrag + Notitie). De drawer is maar ~440px breed, waardoor de Notitie-input over de rechterrand viel en niet meer aanklikbaar was.

De /changelog dark-mode bg was een platte donkere kleur — terwijl het portaal een zachte meerlagige radial-gradient stack heeft. Visueel voelde de pagina los van de rest van het portaal.

In dark mode kreeg het logo-rondje achter de teal Senly-S een donkere achtergrond — daardoor was het logo nog nauwelijks zichtbaar tegen de bijna-zwarte achtergrond.

De pagina gebruikte hardcoded Senly-teal voor de orbs, hero-accent, version-badge en filter-pill. Een bureau dat zijn portaal in bordeauxrood of paars had ingesteld, zag de changelog-pagina alsnog in teal — voelde niet als deel van hún portaal.

In mijn vorige dark-mode passes had ik selectors gebruikt die niet bestaan (.cl-card, .cl-hero-stat, .cl-version-pill...). Daardoor bleef de helft van de pagina wit-met-witte-tekst.

De middleware blokt al elke POST/PATCH/PUT/DELETE in demo (server-side veilig), maar de UI liet inputs en knoppen gewoon klikken. Daardoor leek het alsof je wijzigingen kon maken, terwijl ze nooit opgeslagen werden.

Mijn vorige dark-mode pass had het page-canvas en de cards al donker gemaakt, maar de bovenste hero-sectie hield een hardcoded wit-naar-grijs gradient. Daardoor was de titel "Wat is er nieuw in Senly" lichte tekst op een witte achtergrond — onleesbaar.

De "Flat fee instellen"-rij in de gebruiker-modal had witte tekst op een teal-knop (laag contrast) en de inputs voelden vlak.

In de "Bevoegdheden per rol"-tabel stond de Closer-rol er niet tussen, terwijl die wel in het systeem bestaat. Ook ontbrak Closer in getDefaultPermissions — daardoor kreeg een Closer effectief géén rechten als er geen custom-role override stond.

De /changelog pagina toonde altijd een wit canvas — ook als je in het portaal voor dark-mode had gekozen. Inconsistent en fel.

De "Flat fee instellen"-sectie gebruikte hardcoded var(--surface-muted, #fafafa) wat in dark mode terugviel op bijna-wit — daardoor was de hele inputrij niet leesbaar.

De drawer rechts in beeld liet de achterliggende pagina nog doorschemeren, waardoor labels en knoppen onleesbaar werden.

De "+N tags" pill brak op twee regels (woord viel onder de pill door) en de subject-tag "Web Dev & Design" wrap-te ook over twee regels — beide zagen er rommelig uit.

In de gebruiker-bewerken-drawer was de tekst op de Verwijderen-knop bijna onzichtbaar — rode letters op een rode achtergrond.

Stages kwamen altijd in de volgorde waarin ze aangemaakt waren. Wilde je "Lead binnen" vooraan zetten of "Gewonnen" helemaal rechts, dan moest je dat via de database doen.

Je kon alleen leads één voor één verwijderen via de modal. Voor opruim-acties (bv. 100+ duplicates wegtikken) was dat onwerkbaar.

Als je per ongeluk een stage verwijdert, worden alle leads in die stage automatisch naar de eerstvolgende stage verplaatst. Daardoor zat ineens een berg "Lead binnen"-leads onder "Gekwalificeerd" — niet duidelijk welke je terug moest klikken.

De Import GHL-knop trok blind alle GoHighLevel-contacten binnen via /contacts/ en plaatste alles in de eerste Senly-stage. Daardoor kwamen er ook contacten uit Gekwalificeerd / Gebeld / Klant terecht in "Lead binnen" en zat je met 155 leads i.p.v. de gewenste 105.

De quick-action rij onderaan een lead-card had alleen bellen en mailen. WhatsApp is in de praktijk het meest gebruikte kanaal voor sales-follow-up, en je kon niet zien of er al notities of taken zijn zonder de card te openen.

De kanban-cards toonden alleen bedrijf · bron in één regeltje en een waarde-bedrag. Te weinig info om in één oogopslag te scannen.

Bij het aanmaken van een nieuwe lead werd de in de modal gekozen status ("Gewonnen" of "Verloren") door de API genegeerd — POST destructureerde de body wel maar nam de status-key niet mee. Resultaat: lead werd altijd als "open" opgeslagen en je moest hem na opslaan opnieuw op "Gewonnen" zetten.

Je kon een lead alleen omzetten naar een NIEUWE klant via "Omzetten naar klant". Voor bestaande klanten moest je het handmatig bijhouden — en als zo'n klant later inactief werd, bleef de bijbehorende lead "gewonnen" staan, terwijl die eigenlijk verloren is.

Welke stage-kolom je ook aanklikte, de Nieuwe-lead-modal opende altijd in "Lead binnen" (de eerste stage). Daardoor moest je elke keer alsnog handmatig de juiste fase kiezen.

Als je een lead handmatig invulde zonder eerst een bestaand contact te koppelen, ging die lead langs de contactenlijst heen. Daardoor ontstonden er deals zonder centraal contactbeeld en moest je achteraf alsnog handmatig een contact aanmaken.

Je kon op het kanban-bord wel zien aan wie een lead toegewezen was (via de avatar rechtsboven), maar je kon de toewijzing niet aanpassen vanuit het lead-formulier zelf.

Op het CRM-bord zag je wel de naam en de waarde van een lead, maar niet wie er aan toegewezen was. Daarvoor moest je de lead openen — en met veel kaartjes op het bord werd dat vermoeiend.

Een lead-waarde was puur een bedrag in euro's — je kon niet zien of die "€80" voor een eenmalige opdracht stond, een uurtarief was of een maandelijks abonnement. Daardoor gaf de pipeline-totaal ook een vertekend beeld voor recurring deals.

In de horizontale rijen (Recent gebruikt, Aanbevolen voor jou, Favorieten) toonden de downloader-cards (TikTok, YouTube, Snapchat, Instagram, Facebook, LinkedIn) een generieke grijze cirkel — terwijl in de hoofdtabel de echte platform-logo's wel zichtbaar waren.

De feature-lijst op de login-pagina en in de onboarding-tour zei nog "15+ tools" — terwijl het tools-aanbod intussen ruim 30 hulpmiddelen telt.

De Contacten-tab toonde alles in de ruwe DB-volgorde — geen manier om snel je nieuwste leads bovenaan te zetten of alfabetisch te bladeren als je een naam zoekt.

Brand-geel (#FFFC00) is zo licht dat het witte ghost-icoon er nauwelijks van afstak — visueel verdween het spookje.

De avatar van een CRM-contact had een witte letter (#fff) op een teal gradient. In dark mode prima leesbaar, maar in light mode rendert die gradient veel zachter waardoor de letter visueel verdween.

Het Snapchat-logo gebruikte een zwart ghost-icoon op de gele tile. Officieel is het Snapchat-spookje wit, niet zwart. Was zichtbaar in zowel de tool-rij als in de bubbel-view.

In licht thema oogde de bubbel-view bijna pure wit met nauwelijks zichtbare kleur — daardoor voelde de tab kaal en niet premium.

Door de grotere cluster-radius schatting verdween het Sales-label boven de viewport. Tegelijk plakten labels van naast-elkaar liggende clusters bijna tegen de iconen van de buurcluster.

Bij clusters met veel tools (Sales, Analyse) dreven bubbels soms over het categorie-label heen, waardoor je de cluster-naam niet meer kon lezen.

Achter elk icoon zat nog een zachte category-halo plus een dark drop-shadow van de tile zelf — die combinatie liet visueel een "zwart rondje" achter de tile zien.

Iconen zaten in een kleur-bubbel waardoor het tabblad visueel druk werd (icoon in icoon). Bovendien bewogen alle bubbels constant rond — dat voelde onrustig.

Bubbels lieten alleen een kleine emoji of tekst-glyph zien — daardoor was het lastig om in één oogopslag te herkennen welke tool achter welke bubbel zat.

Bij Huisstijl-instellingen werd het logo na upload niet zichtbaar — alleen het alt-tekst-icoon ("Logo voorbeeld" of broken-image). Oorzaak: Next.js neemt op Railway een snapshot van de public/-map bij build. Bestanden die ná de deploy via POST /api/upload op disk komen, worden door de standaard static-server niet meer geserveerd → /uploads/abc.png gaf 404.

De fullscreen bubbel-view had zijn eigen donkerblauwe radial-gradient achtergrond. Daardoor voelde de tab los van de rest van het portaal — alsof je in een aparte app zat.

De NL-tekst "Synchroniseer boekingen automatisch met je Google Calendar. Auto Google Meet-links." brak naar 3 regels in de kaart, terwijl de andere providers maar 2 regels nodig hadden — visueel onbalans.

/tools dekte de globale teal/violet body-gradient af met een eigen platte linear-gradient — daardoor voelde de pagina los van de rest van het portaal, kaler en zwarter dan bv. Contacten of Takenbeheer.

In de fullscreen bubbel-modus zaten de zij-clusters en het bovenste/onderste cluster te dicht op de viewport-rand. Bubbels werden visueel "afgekapt" tegen de schermrand.

De vorige inline SVG-recreatie liet maar de helft van het logo zien en kwam visueel niet overeen met het echte Microsoft-merk.

Bij een NIEUW contact kon je vorige update al direct iemand toewijzen, maar bij bestaande contacten (bv. uit de CSV-import) was er geen manier om dat alsnog te regelen via de UI.

De vorige inline SVG was alleen een blauwe rounded square met een witte "O" — herkenbaar maar niet het iconische Outlook 2019+ logo dat mensen verwachten.

De SVG-content vulde de hele 48x48 viewBox tot aan de randen, waardoor in de integratie-kaart de hoeken en/of bovenkant van de envelope respectievelijk de camera werden afgesneden.

Het duur-veld was een select met alleen 15/30/45/60/90/120 min — geen ruimte voor coaching-sessies van 50 min of demos van 75 min.

De integratie-kaarten en de Apple koppel-modal toonden emoji (📅, 🍎, 🎥) als icoon, wat amateur oogt en op verschillende OS-versies anders rendert.

.meet-modal had geen padding waardoor de header, formulier-velden en knoppen direct tegen de randen van de modal stonden — geen visuele ademruimte.

Bij het aanmaken van een nieuw CRM-contact kon je nog niet aangeven wie er binnen het bureau eigenaar van is. Achteraf moest je dat alsnog handmatig instellen — irritant bij grotere teams.

Bij elke nieuwe lead moest je naam, bedrijf, e-mail en telefoon opnieuw intypen — ook al stond het contact al in je contactenlijst (bv. via de CSV-import).

In de fullscreen bubbel-modus stonden de zes clusters in een kleine cirkel midden op het scherm. De zijkanten en de bovenste/onderste rand waren leeg, terwijl de bubbels binnen één cluster juist op elkaar geplakt zaten.

Wel een import-knop, maar geen export. Wie wil overstappen naar een andere tool of een backup wil hebben moest handmatig contact voor contact kopiëren.

Bij wisselen naar de bubbels-tab bleven de Senly-sidebar en de bovenste topbar zichtbaar — daardoor voelde de "fullscreen" weergave nog steeds als een dashboard-pagina i.p.v. een eigen experience zoals cryptobubbles.net.

Een nieuwe gebruiker of iemand die overstapt vanuit GoHighLevel moest elke contact handmatig aanmaken. Bij een lijst van honderden leads is dat onbegonnen werk.