Nuance is a queue for high-volume human intelligence tasks (see T8783 for more details).
Although we envision several classes of use case for Nuance, the priority workflow is as a "help desk" or "support queue". Specifically, we plan to:
- Move free support to Nuance, to help address the low quality of many reports (see: {T12134}).
- Move SAAS support to Nuance, to help us scale and improve our support channels.
- Provide a new paid support product via Nuance, to help us better address the project's evolving relationships with customers (see: {T12681}).
---
Outside of our upstream use cases, we've seen some third-party interest in this general class of tool.
- One install was interested in bridging Instabug, but this is probably a better fit for T12739 than the "Helpdesk" use case.
- One install was interested in a Zendesk/Maniphest integration, but seemed substantially satisfied with Maniphest inbound mail.
- One install was generally interested in Nuance along this use case, but also seemed substantially satisfied with Maniphest inbound mail.
- One install from 2014 was interested in Nuance as a triage tool (T12740).
I don't expect to account for these use cases much in this phase. I think the major consideration they imply is how logged-out users work, but that's probably not an issue which would impact design here very much. I think we should generally assume that the "author" of an item may not be a `PhabricatorUser`, but I believe we already do this and this is about all we really need to do to pursue anonymous / email / external users in the long run.
It would still be nice to ship some kind of support in this iteration which would be useful outside of Phacility, but I don't think it's necessarily too important.
---
Some of the features we want are:
**Multiple Queues**: From a staff perspective, we should see "free" and "paid" tickets in different queues.
**Per-Queue Metrics**: We'd like to expose response rate and median response time publicly. I believe our values are very good, and these can reinforce whatever actual SLA we provide. At our current staff levels, the SLA we can commit to in the worst case (12 hours is a stretch) and the SLA we'll routinely hit (minutes) are enormously different. This can also help establish expectations around free vs paid support.
**Sources as Organizations**: I //think// we want to model each organization as a source. The source's properties will then be things like "members", "mana points", "billing status", etc. The source can also represent a "Support Contract" for paid support. This ends up giving a lot of responsibility to sources, so perhaps some of this should go in a secondary upstream object which is just linked to a source.
**Mana / Incident Points**: We want to track how much load each install is creating.
**'Page Someone' Button**: Paying customers should be able to click a "this is urgent" checkbox to page someone for downtime issues, etc.
**The Ability to Take Away the 'Page Someone' Button**: Customers who abuse the "this is urgent" checkbox should lose access to it. We could also do this via Mana (e.g., it costs 999 mana to cry wolf).
**Piles of Weird Workflow for Free Support**: Paid support should probably just have a textarea where you type things, but free support should have additional handrails like //requiring// version information, //requiring// reproduction steps, etc.
**Listing Priorities**: For T12681, installs should be able to list priorities. We could do this in a low-tech way like "open an incident with priorities if you want to list 'em" for now.
**Cross-Linking**: I currently expect this to live on `admin.phacility.com`, while actual development continues to live here on `secure.phabricator.com`. It would be nice if `T123` on Admin cross-linked here. We can probably just copy-paste stuff for now, but I'm not sure that there's a great solution here.
---
Overall workflow is something like:
- You go to "Support".
- Now, you pick a source to report through.
- Everyone can pick the "free" source (but maybe we kind of bury this, since users starting on `admin.phacility.com` are usually not there for free support, and having instance member submit into the free/community queue is a bad experence?)
- If you manage a (non-free) instance, you can pick the instance's source.
- If you're a member of an instance, maybe we say "ask one of these users to open a support ticket for you: <list of managers>"?
- (Free instances get told to go away + upsell, or whatever we can do that's the most evil.)
- If you're authorized on a support contract source, you can pick the support contract source.
- Anyone can purchase dedicated support (but maybe this option is buried/folded if you're an instance member, since you probably don't mean to pick it and it might be confusing/misleading -- "I have to pay for support?").
- Maybe add some ways to simplify this and avoid confusion, like link directly to "Report as <x.phacility.com>" from the instance detail screen.
- Now you get a form where you type your stuff (paid support) or answer a long list of riddles (free support).
- This takes you to an item detail page, where you see the user view of the item. This is similar to a Maniphest task.
Internally, we see items by //queue// ("free" vs "paid") rather than by //source//. Maybe we internally have three queues, like "free", "community", and "paid", and let community members promote stuff from "free" to "community", where we actually look at it.
So:
- Sources need a //lot// of custom hooks here, since most of this probably does not generalize well.
- The whole source management/selection dashboard needs to be custom, but that's not too surprising.
---
The technical pathway may be something like this:
- Try to break out sources first, focusing on instance sources.
- Once instance sources work, do the free sources.
- Once those both work, do the community and paid sources in whatever order.
I'm less concerned about mana, paging, really locking down the free support workflow, priorities, etc., for now. We can continue to do this all by hand for the moment.
I wish I had a better plan for cross-linking. The "best" plan would be to put support on this install, but I'm fairly loathe to do that since we end up with a lot of deployment, billing, and dependency messes. I think we'll just have to try to do a reasonable job with this in the longer run.