Uw automatisering beschrijven in plaats van ze te programmeren

13.10.26 18:22:58

In het kort

  • Het ontwikkelaarsplatform van Zoho Cliq krijgt MCP-instrumenten: u beschrijft in gewone taal wat u wil, het platform bouwt de automatisering.
  • Bots, opdrachten met een schuine streep en planners komen zo tot stand — samen met de Deluge-functies en de gegevenstabellen eronder.
  • Widgets, de visuele tegels in een kanaal, vallen er voorlopig buiten; Zoho meldt dat ze in ontwikkeling zijn.
  • Voor een KMO of MKB-bedrijf verschuift de drempel van wie kan programmeren naar wie kan beschrijven.

Elke onderneming draagt een kerkhof van automatiseringsideeën met zich mee. Het idee zelf kost niets: een bot die de wachtdienst aankondigt, een planner die elke maandagochtend de projectstand in het juiste kanaal zet, een opdracht die een lang gesprek samenvat. Wat wél geld kost, is iemand die de logica uittekent, de code schrijft, de juiste afhandelaars kiest, de randgevallen test, en nadien uitzoekt waarom het ding dat gisteren werkte vanochtend zweeg. Die rekening wordt zelden hardop gemaakt. En dus blijven de ideeën liggen.

Zoho Cliq koppelt zijn ontwikkelaarsplatform nu aan MCP-instrumenten. U verbindt uw AI-toepassing met dat platform, beschrijft in gewone taal wat u nodig hebt, en het platform zet die beschrijving om in een werkende automatisering. Zoho noemt dat vibe coding: niet elke regel zelf schrijven, maar de uitkomst beschrijven en de uitvoering overlaten.

Van bouwstenen kiezen naar de uitkomst beschrijven

Dit is geen bocht in een weg die Cliq nog niet bewandelde. Het ontwikkelaarsplatform bood al langer paden met weinig of geen code, precies opdat wie een proces begrijpt niet zou moeten wachten op wie Deluge beheerst. Zoho verwijst daarbij naar Gartner: tegen 2025 zou 70% van de nieuwe toepassingen die organisaties bouwen op technologie met weinig of geen code draaien, tegenover minder dan 25% in 2020. Het verschil met een palet van blokken is dat u niet langer kiest uit wat voorhanden is, maar beschrijft wat u wil bereiken.

Een bot bouwen betekende tot nu toe elke gebruikersvraag vertalen naar Deluge, per afhandelaar, de webhooks aansluiten en elke stroom handmatig uittesten. Voortaan beschrijft u hoe de bot zich hoort te gedragen en zetten de MCP-instrumenten de opzet voor u klaar. Hetzelfde geldt voor opdrachten binnen een gesprek: een toegangsaanvraag indienen met /request, een lange draad samenvatten met /summarize. Suggesties helpen de gebruiker intussen naar de juiste opdracht. U past die snelkoppelingen met een beschrijving aan de werkwijze van uw team aan.

Planners volgen dezelfde lijn. De samenvatting van de campagne op vrijdag, het projectoverzicht op maandagochtend, het maandelijkse klantenrapport: u geeft aan wanneer en waarvoor, en de planner neemt de herhaling voor zijn rekening. Dat is bescheiden werk, maar het is net dat soort werk dat in een drukke week als eerste blijft liggen, en waarvan het wegvallen pas opvalt wanneer iemand achteraf om cijfers vraagt.

De motor onder de knoppen

Het zichtbare deel van een automatisering is zelden het bewerkelijke deel. Wie ooit een eenvoudige bot opleverde, weet dat de knop in tien minuten staat en de rest in twee dagen. Daarom is het vermeldenswaard dat Zoho het onderliggende werk meeneemt: vraagt u om een bot, een planner of een berichtactie, dan bouwt het platform meteen ook de Deluge-functies die ze aandrijven en de gegevenstabellen waarin ze hun gegevens bewaren. Niet als een tweede ronde waar u later op terugkomt.

Wat er nog niet bij hoort, is even belangrijk om te weten. Widgets — de visuele tegels die in een kanaal leven — vallen voorlopig buiten deze aanpak. Zoho meldt dat het aansturen van widgets als boordtabellen in ontwikkeling is. Wie vandaag een visuele weergave in een kanaal nodig heeft, bouwt die dus nog op de gewone manier. Over de bredere opzet van de toepassing leest u meer op de productpagina van Zoho Cliq.

Wat dit betekent voor een KMO of MKB-bedrijf

Zoho richt zich hiermee uitdrukkelijk niet op de ontwikkelaar die liever zelf de editor opent. Het doelpubliek is de helpdeskverantwoordelijke die precies weet hoe een escalatie hoort te lopen maar nooit een functie schreef, en de operationeel verantwoordelijke die een planner wil zonder een ticket in te dienen dat maanden in een achterstand blijft liggen. In een onderneming van vijftien of vijftig mensen zijn dat net de mensen die het proces het best kennen.

Daar zit tegelijk de kern van de zaak. De moeilijkheid verhuist, ze verdwijnt niet. Wie niet nauwkeurig kan beschrijven wat er moet gebeuren, krijgt een automatisering die nauwkeurig iets anders doet. Een escalatie die na twee uur doorschakelt is iets anders dan een escalatie die na twee werkuren doorschakelt, en het verschil merkt u op een vrijdagavond. Beschrijven is een vaardigheid, geen omweg rond vaardigheid.

Daarbij hoort een tweede voorzorg, en die is in België en Nederland zelden vrijblijvend. Een automatisering die zelf tabellen aanmaakt, bewaart gegevens. Wie mag daarin kijken, hoe lang blijven die gegevens staan, en staat er iemand met zijn naam onder? Spreek vooraf af wie een automatisering in productie mag zetten en waar ze genoteerd staat. Wie sneller bouwt dan hij kan nakijken, ruilt een achterstand in uren om voor een achterstand in overzicht. Dat is geen reden om het niet te doen; het is een reden om er bij de start een afspraak over te maken.

Veelgestelde vragen

Moet ik nu helemaal geen Deluge meer kennen?

Niet om te beginnen, wel om te beoordelen. Het platform schrijft de Deluge-functies en maakt de tabellen aan, dus u kunt een bot of planner opleveren zonder zelf een regel te typen. Zodra iets zich anders gedraagt dan verwacht, helpt het enorm als iemand in huis kan lezen wat er gebouwd is. Zoho zegt het zelf: dit vervangt de ontwikkelaar niet die de editor wil openen. Ons advies aan KMO's is pragmatisch: laat de mensen die het proces kennen bouwen, en spreek af wie het nakijkt.

Waar begin ik het best mee?

Met iets dat herhaalt en waarvan de uitkomst zichtbaar is. Een planner die elke maandag hetzelfde overzicht in hetzelfde kanaal zet, is een goede eerste keuze: de werking is meteen te controleren en een fout richt geen schade aan. Een bot die rechtstreeks in een klantproces ingrijpt, bewaart u voor later. Zo bouwt u vertrouwen op in de aanpak vóór u er iets aan ophangt waar een klant op wacht, en leert uw team meteen hoe nauwkeurig een beschrijving moet zijn.

Hoe weet ik of de automatisering doet wat ik bedoelde?

Door ze te beschrijven in termen die u achteraf kunt natellen. Een goede beschrijving bevat de aanleiding, het moment, de ontvanger en de uitzondering. Test daarna met een geval dat u op voorhand uitgerekend hebt: wat zou er vandaag precies gebeurd zijn? Dat is dezelfde zorgvuldigheid die u bij een werkstroom in uw verkoopdossier zou hanteren. Het verschil is dat de bouwtijd kort is, waardoor de verleiding groter wordt om die stap over te slaan.

Geldt dit ook voor visuele weergaven in een kanaal?

Voorlopig niet. Widgets, de visuele tegels binnen een kanaal, maken nog geen deel uit van deze werkwijze; Zoho meldt dat het aansturen ervan als boordtabel in ontwikkeling is. Wie vandaag cijfers in een kanaal wil tonen, bouwt die weergave dus op de bestaande manier. Houd daar rekening mee bij het plannen: een bot of planner kunt u nu al laten bouwen, een visuele tegel plant u beter als een aparte stap, zodat uw tijdlijn niet afhangt van een aankondiging.

Wat betekent dit voor onze gegevens en voor de AVG?

Een automatisering die zelf tabellen aanmaakt, maakt ook nieuwe bewaarplaatsen aan. Dat is op zich niets bijzonders, maar het vraagt dezelfde discipline als elke andere gegevensbron: weten welke persoonsgegevens er terechtkomen, wie toegang heeft en hoe lang ze bewaard blijven. Voor ondernemingen in België en Nederland is dat geen formaliteit maar een verplichting. Neem die automatiseringen op in hetzelfde register als uw overige toepassingen, en wijs per automatisering iemand aan die er verantwoordelijk voor is.