Support & Quality

Product Support Workflow

No support without a ticket 😘

The help desk provides technical support to end users, troubleshoots customer and user issues, and/or guides them through specific tasks and actions. The fundamental aim of our help desk is to provide swift and effective resolutions for user queries and act as a one-stop shop to manage all customer queries, complaints, needs, requests and support. It is essentially a single point of communication between Akvo and end users and helps resolve any product issues swiftly and effectively.

What Is The Support Process?

jPNPUTGt3bLxVREQ-drawing-3-1685000247.png

How to Categorize Issues?

Severity

Definition

Critical Impact

Production application down or major malfunction resulting in in-operative condition.

Significant Impact

Critical loss of application resulting in high number of users unable to perform their normal functions. Major failure; inconvenient workaround or no workaround exists.

Minor impact

Moderate loss of application functionality or performance resulting in multiple users impacted in their normal functions. Minor feature/product failure, convenient workaround exists/minor performance degradation.

Low impact

Minor loss of application functionality, cosmetic issues.

How To Tag Incoming Tickets?

See this page.

Response Time

The support team commits to responding to issues within 1 working day.

How To Reach Out To Support?

The strong preference is for users to submit requests via the Contact Us form in the support portal. 

To create a support request, follow the below steps:

  1. Locate the Contact Us form - Look for a link or button labelled "Contact Us" on the product support pages.
  2. Enter your information - On the contact form page, enter your name, email address, the hub you work with, the product you need help with, and any other information required by the form. Also select whether you are reporting a bug, requesting a feature or have a question.
  3. Write your message - Use the message box provided to write your inquiry or message. Be clear and concise, and include any necessary details to help us understand your request. See guidelines below on how to write appropriate messages.
  4. Review and submit - Before submitting the form, review all of the information you've entered to make sure it's accurate and complete.

Please reach out on Slack to make sure we attend to the ticket if it is urgent.

If a client reaches out to you directly:

  1. Inform clients that a ticket will be created for them
  2. Make sure the client knows that the support team will end up reaching out to them over email (support ticket)

How To Properly Document A Support Issue?

Sharing as much information as possible helps us in researching and replicating the issue.  “It doesn’t work” makes it very hard to research a problem. 

A general guideline on what to provide:

  1. What were you doing - the action the user was performing
  2. What did you expect to happen - expected result
  3. What actually happened
  4. Steps to reproduce the problem - Any steps that will help reproduce the problem
  5. Flow specific - Dashboards, folders, surveys, assignments, device IDs, IMEI, etc.
  6. RSR specific - User roles / account, specific project, organization, RSR page, etc.
  7. Lumen specific - Instance, user, dataset, visualization, dashboard, etc.
  8. Device specific - Type of computer/browser, type of phone or tablet, app version (and connected dashboard)

Rationale

The process of submitting all produced related inquiries, issues, and complaints through the help desk ticketing system will ensure that your requests are logged and tracked, and our support team can address your needs in a timely and organized manner. Additionally, by following this process, we can document and analyze the data collected from your requests;  This data will allow us to measure our performance and identify areas for improvement.

How To Tag Tickets

Tag

Description

Hub

The hub from which the client/partner is managed from. Can be one off East-Africa, Europe, West-Africa, Asia, Americas.

 

The following tags are available on Re:amaze for the regions partners are managed from:

  • #Submit-Asia:
  • #Submit-EastAfrica
  • #Submit-Americas
  • #Submit-Europe
  • #Submit-WestAfrica

Partner

The partner/client name. The partner tag beings with a “#instance-” followed by the partner name e.g. for Nuffic the partner tag is "#instance-nuffic" for Wemos "#instance-wemos" etc.

Category

Groups tickets by whether it is a question, bug or feature request. When triaging a ticket the support office the following tags are available for this:

  • #question
  • #bug
  • #feature 

Escalation Status

Flags whether the ticket required additional input from L2. This is for tickets that are not resolved by L1 usually bugs or feature requests. The available tag options for this are:

  • #escalated
  • #not-escalated

Impact

Categorizes tickets by the severity of the impact. The description of each of this can be found here.

Issue

A brief tag that describes the issue being reported by the user e.g. data import or export, user management etc.

No standard classification. But be mindful of reusing existing tags as much as possible.

Product Support Dashboard

See the dashboard here.

What Is the Product Support Dashboard?‌

 A ticket dashboard collects all client tickets and provides a centralized place for support teams to view and manage the issues and requests. The dashboard provides a quick, visual overview of ticket status, ticket volume and overall team performance.

What does each chart mean?

Volume Reports

The Volume report shows you a summary and detailed breakdown of customer support requests. It gives you an idea of how "busy" things are in the world of support.  

There are 3 volume reports  grouped by:

  1. The product/brand
  2. The impact/severity of the issue
  3. The category of the ticket
  4. Escalation Status

There is an additional volume report that shows which partners have raised the most number of tickets and a summary of the same by date.

image.png

Average Response Time

The Average Response Time report tells how fast your team is getting back to customers. It's a metric on quality of support and the reports show you when you're doing well and when there are deficiencies in speed. 

image.png

Filtering The Dashboard

 

Support for multiple products

To set up Freshdesk to allow customers to raise tickets for different products, start by configuring multiple support email addresses—one for each product e.g isco@akvo.org, idc@akvo.org etc. This ensures that tickets are categorised based on the product they relate to. Once done, on the contact us form there is a Product dropdown, allowing customers to specify the product when submitting a ticket. 

Additionally, we set up Automation Rules (Admin > Automations) to automatically assign tickets to the relevant support agents or collaborators based on the product selection.

This setup allows us to also have different SLAs for each product where needed.

QA Process

How QA fits Into the Global Delivery Framework

In Akvo’s Global Delivery Framework (GDF), Quality Assurance (QA) plays a structured and strategic role, particularly within the project implementation and software development phases. QA is not a separate or standalone step, but an integrated part of the project lifecycle, aimed at ensuring high-quality delivery and partner satisfaction.

Integration With GDF Tools and Processes

QA work supports the Project Dashboard and PRO (Project Report Out) submissions:

QA in the GDF ensures that Akvo’s project delivery is:

This systematic QA integration helps Akvo achieve its core GDF objectives:

Scope of the QA Role

The QA will focus on functional testing to ensure that features work as intended. At the initial stage, the focus will be on manual testing using TestLodge to support testing.

The goal of this will be to:

qa_process (1).png

Scoping

Defines the boundaries, objectives, and priorities of the project. The output from this step (scoping notes or high-level technical outline) clarify what will be developed. 

SDD Writing

The TPM creates a System Design Document (SDD) that outlines what needs to be built, detailing technical aspects, feature requirements, and dependencies. For QA, it acts as a foundational reference that clarifies how different user stories relate to the overall system, helping ensure consistency and coverage during testing.

SDD Presentation

The team reviews the SDD together. This is a chance to ask questions, flag missing info, and ensure there's a shared understanding of the approach. The QA uses this to begin designing test cases.

Writing/Updating User Stories

QA uses the SDD to shape or refine user stories, making sure they reflect the latest understanding of the feature. If some stories already exist, they’re updated to align with any new details or decisions.

User Stories Review

The QA team, TPM and the client go through each user story to ensure it's clear, complete, and meets the requirements. This is also where edge cases and test scenarios begin to emerge.

Briefing on QA Tools

QA gives the client a quick walkthrough of the tools (Testlodge in this case) like where to find test cases, how bugs will be logged, and how everyone will stay in sync during testing.

Per Deliverable Execution

Development

The development team begins building the feature or component. This includes writing code, reviewing it internally, and getting everything ready for testing. 

Write or Update Test Plan

As the feature takes shape, QA prepares a test plan tailored to that specific deliverable. It spells out what will be tested, how it will be tested, and what outcomes are expected. This ensures nothing important is missed.

Review Deliverable Test Plan

Before testing begins, the test plan is reviewed by the TPM, client and QA team. This step helps confirm that all relevant scenarios are covered and that the test plan matches the deliverable's scope.

Run Test Plan

QA runs through each test case to confirm everything works as expected and to catch any issues early. The client also reviews the deliverable either on their own or together with QA using the test cases as a guide. This collaborative approach helps ensure the feature meets expectations from both technical and user perspectives. Any bugs or feedback are documented and sent to the development team. If everything passes, the deliverable moves on to approval.

Log Bugs

When issues come up during testing, QA logs them in Asana complete with clear steps to reproduce, screenshots (if needed), and an assessment of how serious each bug is.

Fix Bugs

Developers then work on fixing the reported issues. Once fixes are in place, they let QA know so retesting can begin. This back-and-forth may happen a few times until everything checks out.


Deliverable Approval

Once testing is complete and all issues are resolved, the deliverable goes through a final review and is formally approved by the TPM and the client. If there are more deliverables in the pipeline, the process starts again with the next one.

Project Approval & Closure

When all deliverables have been completed and approved, the project moves into its final stage. A final sign-off is done, and all stakeholders are informed that the project is officially closed.


Responsibilities


Task

TPM

PM

QA Team

Dev Team

Drive scoping

R

A

I

I

Write and present SDD

A

R

I

I

Review and finalise SDD

R

A

I

I

Write, execute, and update test cases

I

I

A/R

C

Provide final QA sign-off

I

I

A/R

C

Develop features

A

C

C

R

Fix defects based on QA feedback

A

I

C

R

A - Accountable R - Responsible C - Consulted I - Informed

QA Onboarding process

For a QA specialist to integrate effectively into a project, the following steps should be taken:

Tooling

TestLodge is a user-friendly, cloud-based test management tool used to support manual quality assurance (QA) processes. It allows teams to create, manage, and execute test cases.

TestLodge is primarily used for the following:

Using TestLodge ensures transparency, traceability, and structured QA practices, while making it easy for both internal teams and clients to stay aligned on testing progress and feedback.

(Record a 3 minute video walk-through for PMs)

Collaboration Between QA, PM, and Dev Teams

Effective QA reporting at Akvo depends on close collaboration between the QA, Project Management (PM), and Development teams. QA specialists share regular updates on test progress, bugs, and blockers through test reports generated in TestLodge. These reports are linked directly to related Asana tasks, making it easy for the team to track what needs attention. Each issue includes clear steps to reproduce, relevant screenshots, and any context that helps speed up resolution. PMs use this information to adjust timelines and communicate with clients, while developers rely on QA input to prioritize bug fixes and enhance feature stability. The use of shared tools like Asana, TestLodge, and Slack ensures real-time visibility, efficient task tracking, and quicker resolution of issues. This helps maintain product quality while ensuring alignment on delivery goals.

Best practices and lessons learnt

Key best practices include:

Project Retrospectives

Akvo encourages a culture of continuous improvement by integrating feedback at every stage of the QA cycle. After each project, retrospectives are held to reflect on what went well, what didn't, and how testing processes can be improved. Client feedback gathered during UAT or post-deployment is also reviewed to identify missed edge cases or usability concerns. This information can then be used to refine and improve QA workflows.

Additional materials

Client deck

QA Process For PMs

📥 Click here to download or play the video

What is QA?

Quality Assurance (QA) is a collaborative effort that ensures we deliver a product that meets partner expectations, works reliably, and is ready for real-world use. It is not just about testing, but building confidence in the product together with the partner.

This document outlines your role in the QA process. While our QA team leads the testing efforts, your input and feedback at key stages is required for the successful delivery of projects

Purpose & Benefits

Quality

We identify and fix bugs early, and validate our work against requirements with the partner, often.

Shared Accountability

We tie partner validations to our deliverables and payments.

Timeline & Budget Control

We do not move backwards, i.e. what is done is done.

Shared Confidence

The process is transparent and collaborative.

Our Software Delivery Process, In A Nutshell

To ensure clarity, transparency, and quality throughout our collaboration, we follow a simple but structured three-stage approach:

image.png

Requirements Gathering

The Requirements Gathering phase lays the foundation for the project. Together with you, we define the problem we’re solving, agree on objectives, and align on what success looks like. 

This includes:

This phase ensures everyone is aligned before work begins, reducing the risk of misunderstandings or scope creep later on.

Execution

This is the main development phase. Based on the scope we’ve defined, we design, build, and test the solution in iterative cycles (referred to as sprints).

During this phase:

This collaborative approach ensures continuous alignment and allows us to address issues early.

Closure

The Closure phase wraps up the project. This is where we:

Once everything is confirmed, the project is formally closed. Any remaining contractual obligations are also completed.

This structured approach gives you full visibility and control, while ensuring we deliver high-quality results that meet your expectations.

Here’s how it plays out in practice: from scoping and writing user stories, through test plans and test runs, to bug reporting, approvals, and final closure

image.png

NB: TPM, QA, PM, and Dev all work together, with the PM often representing the partner’s perspective.

PMs Interactions

  1. Scoping: Collaborate with the TPM to define project goals, features, and priorities your input shapes the entire build.

  2. SDD Presentation: We’ll walk you through the System Design Document to align on functionality and clarify anything that may affect testing.

  3. Write User Stories: Answer questions from the QA team to support them in writing relevant user stories.

  4. Review User Stories: Review and confirm that user stories align with partner expectations, planned features, and flag anything unclear or missing for final adjustment

  5. Briefing On QA Tools: We’ll guide you through TestLodge so you can easily access test cases and report issues—no technical skills needed.

  6. Review Test Plan: We share a test plan for each deliverable so you can see what we're testing, how, and why — and suggest additions if needed.

  7. Run Test Plan: Once the feature is ready, we’ll invite you to test it, either with us or on your own. We’ll guide you to ensure everything meets your expectations.

  8. Log Bug: Found an issue? Let us know via TestLodge or together with us. Clear steps and screenshots help us resolve it faster.

  9. Deliverable Approval: After testing and fixes, you’ll review and confirm the deliverable is working as expected and ready to proceed.

  10. Project Closure: Once everything is approved, we’ll do a final review with you and formally close the project.

Partner Interactions

From an internal perspective, the PM represents the partner. Consequently, whenever the PM is involved for an internal step, that same step can be executed by the partner, representing the external perspective.

Testlodge

Tool used to support manual Quality Assurance (QA) processes. It allows teams to create, manage, and execute test cases.

We use TestLodge for:

TestLodge ensures transparency, traceability, and structured QA practices for internal teams and clients.

See a TestLodge demo in the video above (starting at 05:17).

Summary