This is a very broad question related to a Customer Queue Management System. I would like to know your opinion in terms of using NServiceBus. Brief set of features expected from the system is below.
- Users request a ticket in a selected queue (technical/customer support) via mobile or web - REST API
- Issued tickets need to be saved reliably in some storage
a. Technical support queue has [1,2,3,4,5] issued tickets in order
b. Customer support queue has similar queue - Alerting service about the status of a queue which user is interested in (ex:- On my way to a business to get some technical support, I request a ticket via mobile. As long as the mobile app is running I get real-time update about the status of my queue)
- Queue Agent - The individual who is responsible in serving each queue calls tickets
a. Agent may direct the customer to another service (from customer service to tech support queue) - Routing Service - Handles routing services between queues (At all queue changes relevant customers/agents keep informed)
- Service Monitoring - Which measures key statistics at certain points and stores for reporting
- Reporting - just that….
- Other usual blah blah
This will be a multi-tenant solution. So each message going back and forth will always be tied to a tenant which I think is not relevant to NServiceBus.
Also, different businesses may handle their customer service journey differently. So ideally these user journeys must be pluggable for different tenants.
Now this whole thing is a user journey which is long running. So is it correct to say (if I apply this to NServiceBus related usage) that this is a saga?
What would be the best approach in tackling these scenarios in terms of NServiceBus? Some insights will help me get going with the rest.