Je team leeft in Slack. Je systemen niet.
Kijk eens waar de dag zich echt afspeelt bij jullie. Iemand vraagt of die order verstuurd is. Een ander opent de back office, kijkt, en typt het antwoord in een kanaal. Twee uur later vraagt een derde precies hetzelfde.
Dat antwoord was er de hele tijd al. Alleen op een plek waar niemand was.
Dat gat kost geld, en iedereen heeft er stilzwijgend mee leren leven. Het dichten betekende namelijk dat mensen op twee plekken tegelijk moesten werken. Precies dat is veranderd.
Wat er op 24 augustus kwam
Salesforce lanceerde Slack Code en aparte code-kanalen. Tag een code-agent in een gesprek en er opent zich meteen een werkplek. Daarin staan het gesprek zelf, het plan van de agent, de wijzigingen die het maakte, en een live preview van het draaiende resultaat. Het werkt met Claude Code, Devin, GitHub Copilot, ChatGPT en Vercel-agents.
De kop gaat over ontwikkelaars. Het interessantere deel ligt eronder, en dat is niet nieuw. Slack bouwt al langer aan het leidingwerk waarmee systemen en agents van buiten kunnen werken met wat er in een kanaal gebeurt. Anthropic, Google, Notion, Dropbox, Perplexity en anderen bouwen daar sinds eind vorig jaar op.
Samen zeggen die twee dingen iets simpels. Slack is niet langer de plek waar mensen over het werk praten. Het wordt een plek waar het werk kan gebeuren.
Wat daardoor mogelijk wordt
De voorbeelden hieronder zijn van ons en niet van Salesforce. Behandel ze dus als een beginlijst en niet als een functielijst. Ze doen allemaal hetzelfde: iets wat nu vraagt dat iemand gaat kijken, komt voortaan naar je toe.
Goedkeuren waar het gesprek toch al is. Een klant vraagt een wijziging aan in je portaal. Nu ziet iemand dat, maakt een schermafbeelding, en plakt die in een kanaal met de vraag wat we doen. In plaats daarvan landt het verzoek zelf in het kanaal dat erover gaat, met de historie van die klant erbij en twee knoppen eronder. Het besluit valt waar het toch al besproken zou worden, en het systeem legt vast wie het nam.
Uitzonderingen die zichzelf melden. Elk operationeel systeem heeft een gelukkig pad en een stapel gevallen die eruit vallen. Die uitzonderingen komen meestal boven als iemand achter een order aan gaat, en dan is de vertraging al drie dagen oud. Een uitzondering kan zichzelf posten in het kanaal van het team dat erover gaat, op het moment zelf, met genoeg context om iets te doen.
Het cijfer komt naar je toe. De meeste bedrijven hebben dashboards die bijna niemand opent. Het weekcijfer dat een gesprek echt zou veranderen, kun je posten in het kanaal waar dat gesprek plaatsvindt. Op de ochtend dat het telt, met de twee regels uitleg die het betekenis geven.
Onboarding die zichzelf draait. Een nieuwe klant tekent. Nu start dat een checklist die iemand beheert en half onthoudt. In plaats daarvan wordt het kanaal aangemaakt en verschijnen de taken zodra ze aan de beurt zijn. Elke taak sluit zodra het onderliggende systeem zegt dat het klaar is. Niet zodra iemand een vinkje zet.
Vragen beantwoord uit je eigen materiaal. Een agent die in een kanaal werkt, kan putten uit wat eromheen staat. Neem een vraag als "wat hebben we met deze klant afgesproken over verlenging". Die beantwoordt je team nu door drie tools te doorzoeken en te vragen wie erbij was.
Overdrachten die niets meer kwijtraken. Werk dat twee teams raakt, raakt meestal ook twee systemen, en de context overleeft die overstap niet. Sales spreekt iets af, delivery hoort het later, en het detail dat ertoe deed stond in een thread die niemand doorstuurde. Een overdracht kan als één geheel verhuizen, met het dossier en het gesprek samen, naar het kanaal dat het oppakt.
Wijzigingen gestart door wie het zag. Dat is het Slack Code-deel. Wie een typefout op een prijzenpagina ziet, of een kapotte link, kan de fix starten vanuit het gesprek waarin het opviel. Het team kijkt mee terwijl het gebeurt, in plaats van het achteraf te lezen.
Het eerlijke deel
Er hoort één besluit bij, en dat neem je beter voordat je iets aanzet.
De rechten van Slack zijn gemaakt om te bepalen wie een kanaal mag lezen. Ze zijn niet gemaakt om te bepalen wie een terugbetaling mag goedkeuren of een live pagina mag wijzigen. Zodra systemen in Slack landen, komen die twee vragen voor het eerst samen.
Schrijf dus op wie wat mag starten, en wie het mag goedkeuren. Op rol, en niet op wie toevallig in het kanaal zit. Dat is een middag werk, en het is het verschil tussen een mogelijkheid en een incident.
Waar je begint, als je dit wilt
Niet bij de koppeling. Begin met een lijst van de vragen die je team elkaar het vaakst stelt en waar een systeem het antwoord al op weet. Waar staat deze order stil. Heeft de klant gereageerd. Staat dit live. Is die factuur eruit.
Elk van die vragen is een signaal dat je systemen al hebben en je mensen met de hand ophalen. Die lijst is je koppelbacklog, meteen op volgorde, en je schrijft hem in twintig minuten zonder één leverancier te spreken.
Pak daarna alleen de bovenste. Eén vraag die automatisch beantwoord wordt op de plek waar hij gesteld wordt, is een klein klusje met een zichtbaar resultaat. Dat vertelt je meer over de waarde hiervan dan welk plan ook.
Waar wij staan
Wij bouwen de systemen waar dit aan vastzit: back office-platformen, klantportalen, dashboards en goedkeuringsprocessen, met fijnmazige rechten voor honderden redacteuren. Wat verandert is niet wat die systemen doen. Het is dat ze niet meer hoeven te wachten tot iemand langskomt.
De interessante vraag is niet meer welke tools je hebt. Het is welke daarvan je team kunnen bereiken zonder geopend te worden.
