Page MenuHomePhabricator

Nuance: As a Helpdesk, for Phabricator/Phacility support
Open, NormalPublic

Assigned To
Authored By
May 21 2017, 12:49 PM
Referenced Files
"Party Time" token, awarded by spawnlt."Like" token, awarded by tomekj2ee."Like" token, awarded by avivey."Love" token, awarded by johnny-bit.


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:

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, while actual development continues to live here on 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 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 <>" 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.


  • 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.

Event Timeline

epriestley renamed this task from Nuance: As a Helpdesk to Nuance: As a Helpdesk, for Phabricator/Phacility suppot.May 21 2017, 5:03 PM
epriestley updated the task description. (Show Details)

There's a typo in the headline, but I can't it :(

chad renamed this task from Nuance: As a Helpdesk, for Phabricator/Phacility suppot to Nuance: As a Helpdesk, for Phabricator/Phacility support.May 21 2017, 8:33 PM

I think we're more-or-less at the point where the existing Nuance code is about as internally modernized as it's going to get, so there isn't a great deal of remaining obvious technical debt to pay down.

Next, I think I could either write a toy application which doesn't know anything about Phacility objects -- like Fund is a toy application for Phortune -- or just dive straight into writing the Phacility support application.

I think I'm inclined to just start with the Phacility stuff. With Fund, the toy application was much simpler than the real application: for example, it has simpler click-to-buy workflows instead of more complex subscription workflows, and Instances weren't yet fully-realized objects. Here, I don't think any toy application is going to be much simpler or really represent a step along a path and all the Instances stuff has been in production for a long time.

In terms of actual workflow, I think it will look like this as a user:

You can get to support by following a "Support" link from or by following a "Support" link from an instance detail page.

The portal has a list of contracts you have access to and options to purchase additional contracts. If you hit the portal from and have access to exactly one active contract, you're automatically taken to that contract. This is the common case because instances auto-generate a corresponding support contract (at least, in the future).

On the contract page, you can:

  • File a new issue.
  • Review issues you've filed in the past.
  • Change contract details (user access, name).
  • Change billing details ("do not renew").
  • Later: Review mana.
  • Later: Update passive priorities.

The contract has a paired Source in Nuance and filing issues creates Items in Nuance although I think I'm going to leave the primary objects in the new "Support" application for now?

That all seems fairly tractable.

I think I'm going to do this, permissions-wise:

  • For instances, only instance managers can file issues but any user can see them. Users without permission to file will be told who they should go bother.
  • For ala carte, I'd sort of like to set a PoC limit but maybe this should just be ad-hoc, or "add a poc" is a workflow which costs a couple of mana points once you get past 2-3 or whatever. We only really have one install where this is an issue.

Also we need to figure out what the actual pricing is but we can talk about that behind closed doors for the moment.

epriestley added a revision: Restricted Differential Revision.Jun 27 2017, 10:38 PM
epriestley added a commit: Restricted Diffusion Commit.Jul 14 2017, 2:34 PM