← Terug naar index
Embrace Customers · Productteam · Conceptfase
Datamodel ZGW 2.0
Zaak-georiënteerd werken in Embrace Customers. Een herontwerp van de kernobjecten — gebouwd rondom de huurder als gravitatiepunt, met duidelijke eigenaarschap, transparantie en AI-readiness.
v0.3 — canoniek April 2026 Edwin Cnossen · Product Management Conceptfase
Sectie 1
Aanleiding & probleemstelling

Embrace Customers is de afgelopen jaren gegroeid tot een volwaardig CRM voor corporaties en woningverhuurders. Gaandeweg zijn er structurele keuzes in het datamodel geslopen die niet bewust zijn gemaakt, maar die de dagelijkse werking onnodig belasten.

1.1 Drie concrete knelpunten
Knelpunt 1
Elke conversatie = ticket
Nooit bewust zo bedacht. Lichte contactmomenten krijgen dezelfde overhead als formele werkitems. Medewerkers belast met onnodige administratie.
Knelpunt 2
Ticket zonder eigenaar of deadline
Een losse taak is altijd nodig als workaround. Dubbele registratie, onduidelijke verantwoordelijkheid en verlies van overzicht zijn het gevolg.
Knelpunt 3
Portaal toont statische info
Huurders zien geen status, geen eigenaar, geen deadline. De meest gestelde vraag — "Hoe staat het er mee?" — wordt niet beantwoord.
1.2 Kern van het probleem

Het huidige model maakt geen onderscheid tussen een communicatiemoment (iets wat is gezegd) en een werkitem (iets wat gedaan moet worden). Alles wordt op één hoop gegooid als 'ticket', waardoor noch het communicatiekanaal noch het werkproces goed bediend wordt.

Sectie 2
Het nieuwe model — overzicht

Een herontwerp van de kernobjecten, gebaseerd op de bewezen structuur van Intercom maar doorvertaald naar de wereld van corporaties. Het model maakt een heldere scheiding tussen communicatie, werk en proces.

Object Wat is het? Zichtbaar voor huurder? Tijdlijn-niveau
📁 Dossier Langdurig archivaal dossier — afzonderlijk van Verzamelzaak; juridisch, exporteerbaar, meerdere huurders Nee — intern Niet op tijdlijn
📦 Verzamelzaak Groepeert meerdere zaken, broadcast-functie Nee — intern Niet op tijdlijn
💬 Conversatie Elk contactmoment, elk kanaal Ja — op tijdlijn Zaak-inhoud
📋 Zaak Formeel werkitem met eigenaar en deadline Ja — met status Zaak-inhoud
🔄 CaseFlow Procesmotor op een Zaak — sequentiële stappen elk zichtbaar in mijnomgeving Ja — voortgang zichtbaar Zaak-inhoud
🌐 Zaakscenario Self-service beslisboom met logica, genereert een Zaak Ja — huurder doorloopt zelf Zaak-inhoud (start)
⚙️ Opdracht Werkorder in extern systeem, statusupdates keren terug in Embrace Ja — statusupdates Zaak-inhoud
🗨️ Ruggespraak Intern overleg in context van zaak/conversatie Nee — intern Zaak tijdlijn
🔗 Gerelateerde zaken Ad-hoc koppeling tussen zaken Nee — intern Zaak tijdlijn
🔒 Interne Zaak Intern werkitem zonder klantcontact, uitkomst beïnvloedt huurder indirect Nee — intern Zaak tijdlijn (cross-post)
📨 Side conversation Externe communicatie in context van zaak — naar derde partij Nee — extern naar derde Zaak tijdlijn
2.1 Vier klantzaak-patronen

Elke zaaksituatie past in één van vier patronen. Het patroon bepaalt de structuur, niet het zaaktype. De patronen zijn geen aparte objecten — het zijn architect-patronen die beschrijven hoe Zaken aan elkaar zijn gerelateerd.

1
Zaak
Enkelvoudig
Één Zaak, één huurder, één eigenaar. De basisvorm. Geen koppeling met andere zaken nodig. Zichtbaar als individueel werkitem op de huurder-tijdlijn.
📋 Zaak
2
Gerelateerde Zaak
Bidirectioneel
Twee of meer zaken zijn ad-hoc aan elkaar gekoppeld — gelijkwaardig, geen hiërarchie. Medewerker ziet de samenhang; huurder ziet zijn eigen zaak.
📋 Zaak A 📋 Zaak B
3
Verzamelzaak
Fan-out · Broadcast
Eén overkoepelende Verzamelzaak met meerdere onderliggende Zaken (één per huurder). Broadcast-functie: één update bereikt alle gekoppelde huurders tegelijk.
📦 Verzamelzaak📋 n× Zaak
4
Zaakflow
CaseFlow · Sequentieel
Een overkoepelende Zaak met een CaseFlow die sequentiële stap-Zaken aanstuurt. Elke stap is zichtbaar voor de huurder. Pas als alle stappen klaar zijn, sluit de hoofdzaak.
📋 Zaak + 🔄 CaseFlow
Sectie 3
De objecten in detail
💬 Conversatie

Een conversatie is elk contactmoment tussen een huurder en de organisatie, ongeacht het kanaal. Een conversatie is licht van aard: het registreert dat er contact is geweest, maar verplicht niemand tot verdere actie. Pas als er opvolging nodig is, wordt er bewust een zaak van gemaakt.

Elk kanaal: telefoon (via Unexus), chat, email, balie of handmatig
Altijd zichtbaar op de tijdlijn van de huurder
Voorzien van een AI-samenvatting (automatisch via Unexus, of handmatig ingevoerd)
Heeft Ruggespraak als onderdeel — intern overleg altijd in context van de conversatie
Kan handmatig worden omgezet naar een Zaak — bewust triggermoment
Gecategoriseerd via een kennisbank-item
Voorbeeld — Telefonisch contact
Een huurder belt om te vragen of zijn betaling ontvangen is. De medewerker beantwoordt de vraag direct. Unexus legt het gesprek vast en stuurt een AI-samenvatting naar de tijdlijn. Er is geen zaak nodig — afgerond contactmoment.
Voorbeeld — Conversatie wordt Zaak
Dezelfde huurder belt opnieuw: zijn cv-ketel doet het niet. De medewerker zet dit om naar een Zaak, kent eigenaar toe (technische dienst), stelt deadline in (48 uur) en koppelt een CaseFlow 'Reparatieverzoek'. De conversatie blijft zichtbaar als het oorspronkelijke contactmoment.
📁 Dossier

Een Dossier is de hoogste container in het model — een langdurig, thematisch archief dat alles bundelt wat relevant is voor een specifiek traject. In tegenstelling tot een Zaak of Verzamelzaak heeft een Dossier geen operationeel karakter: het documenteert en bewijst. Een Dossier kan meerdere huurders bevatten en is ontworpen om te worden geëxporteerd voor juridische doeleinden.

Thematisch: Leefbaarheid, Onderhoud complex, Juridisch traject
Kan meerdere huurders bevatten — klagers én veroorzakers in één dossier
Bevat Zaken en Conversaties; archiveert alle relevante klantinteracties
Exporteerbaar als volledig bewijsdossier (chronologisch)
Statussen: Open / Juridisch traject / Gesloten
StatusBetekenis
OpenDossier is actief en in opbouw — zaken en conversaties worden toegevoegd
GeslotenTraject afgerond. Uitkomst bereikt en dossier gearchiveerd
Voorbeeld — Leefbaarheidsdossier
Meerdere klachten over overlast in portiek 3, complex Stationsweg. Dossier 'Leefbaarheid Stationsweg 12-24' aangemaakt. Na drie maanden en twee waarschuwingen escaleert naar 'Juridisch traject'. De jurist exporteert het volledige dossier als PDF voor de rechter.
📋 Zaak

De Zaak is het centrale werkitem in het nieuwe model. Het vervangt het huidige 'Ticket' en is een volwaardig object met alle eigenschappen om werk te sturen, bewaken en afsluiten. De naam 'Zaak' sluit aan op de taal die corporaties al dagelijks gebruiken.

Heeft altijd een eigenaar, deadline, status en type
Wordt altijd aangemaakt via een Zaakscenario — de verplichte poort
Heeft Ruggespraak als onderdeel — intern overleg altijd in zaak-context
Kan een CaseFlow dragen voor gestructureerde processen (Zaakflow-patroon)
Altijd zichtbaar voor de huurder — harde regel. Alleen een Interne Zaak is nooit zichtbaar
StatusBetekenis
IngediendZaak is aangemaakt maar nog niet opgepakt
In behandelingZaak is toegewezen en er wordt aan gewerkt
Wacht op huurderHuurder moet informatie aanleveren of actie ondernemen
Wacht op derdeWachten op een externe partij (bijv. aannemer)
OpgelostZaak is afgerond
Voorbeeld — Proactieve Zaak zonder conversatie
Technische dienst plant jaarlijkse rookmelderscontrole. Medewerker maakt direct een Zaak aan, koppelt CaseFlow 'Jaarlijkse controle', stelt deadline in. De huurder ziet de zaak verschijnen in zijn portaal met status 'Ingediend'.
🗨️ Ruggespraak

Intern overleg dat plaatsvindt binnen de context van een Zaak of Conversatie. Zichtbaar voor collega's, nooit voor de huurder. De interne discussie blijft altijd bij de zaak — niet verspreid over losse berichten of e-mails.

Snel & gericht — @mentions
Directe interne notitie in de zaak-context. Tag een collega, die ontvangt een melding en reageert in dezelfde context.
Breed bereik — social intranet
Notificatie naar juiste mensen of teams in de organisatie. Antwoord landt terug in de zaak — CRM-context blijft compleet.
📦 Verzamelzaak

Een Verzamelzaak groepeert meerdere Zaken onder één overkoepelend overzicht. Intern werkitem — de huurder ziet de Verzamelzaak zelf niet. De kracht zit in de broadcast-functie: vanuit één Verzamelzaak update je in één keer alle gekoppelde huurders.

Altijd intern — nooit zichtbaar voor de huurder
Broadcast-functie: één update wordt doorgezet naar alle gekoppelde Zaken
Statuswijziging wordt cross-posted naar alle gekoppelde Zaken
Voortgangsoverzicht: hoeveel zaken afgerond, hoeveel lopen nog?
Reactief
Meerdere huurders melden hetzelfde probleem. Medewerker maakt Verzamelzaak aan en koppelt individuele zaken.
Proactief (vanuit Complex)
Medewerker kiest een complex, selecteert CaseFlow-template → automatisch een Zaak per huurder, gekoppeld aan de Verzamelzaak.
Voorbeeld — CV-storing
Centrale ketel in complex Carolieweg defect. Tien huurders geraakt. Verzamelzaak 'CV-storing Carolieweg' aangemaakt met tien individuele Zaken. Na reparatie één broadcast: 'De storing is verholpen.' — alle tien huurders ontvangen update via eigen zaak en portaal.
Voorbeeld — Huurmutatie complex
In complex Beatrixlaan vertrekken vijf huurders in dezelfde periode. Verzamelzaak 'Huurmutaties Beatrixlaan Q2' aangemaakt. Per woning wordt automatisch een Zaak aangemaakt met een CaseFlow 'Huurmutatie' — stappen: Huuropzegging verwerken → Inspectie plannen → Reparaties uitvoeren → Nieuwe verhuur starten. De beheerder bewaakt alle vijf mutatietrajecten vanuit één Verzamelzaak en ziet direct welke woningen achterlopen op planning.
🔗 Gerelateerde zaken

Lichtgewicht koppelingsmechanisme waarmee twee of meer Zaken aan elkaar worden gelinkt zonder formele hiërarchie. Zaken blijven volledig zelfstandig maar zijn voor de medewerker zichtbaar als samenhangend.

Gerelateerde zakenVerzamelzaak
StructuurGelijkwaardig, geen hiërarchieParent/child hiërarchie
DoelAd-hoc koppeling samenhangende zakenOverzicht en broadcast
AanmakenDirecte koppeling tussen twee zakenBewust aangemaakt als overkoepelend object
BroadcastNiet van toepassingJa — één update naar alle zaken
🔒 Interne Zaak

Een intern Embrace-object voor corporatieteams die werken aan een dossier zonder direct klantcontact, maar waarvan de uitkomst direct bepaalt wat er met de huurder of diens Zaak gebeurt. Zeldzaam en precies afgebakend.

Nooit zichtbaar voor de huurder — harde regel, ongeacht zaaktype
Eigen eigenaar, deadline en status — gescheiden van klantcommunicatie
Statuswijzigingen worden cross-posted naar de gekoppelde Zaak of Conversatie
Aangemaakt door het specialistteam zelf — niet door front-desk
⚠ Scope-afbakening — Interne Zaak vs. back-office werk
Wél een Interne Zaak: juridische aansprakelijkheidsbeoordeling, fraudecheck, urgentiebeoordeling bij wachtlijst — intern werk waarvan de uitkomst direct de huurder of diens zaak beïnvloedt.

Geen Interne Zaak: Work Orders in Connect-it 365, Invoices in Tobias365, factuurverwerking, leveranciersdisputen, budgetgoedkeuringen corporatie↔leverancier. Die horen volledig in Tobias365 F&O.
📨 Side conversation

Een externe communicatielijn vanuit een Zaak naar een derde partij — aannemer, notaris, andere corporatie of gemeente. Aparte thread, gekoppeld aan de zaak, volledig onzichtbaar voor de huurder.

Extern — gericht naar een partij buiten de eigen organisatie
Altijd gekoppeld aan een Zaak — context blijft bewaard
Antwoorden van externe partij landen terug in de Zaak-context
Verschil met Ruggespraak: Ruggespraak = intern (collega's); Side conversation = extern (derden)
Embrace Customers ondersteunt al het koppelen van een emailbox. Via die koppeling stuurt een medewerker vanuit een Zaak direct een email naar een externe partij. De emailthread is zichtbaar in de context van de Zaak.
🌐 Portaal

In het nieuwe model wordt het portaal dynamisch: de huurder ziet actuele status, voortgang en verwachte afhandeling in plaats van statische historische informatie.

Huidig portaalNieuw portaal
ContactmomentenArchiefTijdlijn met AI-samenvatting
ZaakstatusNiet zichtbaarZichtbaar (Ingediend / In behandeling / Opgelost)
VoortgangGeenCaseFlow-voortgang (stap 2 van 7)
VerwachtingNiet gecommuniceerdDeadline zichtbaar als belofte
Effect: De meest gestelde vraag bij corporaties is "Hoe staat het er mee?" — een dynamisch portaal beantwoordt die vraag zonder dat de huurder hoeft te bellen. Dit vermindert direct de inbound contactdruk.
🔄 CaseFlow

CaseFlow is een procesmotor die op een Zaak draait. Het definieert de levenscyclus van een Zaak als een reeks opeenvolgende stappen. Elke stap kan automatisch een nieuw object genereren of handmatig worden afgerond.

Sequentieel — stap wordt pas actief zodra de vorige is afgerond
Elke stap genereert een object: een nieuwe Zaak, een Conversatie of een Opdracht
Altijd zichtbaar in mijnomgeving — huurder ziet stapnaam en status
CaseFlow stappen genereren nooit een Interne Zaak — intern werk wordt parallel aangemaakt buiten de flow
Zichtbaarheidsregel CaseFlow
CaseFlow-stappen genereren uitsluitend reguliere Zaken, Taken of Opdrachten — nooit Interne Zaken. Als intern werk nodig is dat de huurder niet ziet, wordt dit als Interne Zaak parallel aangemaakt — gekoppeld aan de CaseFlow-Zaak, maar buiten de zichtbare flow.
Voorbeeld — Huurder onboarding (CaseFlow)
Stap 1: Welkomstgesprek plannen → genereert Conversatie
Stap 2: Sleuteloverdracht → genereert Zaak, eigenaar Verhuur
Stap 3: Contract ondertekenen → genereert Zaak (juridisch, eigenaar Contractbeheer)
Stap 4: Portaal activeren → genereert Zaak (eigenaar Administratie)
Parallel (buiten CaseFlow): kredietcheck → Interne Zaak, volledig intern, nooit zichtbaar voor huurder
🌐 Zaakscenario

De universele startmotor van elke Zaak in Embrace Customers. Elke Zaak wordt aangemaakt via een Zaakscenario — hoe eenvoudig of complex ook. Het Zaakscenario leest context, doorloopt beslislogica, en maakt op basis daarvan een Zaak aan met de juiste eigenschappen.

Van SSS naar Zaakscenario: "Self Service Scenario" dekt slechts een deel van de lading — het suggereert dat alleen huurders het starten. In ZGW 2.0 gebruiken medewerkers dezelfde logica intern. De nieuwe naam benoemt de uitkomst: altijd een Zaak.

De vier varianten:

Minimaal — categorie kiezen uit zaaktaxonomie, optioneel notitie. Maximale vrijheid voor ad-hoc registratie.
Gestructureerd — intake met verplichte velden en context. Zaak aangemaakt met juiste eigenschappen en routing.
Geautomatiseerd — beslisboom loopt end-to-end. Zaak aangemaakt én gesloten. Eventueel met ERP-mutatie of Opdracht.
CaseFlow-starter — intake maakt Zaak aan én start CaseFlow. Voor complexe processen (huuropzegging, klachtafhandeling).
🔔 Notificatiesysteem

Het notificatiesysteem is het zenuwstelsel van ZGW 2.0. Het zorgt ervoor dat de juiste partij — huurder of medewerker — op het juiste moment gesignaleerd wordt over relevante zaakgebeurtenissen. Er zijn twee fundamenteel verschillende richtingen, elk met een eigen doel en een eigen kanaalset.

Al operationeel: De infrastructuur is aanwezig via het social intranet. Wat nog gebouwd moet worden is de koppeling van zaak-events als triggers naar de notificatielaag — voor beide richtingen.
🔔 Notificatiecentrum — intern instrument voor de medewerker

Het notificatiecentrum is het persoonlijke signaleringscentrum van de medewerker binnen het CRM. Het staat bewust los van de Inbox — de Inbox is voor inkomende berichten van huurders, het notificatiecentrum is voor alles wat intern relevant is voor de medewerker. De medewerker ziet in één oogopslag wat zijn aandacht vraagt, zonder zijn inbox te hoeven doorzoeken.

TriggerWanneerKanaal
Zaak toegewezen aan jouDirect🔔 Notificatiecentrum
@mention in zaak of ruggespraakDirect🔔 Notificatiecentrum
Nieuwe zaak in jouw groepDirect🔔 Notificatiecentrum
Deadline nadert (< 24 uur)Tijdgestuurd🔔 Notificatiecentrum
Deadline overschredenDirect🔔 Notificatiecentrum
Zaakstatus gewijzigd (gevolgde zaak)Direct🔔 Notificatiecentrum
CaseFlow-stap wacht op jouDirect🔔 Notificatiecentrum
Interne Zaak afgerond (cross-post)Direct🔔 Notificatiecentrum
Huurder heeft gereageerd via portaalDirect🔔 Notificatiecentrum
AI-signaal (zie onder)Patroongestuurd🔔 Notificatiecentrum
📬 Huurder-notificaties — proactieve communicatie naar de huurder

De huurder hoeft niet meer te bellen om te weten wat er met zijn zaak gebeurt. ZGW 2.0 stuurt de huurder proactief een notificatie op elk relevant moment in zijn zaaktraject. De huurder kiest zijn voorkeurskanaal; Embrace zorgt dat het bericht via dat kanaal aankomt.

TriggerKanalen (huurder kiest voorkeur)
Zaak aangemaakt / ontvangstbevestiging SMS Mijn omgeving
Zaakstatus gewijzigdMijn omgeving App-push
CaseFlow-stap voltooidMijn omgeving App-push
Afspraakbevestiging SMS App-push
Afspraakherinnering (dag vóór)SMS App-push
Zaak afgerond / opgelost SMS Mijn omgeving
Actie vereist van huurder SMS App-push
Document beschikbaar (bijv. eindafrekening) Mijn omgeving

Kanaaloverzicht: SMS voor urgente, tijdgebonden berichten. voor inhoudelijke berichten met bijlagen of documenten. App-push voor huurders die de Embrace-app gebruiken. Mijn omgeving als basislijn — altijd beschikbaar via het portaal, ongeacht voorkeurskanaal.

Notificatiecentrum
🔔 @mention in zaak of ruggespraak
📋 Zaak aan mij toegewezen
⚠️ Deadline-alert (< 24 uur)
👥 Nieuwe zaak in mijn groep
🔄 CaseFlow-stap wacht op mij
💬 Huurder reageerde via portaal
Huurder-notificaties
📬 Ontvangstbevestiging zaak
📊 CaseFlow voortgangsupdate
📅 Afspraakbevestiging + herinnering
✅ Afsluitbericht bij oplossing
📄 Document beschikbaar
⚡ Actie vereist van huurder
AI-signalen (Visie)
🤖 Zaak staat > X dagen stil zonder actie
🔍 Patroon herkend: vergelijkbare zaak eerder
📈 Huurder heeft meerdere openstaande zaken
⚠️ Deadline-risico op basis van zaaktype
💡 Voorgestelde actie op basis van zaakhistorie
Ontwerpprincipes
Inbox ≠ Notificatiecentrum. De Inbox is uitsluitend voor inkomende berichten van huurders. Het notificatiecentrum is het interne signaleringscentrum voor de medewerker — mentions, toewijzingen, deadlines, procesvoortgang.

Huurder-notificaties zijn altijd event-driven. Ze worden getriggerd door een objectwijziging in Embrace — niet door periodieke push-berichten zonder aanleiding. De huurder ontvangt alleen berichten over zaken die al zichtbaar zijn in zijn portaal.

AI-signalen zijn proactief, niet reactief. Ze worden niet getriggerd door één event maar door een patroon — een combinatie van tijd, zaaktype, historie en context. Ze zijn uitsluitend zichtbaar in het Notificatiecentrum voor de medewerker, nooit richting de huurder.

Ruggespraak blijft intern. @mentions in interne ruggespraken bereiken de huurder nooit — ook niet als de huurder toegang heeft tot het portaal.
Sectie 4
De huurder als middelpunt

In het nieuwe model is de huurder het organiserende principe. Alle objecten zijn gekoppeld aan een huurder en verschijnen op diens tijdlijn.

Over de niveaus 1–5: De niveaus beschrijven de containment-diepte in de objecthiërarchie — hoe hoog of diep een object in de neststructuur zit. Ze staan volledig los van CaseFlow-stap nummers. Een CaseFlow kan 3, 7 of 12 stappen hebben — dat heeft geen relatie met deze niveauindeling.
NiveauObjectKarakter
1 — Archivaal📁 DossierLangdurig, thematisch, juridisch, exporteerbaar — apart van Verzamelzaak
2 — Groep📦 VerzamelzaakProbleem-gedreven, broadcast, tijdelijk
3 — Werkitem📋 ZaakFormeel werkitem, eigenaar, deadline, status
4 — Communicatie💬 ConversatieContactmoment, elk kanaal, tijdlijn
4 — Procesmotor🔄 CaseFlowSequentiële stappen op een Zaak — elke stap zichtbaar
5 — Self-service🌐 ZaakscenarioBeslisboom met logica, genereert Zaak of Opdracht
5 — Integratie⚙️ OpdrachtWerkorder in extern systeem, status sync naar tijdlijn
5 — Intern overleg🗨️ RuggespraakIn-context, @mentions of via intranet — nooit zichtbaar voor huurder
Dwarsverband🔗 Gerelateerde zakenAd-hoc koppeling, gelijkwaardig
Dwarsverband🔒 Interne ZaakIntern werkitem, cross-posting naar zaak-tijdlijn
Dwarsverband📨 Side conversationExtern overleg in context van zaak, naar derde partij
4.1 Tijdlijn — twee niveaus

De tijdlijn op een Zaak bestaat uit twee duidelijk gescheiden niveaus. Het onderscheid is niet instelbaar per item — het volgt uit het type object.

Zaak-inhoud
Zichtbaar voor huurder én medewerker
📋
Zaak aangemaakt / gesloten
Start- en sluitmoment van de zaak op de tijdlijn
🔄
CaseFlow stappen
Elke stap met naam en status — voortgang altijd zichtbaar in mijnomgeving
💬
Conversaties
Contactmomenten met kanaalmarkering en AI-samenvatting
⚙️
Opdracht-statusupdates
Wanneer een externe werkorder van status wisselt (bijv. aannemer ingepland)
🌐
Portaal geactiveerd
Zaakstatus, deadline en CaseFlow-voortgang zichtbaar voor huurder
Zaak tijdlijn
Alleen intern — alleen medewerker
🔀
Statuswijzigingen
Interne status-overgangen vastgelegd voor de medewerker
🗨️
Ruggespraak
Intern overleg via @mentions of social intranet — nooit zichtbaar voor huurder
🔒
Interne Zaak events
Signalen van gekoppelde Interne Zaken (bijv. juridische beoordeling afgerond)
🔗
Systeemkoppelingen
Events vanuit T365 of CIT via Dataverse — intern signaal, niet op huurder-tijdlijn
Harde scheiding — geen uitzonderingen
Conversaties en CaseFlow-stappen horen in de Zaak-inhoud — zichtbaar voor huurder én medewerker. Ze mogen niet worden verplaatst naar de interne tijdlijn.

Ruggespraak en Interne Zaak-signalen horen altijd in de Zaak tijdlijn — nooit zichtbaar voor de huurder. Dit is geen instelling maar een eigenschap van het object.
4.2 Zichtbaarheidsregels

Het zaaktype bepaalt de zichtbaarheid — niet een instelling per zaak. Het leidende principe:

Positief principe
Alles wat in een Zaak zit, is zichtbaar voor de huurder — tenzij het objecttype dit uitsluit. De uitzondering staat vast in het model; het is geen vrije instelling per item.
Reguliere Zaak — altijd zichtbaar voor de huurder. Geen instelling, geen uitzondering.
CaseFlow stappen — altijd zichtbaar voor de huurder (onderdeel van Zaak-inhoud).
Conversatie — altijd zichtbaar op tijdlijn, tenzij intern gemarkeerd via "Intern"-tag.
Opdracht statusupdates — zichtbaar op huurder-tijdlijn zodra status van het externe systeem wijzigt.
Interne Zaak — nooit zichtbaar voor de huurder. Harde regel, geen uitzondering.
Ruggespraak — nooit zichtbaar voor de huurder. Intern overleg blijft intern.
Side conversation — nooit zichtbaar voor de huurder. Extern naar derde partij, niet naar huurder.
Harde Regel 5 — Embrace scope-filter
Alles in Embrace Customers heeft directe relevantie voor de huurder. Administratieve verwerking zonder huurder-impact (facturen van aannemers, leveranciersdisputen, budgetgoedkeuringen corporatie↔leverancier) hoort in Tobias365 F&O en wordt nooit gesynchroniseerd naar Embrace. Een factuur van een aannemer hoort niet op de tijdlijn. Een eindafrekening richting de huurder wél.
4.3 Harde Regels — compleet overzicht

Alle vijf harde regels van ZGW 2.0 op één plek. Deze regels zijn niet instelbaar — ze zijn eigenschap van het model.

1
Reguliere Zaak is altijd zichtbaar voor de huurder
Geen instelling, geen uitzondering. Als iets een reguliere Zaak is, verschijnt het op de huurder-tijdlijn. Wil je het intern houden? Gebruik dan een Interne Zaak.
2
Interne Zaak is nooit zichtbaar voor de huurder
Ongeacht zaaktype of status — een Interne Zaak raakt nooit de huurder-tijdlijn direct. Wel kan een cross-post-event op de Zaak tijdlijn (intern niveau) verschijnen voor de medewerker.
3
CaseFlow-stappen zijn altijd zichtbaar voor de huurder
Elke stap binnen een CaseFlow is zichtbaar in de mijnomgeving — naam en status. Dit is de voortgangsbelofte naar de huurder. Een CaseFlow die intern werk regelt zonder klantinteractie hoort thuis als Interne Zaak, niet als CaseFlow-stap.
4
CaseFlow stappen genereren nooit een Interne Zaak
CaseFlow = klantproces. Interne Zaak = intern werk. Ze worden nooit gemengd. Als een CaseFlow-stap intern werk uitlokt (bijv. een juridische beoordeling), wordt dat als een parallelle Interne Zaak aangemaakt — buiten de zichtbare CaseFlow.
5
Embrace scope-filter — alleen huurder-relevante data
Alles in Embrace Customers heeft directe relevantie voor de huurder. Administratieve verwerking zonder huurder-impact (facturen aannemers, leveranciersdisputen, budgetgoedkeuringen) hoort in Tobias365 F&O. Een factuur van een aannemer hoort niet op de tijdlijn. Een eindafrekening richting huurder wél.
4.4 Dataverse integratiebrug

Tobias365 (financiën/ERP) en Connect-it 365 (vastgoed/onderhoud) draaien op Dataverse — het Microsoft integratieplatform. Via een Dataverse-brug kunnen events vanuit deze systemen als tijdlijn-signalen in Embrace Customers verschijnen. Het gaat om leesbare events, niet om nieuwe objecten.

Dataverse integratiestroom
T365 / CIT Dataverse event Zaak tijdlijn (intern)
Events uit T365 of CIT reizen als tijdlijn-events naar de klantkaart in Embrace. Ze worden geen objecten in Embrace — er wordt geen Zaak of Interne Zaak aangemaakt. De medewerker ziet het signaal op de interne zaak-tijdlijn zonder naar T365 of CIT te navigeren.

Voorbeeld: Een Work Order in Connect-it 365 wordt ingepland voor morgen 14:00. Dit event verschijnt als "Monteur ingepland — 12 april 14:00" op de Zaak tijdlijn in Embrace. De huurder ziet dit via de Opdracht-statusupdate op de Zaak-inhoud tijdlijn.
Wél via Dataverse brug
Work Order statusupdates (CIT), inspectiedatums (CIT), incasso-stappen (T365), eindafrekening-events (T365 → huurder-impact)
Niet via Dataverse brug
Leveranciersfacturen, budgetgoedkeuringen, inkooporders, interne boekhoudmutaties zonder huurder-gevolg — die blijven in T365 F&O
4.5 VERA ketenstandaarden

VERA is de sectorstandaard voor woningcorporaties — een set OpenAPI-definities die de informatieuitwisseling tussen corporatiesystemen beschrijft. ZGW 2.0 sluit aan op de relevante VERA-domeinen. De mapping bepaalt welk object in Embrace correspondeert met welk VERA-contract.

VERA Domein Afkorting ZGW 2.0 object(en) Toelichting
BDO Casemanagement BDO 📋 Zaak 🔄 CaseFlow Het kerndomein voor zaakgericht werken — meest relevante standaard voor ZGW 2.0
VHE Verhuren VHE 📋 Zaak (Huur opzeggen, Woning betrekken) Klantreis Huur opzeggen en Woning betrekken vallen onder dit domein
OHD Onderhoud OHD ⚙️ Opdracht 📋 Zaak Reparatieverzoeken, inspecties, Work Orders in CIT — Opdracht-object als brug
INC Incasso INC 📋 Zaak 📁 Dossier Betalingsregelingen, incasso-dossiers — raakt T365 F&O via Dataverse
WRV Woonruimteverdeling WRV 📋 Zaak (Urgentie) Urgenties, kandidaat-selectie — Interne Zaak-patroon voor beoordeling
Interface-contract: VERA definieert de API-specificaties waarmee Embrace, Tobias365 en Connect-it 365 met elkaar communiceren. Wanneer ZGW 2.0 objecten aanmaken of muteren die raken aan een VERA-domein, dient de implementatie de bijbehorende OpenAPI-definitie te volgen.
Sectie 5
Uitgewerkte klantreizen

De volgende klantreizen zijn volledig uitgewerkt als ZGW 2.0 klantreis — met stappenoverzicht, objectgebruik, VERA-koppeling en portaalervaring. Elke klantreis is een levend document en onderdeel van de ZGW 2.0 documentatieset.

Sectie 6
De weg naar agentisch werken

Het nieuwe datamodel is niet alleen een verbetering voor vandaag — het is het fundament voor de volgende stap: AI-agenten die zelfstandig taken uitvoeren, zaken aanmaken en processen bewaken.

Zaak-aanmaak — AI-agent herkent type melding vanuit conversatie en voert automatisch het juiste Zaakscenario uit
Proactieve Verzamelzaak — agent monitort signalen (meerdere meldingen zelfde complex) en maakt automatisch een Verzamelzaak aan boven drempelwaarde
Deadline-bewaking — agents sturen automatisch herinneringen of escaleren bij overschrijding
Intelligente routing — inkomende conversaties geclassificeerd en doorgerouted met conceptantwoord als suggestie
Bulk-zaakgeneratie — op basis van planningstrigger automatisch Zaken aanmaken per huurder in een complex
Strategisch principe
Het nieuwe datamodel is niet alleen een UX-verbetering — het is de infrastructuur waarop AI-agenten kunnen draaien. Agentisch werken vereist duidelijk gedefinieerde objecten, eenduidige relaties en machine-leesbare statussen. We bouwen nu de structuur die dit straks mogelijk maakt.
Sectie 7
Rechten & Rollen

ZGW 2.0 introduceert een bewuste scheiding in zichtbaarheid: niet alle medewerkers mogen alle zaakinhoud inzien. Tegelijk moet voor iedereen duidelijk zijn wat er bij een huurder speelt.

7.1 Twee onafhankelijke assen
As 1 — Huurder-zichtbaar (bestaat al)
Bepaalt of een contactmoment of zaakstatus zichtbaar is in de mijnomgeving. Geregeld via de bestaande "Intern"-tag.
As 2 — Medewerker-toegang (nieuw)
Bepaalt welke medewerkers de volledige inhoud van een zaak mogen inzien. Bestaat nog niet in het huidige systeem.
7.2 Toegangsniveaus per zaaktype
Transparant
Alle medewerkers zien de volledige inhoud. Voor standaard zaaktypen: reparaties, algemene vragen.
Beperkt
Alleen eigenaar + betrokken team ziet de inhoud. Anderen zien de zaak op tijdlijn maar kunnen inhoud niet openen. Incasso, Leefbaarheid, Juridisch.
Vertrouwelijk
Alleen specifiek benoemde personen. Anderen zien uitsluitend dat er een zaak van dit type loopt. Fraude, intimidatie.
7.3 Wie maakt wat aan?
Front-desk medewerker — maakt vanuit Conversatie een Zaak aan, wijst toe aan specialistteam. Heeft daarna alleen toegang tot voortgangkaart bij gevoelige zaaktypen.
Specialistteam (Incasso, Leefbaarheid, Juridisch) — werkt volledig in de Zaak met toegang tot alle inhoud, notities, ruggespraak en documenten.
Interne Zaak — aangemaakt door specialistteam zelf. Verschijnt niet op tijdlijn huurder, front-desk ziet deze zaak niet.
Sectie 8
Volgende stappen & discussiepunten

Dit document is bedoeld als startpunt voor de teamdiscussie — een gedeeld begrip van het model. Technische uitwerking volgt in epics en user stories per fase.

8.1 Bouwvolgorde — fundament naar uitbreiding
1
Fase 1 — Fundament
De Zaak als volwaardig werkitem
Eigenaar, deadline en status op de zaak zelf. Meest urgente pijnpunt, basis voor alles wat volgt.
2
Fase 2 — Scheiding
Conversatie en Zaak als aparte objecten
Bewust triggermoment van conversatie naar zaak. Ruggespraak embedded in context via @mentions. Notificatiesysteem gekoppeld aan zaak-events.
3
Fase 3 — Samenwerking
Ruggespraak, Side conversation, Gerelateerde zaken
Ruggespraak embedded in context. Side conversation via bestaande emailkoppeling.
4
Fase 4 — Schaal
Verzamelzaak, Interne Zaak, Bulk-generatie
Verzamelzaak met broadcast. Interne zaak met cross-posting. Bulk-zaakgeneratie vanuit complex.
5
Fase 5 — Portaal
Dynamisch huurdersportaal
Zaakstatus, CaseFlow-voortgang en deadline-communicatie zichtbaar voor huurder.
8.2 Openstaande discussiepunten
Hoe gaan we om met bestaande tickets in de migratie naar 'Zaak'?
Welke zaaktypen definiëren we als eerste? Welke zijn standaard zichtbaar in het portaal?
Welke Zaakscenario's bouwen we als eerste — en wat is de minimale variant voor ad-hoc Zaak-aanmaak?
Hoe borgen we dat conversatie→zaak een bewuste keuze blijft, geen automatisme?
Wat is de minimale set attributen per zaaktype voor de eerste release?