Comments (12)
Onderstaande volgens de huidige visies op verzoeken en klantcontacten. Dit is een oefening in het doorredeneren van de keuzes daarbinnen, niet per se het definitieve antwoord.
Da's een interessante, dat eerste citaat uit de visie. Wat nu als een burger via het digitale kanaal een vraag stelt? Valt dat niet onder verzoeken (een verzoek tot antwoord op een vraag)?
Is daarvoor een product? Zo niet, geen verzoek. In de (open, hulde!), Vlaamse PDC (link) vind ik geen voorbeelden van generieke producten als 'antwoord op een vraag' of 'informatieverzoek'. Verzoeken als vragen behandelen? Dan daartoe een product toevoegen.
Consequentie hiervan is de vraag of we niet eigenlijk moeten spreken van 'bestellingen' in plaats van 'verzoeken'. Hoewel dat laatste vanuit klantperspectief (#58) zeker niet duidelijker is.
Als er in een vraag geen producten/diensten besteld worden, is het dan een klantcontact?
Inderdaad. Maar als er telefonisch contact is tussen klant en gemeente over een vergunningsaanvraag, en dat gesprek leidt ertoe dat een medewerker in opdracht van de klant een aanvraag indient, dan is sprake van een klantcontactmoment dat heeft geleid tot een verzoek.
Of is het onderscheidende aan een klantcontact dat er echt sprake is van contact, synchroon. Terwijl het digitaal indien van een verzoek en de reactie daarop asynchroon is. Is dan een klantcontact een subtype van een verzoek? En wat nu met digitaal chatten? Klantcontact?
Klantcontact zou een subtype van verzoek worden als vraagbeantwoording een product is. Een bericht per mail of berichtenbox over een zaak aan een initiator is ook een klantcontact. Asynchroon mag dus ook.
gemeente-Whatsapp?
Ik begreep dat het maar zeer de vraag of deze vraag na december nog relevant is.
from klantinteracties.
Deze user story heeft mogelijk consequenties voor het gegevensmodel.
from klantinteracties.
Hoe moet ik deze story begrijpen? Als in 'medewerker definieert een verzoek(type) en koppelt daaraan één of meerdere producten zodat klanten verzoeken kunnen indienen'? Of als in 'medewerker koppelt één of meerdere producten aan een binnengekomen verzoek van een klant'? Ik vermoed het laatste, wat impliceert dat we 'ongestructureerde' verzoeken willen toestaan.
from klantinteracties.
@hdksi De visie geeft aan:
Verzoek kan meerdere producten/diensten omvatten (dit ondersteunt een winkelmandje) en derhalve tot meerdere zaken leiden. Anders is het een vraag, dus contactmoment.
en
Bij een verzoek wordt alleen generieke metadata opgeslagen, domein- of procesgegevens worden in een andere registratie opgeslagen.
from klantinteracties.
Da's een interessante, dat eerste citaat uit de visie. Wat nu als een burger via het digitale kanaal een vraag stelt? Valt dat niet onder verzoeken (een verzoek tot antwoord op een vraag)? Waarin zit het onderscheid tussen een klantcontact en een verzoek? Als er in een vraag geen producten/diensten besteld worden, is het dan een klantcontact? Of is het onderscheidende aan een klantcontact dat er echt sprake is van contact, synchroon. Terwijl het digitaal indien van een verzoek en de reactie daarop asynchroon is. Is dan een klantcontact een subtype van een verzoek? En wat nu met digitaal chatten of de gemeente-Whatsapp? Klantcontact?
from klantinteracties.
Ik denk dat we in de user story moeten loslaten wie het koppelen doet. Het moet mogelijk zijn een verzoek te koppelen aan een of meerdere producten. Meestal kan de koppeling direct tot stand komen bij het indienen door de klant (denk aan formulier) en soms moet de medewerker dit alsnog doen (of wijzigen) bij de intake.
from klantinteracties.
Klantcontact zou een subtype van verzoek worden als vraagbeantwoording een product is. Een bericht per mail of berichtenbox over een zaak aan een initiator is ook een klantcontact. Asynchroon mag dus ook.
Aha, nu wordt het echt interessant. Is een klantcontact dan elke interactie met een klant: ontvangst van een brief, van een mail, idem verzending van beide, telefonisch contact, facebookcontact, ontvangst van een digitaal formulier, et cetera? Dan zou verzoek, wat je neerzet als bestelling van een product, daarvan een subtype zijn. En is het iets anders dan wat nu in het RGBZ klantcontact heet.
Zie ook deze analyse.
from klantinteracties.
@ArjanKloosterboer: dat klopt, en was één van de redenen voor het losknippen van klantcontacten. Volgens mij kunnen we de tabel waarnaar je linkt als volgt uitbreiden (informeel contact betekent hier contact dat niet over de levering van producten of diensten gaat).
Mogelijke soorten klantcontacten
Soort contact | Verzoekgerelateerd | Zaakgerelateerd | Niet-verzoek-/zaakgerelateerd |
---|---|---|---|
Synchroon niet-anoniem leidend tot levering producten/diensten | x | ||
Synchroon anoniem leidend tot levering producten/diensten | x | ||
Asynchroon niet-anoniem leidend tot levering producten/diensten | x | ||
Asynchroon anoniem leidend tot levering producten/diensten | x | ||
Synchroon niet-anoniem met betrekking tot lopend(e) verzoek/melding/productbestelling | Als overgang zaak-verzoek atomair is dit niet mogelijk. Zie #53. | x | |
Synchroon anoniem met betrekking tot lopend(e) verzoek/melding/productbestelling | i.v.m anonimiteit niet van toepassing (?) | i.v.m anonimiteit niet van toepassing (?) | i.v.m anonimiteit niet van toepassing (?) |
Asynchroon niet-anoniem met betrekking tot lopend(e) verzoek/melding/productbestelling | Als overgang zaak-verzoek atomair is dit niet mogelijk. Zie #53. | x | |
Asynchroon anoniem met betrekking tot lopend(e) verzoek/melding/productbestelling | i.v.m anonimiteit niet van toepassing (?) | i.v.m anonimiteit niet van toepassing (?) | i.v.m anonimiteit niet van toepassing (?) |
Synchroon niet-anoniem informeel | x | ||
Synchroon anoniem informeel | x | ||
Asynchroon niet-anoniem informeel | x | ||
Asynchroon anoniem informeel | x |
from klantinteracties.
Producten worden ofwel via URL gekoppeld ofwel via identificerende gegevens (dit is productnaam).
from klantinteracties.
@hdksi Ik weet niet precies wat we met je tabel moeten doen maar het ziet er nuttig uit?
Qua werkzaamheden in dit ticket ga ik het volgende doen:
VerzoekProduct
als resource introduceren (relatie tussen verzoek en een product). Dit is helaas nodig omdat het PDC een nog niet officiele API-standaard betreft. Hierdoor moeten we identificerende gegevens ergens opnemen. Dat zou nog zonder deze resource kunnen maar gezien er ook aangegeven wordt "[een of] meerdere producten uit de PDC aan een verzoek koppelen" moet dit ondergebracht worden in een losse resource.
In aanvulling op @Hugo-ter-Doest 's commentaar neig ik naar code
op te nemen als identificerend gegeven op basis van het gelijknamige attribuut zoals Arjan dat in de laatste (bij mij bekende, want niet op Github) versie van zijn IM heeft opgenomen.
Overigens zit deze relatie dus alleen tussen een Verzoek en een Product, volgens de US en volgens het IM diagram.
from klantinteracties.
De tabel gaat over wanneer sprake is van een klantcontact, en is een gevolg van de discussie die naar aanleiding van het issue ontstond, maar eigenlijk niet relevant voor het specifieke issue zelf.
from klantinteracties.
Toegevoegd in VNG-Realisatie/klantinteracties-api#16
Zie: Redoc
from klantinteracties.
Related Issues (20)
- Voorstellen Klantinteracties: Registreren partij en gevolgen voor Omnichannel doel: Klantherkenning. HOT 1
- Voorstellen Klantinteracties: Toelichting deel 2 – sheet 5: Digitaal adres HOT 1
- Voorstellen Klantinteracties: Partij - gegevensset HOT 1
- Waarom is de "promotie" van interne taak naar zaak verwijderd? HOT 2
- [VRAAG] Datum van IMs HOT 1
- [VRAAG] Welke externe ID soorten zijn mogelijk?
- Maak een case aan voor een mutatie van een klantcontact.
- Hoe gaan we om met referentielijsten in de API-specificaties.
- Bij het vervangen van 'voorkeurskanaal' door 'voorkeursDigitaalAdres' is onbedoeld de mogelijkheid komen te vervalen een niet-digitaal kanaal (post) als voorkeur te registreren
- Hoe zorgen we ervoor dat nummers bij Klantcontact, Partij en Interne Taak uniek ziijn ? HOT 1
- Hoe gaan we om met referentielijsten voor indentificatoren?
- Omschrijving komt niet overeen met de specificatie
- Als functioneel beheerder wil ik partijen kunnen opdelen in categorieën (categorie, partijtype).. HOT 2
- [VRAAG] Moet het formaat van "nummer" attributen niet string zijn ipv integer?
- NummeraanduidingID is onterecht verplicht
- [VRAAG] In de case van een terugbelverzoek, moet er dan een nieuw klantcontact worden aangemaakt of bestaande worden bijgewerkt, of geen van beide?
- Als Erfpacht domein wil ik domein specifieke klantgegevens registreren in de Klantinteractie API
- Bondig beschrijven wanneer wel en geen partij wordt geregistreerd en wanneer het wel of niet zinvol is om een klantcontact te registreren
- Taak kunnen toewijzen aan medewerker én een organisatorische eenheid
- Kunnen zien wanneer een interne taak is afgehandeld
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from klantinteracties.