MVP for Complaint Manager v2.0

[rnair-tw]

Overview

We want to create a simple Complaint Manager with basic functionality to allow organizations to handle and process complaints efficiently. We do not plan to have all the features in out existing Complaint Manager v1.0 at the moment. While we build it, we should think about scalability, configurability and customization, as well as how to use AI to augment our features.

This MVP will serve as the foundation for further development and refinement, focusing on only the essential functionalities necessary for managing complaints (as outlined below). Post-MVP, we will address address additional requirements and expand its functionality based on user feedback and organizational needs.

Our goals are:

• Demo this to our existing users for feedback and determine a good timeline for them to come onboard to this system
• Build this with the Digital Public Goods (DPG) Standards so that it can eventually get added to the registry: https://digitalpublicgoods.net/registry/ (this sheet lists requirements: https://docs.google.com/spreadsheets/d/1p_esCblUeBHmkx0AL5ZpAaJMYYbatdSyL4YIugXZPg8/edit#gid=0)

Key Features

Tl,dr: A user should be able to log in, see all cases, create a new case, save the case and log out.

In Scope

1. User Authorization and Authentication:

   • Users can authenticate securely to access the system.
   • Basic user roles such as admin and basic user are defined.

2. Dashboard:

   • Users can see an "all cases" view that lists out all the complaints.
   • Users can click on an individual complaints and edit the details.
   • Users can search based on any data fields shown in their view.

3. Complaint Submission:

   • Users can submit complaints through a user-friendly interface with basic information such as:
     • Complaint Title: A brief summary describing the nature or subject of the complaint.
     • Complaint Description: A detailed explanation of the complaint, including relevant information such as dates, events, and any other pertinent details.
     • Date Created: The date and time when the complaint was registered in the system.
     • Status: The current status of the complaint (e.g., Open, In Progress, Resolved).
     • Reporter/Submitter Information: Details about the person submitting the complaint, including name, contact information, and any relevant identifiers.
     • Evidence upload: Any attachments related to the case (pdf)
     • Users receive confirmation notifications upon successful submission.

4. Settings:

   • Admins can configure the following
     • Organization logo to show on the top left of the screen

Out of Scope

• Assignment and Routing
• Reporting capabilities
• Notifications and Alerts
• Letter generation
• User configurability (workflow and data fields management)
• User uploaded tables (people, etc)

Non functional requirements

• Authentication: The system will use Okta for login and authentication, without any significant customization
• Field configurability: Organizations can configure which fields they want to see in "All Cases", based on existing (not new) fields
• Database tables: People involved in case (this can later be mapped to complainant, accused, witness, etc)
• Data storage: A way to store uploaded evidence
• Security and Compliance: Security measures such as encryption, role-based access control, and data privacy policies are implemented to protect sensitive information.
• Scalability: System should be able to support 3 different organizations (with their own users and admins)
• Responsive design: This should work on a desktop, laptop and mobile.
• Accessibility: These requirements should be part of design and testing

Workflow

https://app.mural.co/t/twma7655/m/twma7655/1710367228710/ce4971707c10f55a7a77d35cc767658097e98dad?sender=u53de0f6cc7afb2ef5ee24114

Mockup

https://www.figma.com/file/Qpewv3nKANuv7qm4oJd2Xy/Hi-Fi_Mockups?type=design&node-id=0-1&mode=design&t=OYRql6Eq6iz4lV58-0

Dependencies

• Authentication mechanisms for user registration and login.
• Database infrastructure for storing user accounts, complaints, and related data.
• Frontend and backend development for user interfaces and system logic (design system)
• Configuration and setup for basic organizational profiles and workflow definitions.
• Cost associated with system, especially when transitioning this to system owners

Acceptance Criteria

• [ ] Users can successfully log in to the system.
• [ ] Users can submit complaints with required details.
• [ ] Users can view and manage complaints through a centralized dashboard
• [ ] Users can see complaint progress through predefined workflow stages
• [ ] Users can log out of the system.

Notes

xxxx

[rnair-tw]

Tech questions:

• This is more of a tech question but at what stage are we implementing the “create org, or org adaption step”? It seems extremely fundamental to our product.
• Tech question: as a dev, it’s important to know exactly what settings will be configurable. Do we have an explicit list of what’s configurable?
• Is using Okta by default making us platform dependent?
• Are we gonna use okta for all orgs?
• What specific parts of the create case user can modify? We still need make sure user changes won’t change database data structure