Wat FixControl doet
Van melding naar geteste oplossing. FixControl verbindt je supportkanalen, je documentatie en je codebase. Een melding — van een klant, of van je eigen team — wordt onderzocht met de informatie die bij het project hoort. FixControl stelt een codewijziging voor, test die in een afgeschermde sandbox en legt haar daarna aan je team voor.
Standaard gaat er niets naar je klanten, je repositories of je productieomgeving zonder een vastgelegde beslissing van een mens. Codewijzigingen komen binnen als pull request (of merge request), nooit rechtstreeks op je hoofdbranch. Automatisering die zonder mens handelt bestaat alleen waar je organisatie haar zelf aanzet, binnen grenzen die je instelt, en wordt vastgelegd.
Eerst de juiste informatie. Daarna een voorstel. Pas na controle een actie.
Twee startpunten, één route
| Startpunt | Hoe het binnenkomt | Voorbeeld |
|---|---|---|
| Een klantmelding | Per e-mail in de Inbox: je maakt er met Issue aanmaken een issue van, of laat FixControl dat per mailbox automatisch doen. Via Slack of Microsoft Teams: de bot stelt een issue voor en maakt het aan zodra iemand bevestigt. | "Sinds gisteren klopt het btw-bedrag op mijn factuur niet meer." |
| Werk dat je team zelf start | Je legt een issue vast met Nieuwe issue, je opent een werksessie direct op de codebase, of je eigen systemen maken een issue aan via de publieke API. Een supportticket is niet nodig. | Een bekende bug, een backlog-item, een intern defect. |
Tickets in Freshdesk, Linear, Odoo of TOPdesk worden niet vanzelf een issue, en Jira-tickets alleen als Nieuwe Jira-tickets als issue binnenhalen aanstaat op de Jira-koppeling van het project: FixControl maakt daar tickets aan en volgt hun status, en in Slack of Teams kun je een bestaand Jira- of Freshdesk-ticket handmatig importeren. Zie Integraties.
Daarna loopt het werk door dezelfde stappen:
- Onderzoeken — FixControl leest de melding, eerdere tickets, de documentatie die je koppelde en de repository van het project. Dit is alleen lezen.
- Voorstellen — bij riskant werk eerst een uitvoeringsplan dat iemand goedkeurt, daarna een concrete patch. Er is nog niets aangepast of verstuurd.
- Testen — de patch draait in een afgeschermde sandbox: installeren, bouwen en de tests van het project. Waar FixControl weet hoe je applicatie start, moet die ook opkomen.
- Beslissen — een bevoegde collega beoordeelt de wijziging met de testresultaten en keurt goed, wijst af of vraagt een aanpassing. Bij werk zonder risicomarkering kan dat ook de CTO Review-agent zijn, na een geslaagde test (zie hieronder).
- Opleveren — na goedkeuring open je het pull request (of doet FixControl dat direct, als het project automatisch opleveren heeft aangezet). Mergen doe je zelf, in je eigen Git-provider. Een deployment wordt alleen beïnvloed waar je dat hebt ingesteld, na een eigen goedkeuring.
Elke stap is een aparte gebeurtenis met een eigen status. Gemaakt, getest, goedgekeurd, opgeleverd als pull request, gemerged en gedeployed zijn zes verschillende dingen, en FixControl toont ze ook zo. Zie Wijzigingen opleveren.
Wat er per beslismoment gebeurt
| Moment | Standaard | Wat je kunt aanpassen |
|---|---|---|
| Een antwoord aan een klant | Een medewerker schrijft of beoordeelt het antwoord en verstuurt het zelf. De AI doet alleen een voorstel. | Per organisatie of project kan de AI concepten klaarzetten of laagrisico-antwoorden zelf versturen, binnen grenzen. Je kunt ook goedkeuring verplicht maken voor AI-antwoorden of voor elk antwoord. |
| Een uitvoeringsplan | Gevraagd bij werk met prioriteit critical of met een risicomarkering (betalingen, inloggen, beveiliging, migraties, dataverlies, persoonsgegevens, infrastructuur). | Het governance-beleid kan een plan altijd of nooit laten goedkeuren. |
| Een patch goedkeuren | Een mens beslist bij werk met een risicomarkering, als de CTO Review-agent bezwaar maakt, of als niet bewezen is dat de applicatie nog start. Bij overig werk mag de CTO Review-agent de patch goedkeuren — maar pas nadat de sandboxtest van precies die versie geslaagd is. | Wie mag beslissen, en of er meerdere goedkeuringsstappen nodig zijn. |
| Een pull request openen | Een medewerker opent het zelf, na het bekijken van titel, beschrijving en commitbericht. | Een project kan automatisch opleveren aanzetten: na goedkeuring wordt het pull request dan direct geopend. |
| Mergen | Nooit door FixControl. | — |
| Een deployment | Geen invloed. | Waar je beheerder een deploymentgate inricht, geeft een goedkeuring een gepauzeerde rollout of pijplijn vrij. |
Een patch kan alleen worden opgeleverd als de sandboxtest van die versie geslaagd is; wie daarvan afwijkt, moet een reden opgeven en die reden komt bovenaan het pull request te staan. Meer in Goedkeuringen en Wijzigingen opleveren.
Je eerste stappen
Wat je nodig hebt, hangt af van je rol.
Ben je beheerder van je organisatie? Begin met Beheerdersgids → Aan de slag als beheerder. Daar richt je in deze volgorde in:
- Een project aanmaken onder Projecten → Nieuw project.
- In dat project onder Verbindingen een mailbox of chatkanaal koppelen voor meldingen, en een repository voor code.
- Laten controleren of FixControl je applicatie kan bouwen en testen (onder Omgevingen).
- Collega's toevoegen en vastleggen wie mag goedkeuren.
Werk je met klantvragen? Lees Inbox en Antwoorden aan klanten.
Werk je aan bugs en features? Lees Issues, Werksessie en Verificatie en resultaten.
Moet je goedkeuren? Lees Goedkeuringen.
De schermen die je het meest gebruikt
| Scherm | Waarvoor |
|---|---|
| Inbox | Binnenkomende e-mail van gekoppelde mailboxen bekijken, beantwoorden en omzetten naar een issue. |
| Issues | Al het werk na intake, met prioriteit, status en de acties per soort werk. |
| Werksessies | Een chat met een AI-agent op een codebase, voor werk dat je team zelf start. |
| Goedkeuringen | Alles wat op een beslissing wacht: open poorten (plannen, codewijzigingen, deployments) en antwoorden aan klanten. Je komt er via de oranje melding … wacht op jou onder in de zijbalk, of via Meldingen. |
| Patches | Voorgestelde wijzigingen per status: te beoordelen, goedgekeurd, toegepast, afgewezen, archief. |
| Sandbox-runs | Elke testrun met zijn uitkomst en bewijs. |
| Projecten | De afbakening: welke bronnen, mensen en regels bij een stuk werk horen. |
Welke menu-items je ziet, hangt af van je werkprofiel. Een nieuw account begint met een beperkt menu; AI-resultaten zoals Patches en Sandbox-runs verschijnen zodra er iets is. Bij het profiel support heet de Inbox Klantvragen en Issues Tickets; bij engineering heet Issues Problemen en Patches Voorgestelde wijzigingen.
Kernbegrippen
- Project — een afgebakende werkomgeving. AI werkt per project met de bronnen die eraan gekoppeld zijn, niet met alles wat je organisatie heeft. Zie Projecten.
- Issue — een eenheid werk na intake, met een soort: BUG, FEATURE of SUPPORT.
- Patch — een voorgestelde codewijziging. Een patch is pas een pull request nadat hij is goedgekeurd en opgeleverd.
- Sandbox — een afgeschermde, tijdelijke omgeving waarin een patch wordt gebouwd en getest. Zie Verificatie en resultaten.
- Poort (gate) — een moment waarop het werk wacht op een vastgelegde beslissing. Zie Goedkeuringen.
- Confidence is geen risico. Confidence is hoe zeker het model van zichzelf is; risico is een apart oordeel over de gevolgen. Een zeker antwoord kan nog steeds riskant zijn — lees beide.
Wat FixControl niet is
- Geen AI die zelf zijn gang gaat. AI bereidt werk voor; standaard beslist een mens.
- Geen vervanging van je supportsoftware, je issuetracker of je Git-provider. FixControl werkt erbovenop.
- Geen garantie dat elke codebase direct te testen is. Wat FixControl niet kan bouwen of starten, benoemt het — het geeft dan geen groen resultaat. Zie Verificatie en resultaten.
Hulp nodig?
- Iets blijft hangen of wordt geweigerd → Problemen oplossen.
- Je kunt het ook vragen in het Command Center: "Is dit project klaar?", "Waar wacht men op mij?" — zie Command Center.
- Welke instellingen van jouw workspace zijn → Instellingen die je workspace zelf maakt.