Support Process

21.5. Support Process#

This chapter documents the main support proess for GNU Taler users. The goal is to ensure customers are kept in the loop and receive timely feedback and quality resolutions.

21.5.1. Incoming#

There are several ways how users may reach us for support:

  • Filing bugs at https://bugs.taler.net (Mantis)

  • Contacting us via e-mail, usually support@taler.net or a dedicated support e-mail address of the respective Taler operator.

  • Contacting us via e-mail at sales@taler.net or a dedicated sales e-mail address of the respective Taler operator. Those should soon be routed directly into the ERP.

  • Phone calls (usually to the respective Taler operator). For these, we should eventually set up an automatic cascade.

The next steps depend a bit on the type of issue, channel used and the type of customer.

21.5.1.1. Bugtracker#

If an issue was raised in the bugtracker, that is perfect and it basically immediately goes into the analysis stage.

21.5.1.2. Support E-mail#

If raised via e-mail, there recipient should do some initial triage.

  • If the request is likely to be an actionable bug in the documentation, software or operations, a bug report should be filed on Mantis without personally identifiable information about the user. If such information is critical to the issue, it could be added as as a “private” note. If the issue could have serious negative implications if disclosed to the public prematurely (like a security problem on our end), it should be set to “private”.

  • If the request relates to needs for onboarding and commercial support, a record for the merchant or bank should be created in the ERP and the communication added there (if the support e-mail did not already arrive into the ERP). The process continues with the “Sales” stage.

  • If the support request is answered by existing documentation, the e-mail should be answered by pointing to the existing documentation and asking the user politely if that answers their question. If the user is unhappy with the documentation or if them not finding it happens frequently for a particular question, a bug should be opened indicating that the documentation or its discoverability need to be improved. (In this case, the user does NOT need to be pointed to that bug.) If existing documentation does not answer the user, this is an actionable bug (see above) and should be treated as a documentation bug.

Issues in the bugtracker added on behalf of customers should always be filed in state “new” and not already be assigned. They should be tagged with “Customer”.

21.5.1.3. Support phone#

When receiving a customer call via phone, it is important to note the following:

  • Name of the customer

  • Type of customer (user, merchant, bank, other?)

  • Contact information (e-mail? phone number!)

  • Anything about the actual issue

  • Date of the call

These should be added to the bug tracker (if we have a problem) or the ERP (if related to onboarding / sales) respectively.

During the first phone call, focus on listening to the customer to make sure you understand their issue as best as you can. You may point them already to existing documentation, but should not promise that particular issues will be fixed or within a certain timeline unless you are very sure that the timeline can be met and will have management approval. If in doubt, you may forward the customer to management.

21.5.1.4. Sales E-mail#

Sales E-mails should be added to the ERP under the respective customer. The process then continues with the “Sales” stage.

21.5.2. Sales#

The sales process follows the usual ERP processes from leads to conversion. In general, it is important to identify blockers for the customer (such as missing features) early on and to proceed once we are ready to follow through.

If technical issues (incl. feature requests) arise during the sales process, management should be consulted about making a commercial offer, addressing the issue gratis, or refusing to address the request. If the customer accepts the offer (or if management decided to address it gratis), a respective issue should be opened on the bug tracker.

21.5.3. Analysis#

Initial analysis of all incoming bugs is generally done by the management; some executive will look over NEW bugs and assign a priority and set a staff member to look into the issue. Developers may self-assign (“grab”) incoming issues that are clearly in their domain if they consider them clearly urgent and suitable for fast resolution. However, any interference with customer accounts or data (such as re-setting passwords) always requires prior assignment of the issue to the staff member by management.

The bug is first set to “feedback”. At this stage, the developer MUST urgently respond if the problem (and path to resolution) is clear, and what they think is a realistic and conservative (!) timeline for fixing the issue. If the issue is complex and likely to require changes in other subsystems, sub-bugs may need to be opened by the developer, which may in turn require feedback from other developers as well (so they should be assigned with “feedback” to the other developers). After the feedback has been collected, the bug status should be set back to “NEW”. This even applies if the developer already fixed the issue; if the issue has aready been resolved it should be noted where (in Git? in testing? in production? which version?).

Afterwards, management will determine a timeline for resolution based on the feedback and either directly respond to the reporter or ask a suitable staff member to communicate a response to the user (for reports received via phone or e-mail). In general, the user must receive an answer that we are “investigating the issue” including a link to the bug (unless it is set to “private” and would thus not be visible to the user). The bug(s) are set to “confirmed” and the request then proceeds to the action stage.

21.5.4. Action#

Staff generally promote tasks from “confirmed” to “assigned” when they start to work on them. In general, this should happen by checking the target release and/or bug priority, but developers may have good reasons (context, dependencies, etc.) to make adjustments. If it becomes likely (!) that deadlines cannot be met, staff will put this in writing with the impacted issues. In general, the subject of the bug should contain the amount of time needed that is left for fixing the issue, and a deadline ([4h, 14.3.2034]). These numbers should be updated whenever predictions change or work progresses.

After the developer has fixed the issue, they draft a response to the customer as a bug note. The general tone of the response should always be “we fixed”, not “I fixed”, never put any blame on the user, and acknowledge mistakes appropriately. The issue should then be scheduled for review by assigning the bug to another staff member for “feedback”.

21.5.5. Review#

When receiving a (presumably) resolved bug for feedback, the staff member is supposed to try to reproduce the original issue and check if is now absent. This may again require sub-tasks such as packaging and deployment (into staging systems) to be performed. Review does not have to be done in a big QC session, but especially for complex issues it is recommended to look into them during a QC session.

If the issue is not addressed fully, it should go back into the “Action” stage, otherwise it is assigned (status: assigned) to the staff member responsible for communicating the resolution to the customer. It should be noted that this only applies to bugs opened by customers, if no customer is involved the bug may simply be marked as “resolved” directly.

21.5.6. Resolution#

In this phase, the same staff member (if possible) who responded to the customer during the analysis phase writes a brief notification to the customer about the issue having been fixed based on the draft provided by the developer. Depending on the customer, this may happen after confirmed fix is in Git, deployed to staging or is available in production. The staff member should consider when to send out the notification on a case-by-case basis, but in general earlier is better as long as the infomation is useful for the customer. Technical information may be shared, but the amount of sharing should be tailored to what we believe the customer would want to comprehend.

If the issue originated from a sales process, the ERP must also be updated and (if applicable) the invoicing / billing process be initiated. In this case, the response should be sent via the ERP.

Afterwards the issue should be marked as “resolved” and is finally closed by management with the next release cycle.