Als medewerker wil ik een of meerdere producten uit de PDC aan een verzoek koppelen about klantinteracties HOT 12 CLOSED

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

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.