Support Mana

Phacility User Documentation (Support)

Understanding support mana.

Overview

Phacility provides bundled support for SAAS customers and offers paid support for organizations that self-host Phabricator.

The range of support services we provide is broad, but the amount of support we can provide in a given period of time is finite. We use incident points (called "mana") to help manage support volumes and communicate expectations.

Support pacts accrue mana over time and spend it on support services. Unused mana contributes toward prioritizing longer term projects (like development of major new features) that are important to your organization. If you run out of mana, your issues will be processed at lower priority.

Mana Regeneration

• A little bit of mana regenerates every day.
• When your mana is full, overflow mana helps prioritize long term projects.

Pacts have a mana regeneration rate and a maximum mana capacity, visible on the Mana Details page.

Mana regenerates daily, based on the mana regeneration rate. For example, if your pact regenerates 50 mana per month, it will regenerate about two mana every day (in practice, it will regenerate 2 mana most days and 1 mana on other days).

Mana regenerates on a 28 day cycle regardless of the length of the calendar month or current billing cycle. You can review regeneration on the Mana Details page.

If mana would regenerate above your maximum mana capacity, it overflows. This overflow mana is tracked internally and used as an input when we decide how to prioritize longer term projects.

Mana Costs

• Support costs mana.
• Manage mana costs by prioritizing your support requests.

Filing a support issue costs 5 mana. After the issue is triaged and understood, the casting cost may be adjusted up or down. We will generally make these kinds of adjustments to issues:

This list is not exhasutive, and these categories are just general ideas of some of the kinds of issues we see most frequently. Generally, issues which are easier to resolve (like simple questions) or where we shoulder more of the resposibility for the problem (like bugs) have lower costs. Issues which are harder or more time consuming to resolve or where we are less responsible for the problem have higher costs.

Most organizations do not need very much support and will not need to be particularly mindful of their available mana. If you find you're using mana faster than it is regenerating, you can try making some of these changes:

Consolidate Points of Contact: If you have many points of contact on your pact and they're each filing separate issues without internal communication, this can drain mana quickly, especially if these issues are redundant. Use fewer points of contact and focus on getting the issues which are most important to your organization addressed first.

The easiest way to do this is to ask users to coordinate with a dedicated internal point of contact and have only that person interface with Phacility. This will help make sure you aren't filing redundant issues and have clear internal priorities.

Reduce Issue Complexity: The mana cost of reproducible bugs and well-defined problems (which take us less time to resolve) is very low. You can get the same issues addressed with less mana if you're willing to do a little more work upfront.

Particularly with bug reports, it may be much more efficient for you to do this work than for us to do it, because we usually won't have direct access to your environment where the issue reproduces. If you're able to narrow a problem down to a reproduction case before you open an issue it can save everyone a lot of time.

For guidance on filing good bug reports (with reproduction steps) and requests (which describe context and problems, rather than just asking for specific solutions), see:

• Contributing Bug Reports
• Contributing Feature Requests

Review and Prioritize: If you're filing a mixture of more immediate issues and longer term issues, you may want to hold the longer term issues until the more urgent issues are resolved.

In particular, this situation may occur in the first few months after you begin using Phabricator. It's common for a lot of hypothetical questions about possible problems in the future to arise. However, it's also common for many of these problems to never actually happen, or for it to become clear how to navigate them as your organization adapts to Phabricator and becomes more familiar with it.

In cases like this, you may want to divide issues into more urgent issues (for example, problems blocking teams from doing work) and less urgent issues (for example, possible problems you think you may encounter in the future) and hold the less urgent issues until later.

You can review what you're spending mana on in the Mana Details panel.

Increase Plan Size: Of course, you can also purchase a support plan which generates more mana.

Mana Exhaustion

• You can always file new issues, even if you're out of mana.
• If you run out of mana, we will respond to your issues at lower priority.

Mana is a communication tool to help us set clear expectations about how much support we can provide you. It is only a guideline, not a hard limit.

Running out of mana does not prevent you from filing new issues, and we'll continue to triage them promptly as long as your account remains in good standing. However, we will process and resolve them at a lower priority than normal until your mana regenerates.

There are no other penalties or negative consequences, and you shouldn't worry about running out of mana: it just means that you may want to take another look at how you interact with support to make sure the issues that are most important to you are getting prioritized.

Feature Development

• You are paying for help solving problems, not for feature development.
• Sometimes, feature development is a promising approach to solving a problem.

The primary goal of support is to solve problems you encounter.

In some cases, the best solution to a problem is for us to add new features to the upstream. After understanding the problem you're facing, we may offer to develop features to solve it.

But we also may not. You are paying us to help you solve problems, not necessarily to develop features, and you should not expect a support pact to give you a blank check to get a MIDI synthesizer or Raspberry Pi support into the upstream, even if these features would solve problems for your organization.

Feature development isn't always the best solution to problems. It also takes much more time than most other types of solutions, so we'll usually try to find a different type of solution, at least as a stopgap, which can solve or mitigate the problem you're encountering more quickly. But we may also offer a partial or complete solution in terms of new feature development.

Generally, you should describe problems to us. We will try to offer solutions to those problems, which may include feature development. But the solutions we offer may also not include feature development, and the features we offer may not be the same set of features you imagined in thinking about the problem. It is rare that we can not offer any solution to a problem, but common that the solutions we offer may not be the first thing you might think of.

For some more details on the kinds of features which are generally suitable (and unsuitable) for the upstream, see Planning.

After we mutually decide that feature development is a promising approach to solving a problem, we'll add the project to our roadmap (if it isn't already something we plan to build) and use your interest in it to help prioritize it so it gets built sooner.

Feature Prioritization

• Unused mana is a little like votes for long term projects.
• Reality is messy, but we'll try to keep lines of communication open.

We have finite development bandwidth, and features compete against other features and other internal and external factors for priority. One factor we weigh heavily in prioritizing features is your organization's interest.

You can think of unused support mana as similar to voting for features. This oversimplifies our planning process and is not the only factor we consider, but we will generally use support mana as a proxy for feature value when prioritizing and planning.

The reality of software development is messy and we can not offer an oracular leaderboard of features, votes, and delivery dates. We will try to offer insight into our plans and estimates where we can so you have the most accurate information available, even if that information is uncertain.