Case Managements Systems

An online application that handles case Difference between customer and OurCustomer: Customer: is someone who uses the customer GUI to create a case/ticket OurCustomer: is companys or people who uses this system, they each have their own portal within the system, many users can belong to one OurCustomer. We will need the full source code and database upon completion. No code can be encrypted in any way. The code and the application belongs to us upon delivery and payment and may not be reused or distributed without our written permission. The code needs to be in ASP.NET C# Specifications: -Design Create an overall design for the application. Preferably one that is easily changed at least through css, or themes -Languages The applications language should be defined in a XML file so one can create new language packages and easily change the language of the application -Portal A portal is a different instance of the application. Basically to separate cases belonging to different OurCustomers (see OurCustomers later in this document) Example: MKF Ekonomi Support, Micosoft Customer Service Portal and so on. These should be able to be created in the GUI by the super admin user. -Separated admin GUI and Customer GUI The admin gui is the system it self, the customer GUI is just a webpage where you can create support tickets through the API (which means you can also create new customer GUI’s since the API is doing all the work) -API A secure API with the ability to create new cases/tickets from outside the admin GUI. The API should also allow fetching cases/tickets in XML structure if a correct token/pw/accesskey is provided -Create case/ticket Create a case / ticket either through an API call or the admin gui. Should be able to assign this to a category and/or a person A case should have a unique ID identifying it and should be able to be reassigned after being created. A case should only be visible to users who belong to the OurCustomer who owns the portal (see OurCustomers and users later in this document) OR a user with superadministrative permissions. An access token should be emailed to the customer when the ticket is created (if it is created by a customer through the customer GUI, this token should be used so the customer can access his case through the customer gui again later, this token needs to be unique for each case/ticket. It should also be displayed when the customer creates the ticket. Case should also contain: Customer full name Customer email Customer phone number Open date Last update date Closed date (if closed of course) Subject (also used as email subject if email updates are enabled) -Updating cases/tickets When updating a case you should be able to flag the post as internal which means it wont be visible to the customer (note, the customer to the ticket not the OurCustomer!) but should be visible to every user in the same OurCustomer within the admin GUI Be able to change status (see Case Status) Able to add attachments (see Attachments) Be able to mark the ticket as closed (only Users can do this, not customers), when closing a ticket you must supply a closed reason -Case Closed Reasons These should be able to be added by users with the right permissions. These are specific to different OurCustomers so one OurCustomer can have different Closed Reasons than other OurCustomers. -Case Status Ability to assign and change status on cases, ability to add and remove new status types -Case Priority Cases/tickets should be able to marked with priorities: low, medium (default), high and urgent -Inbox An inbox containing all the cases for the portal belonging to the OurCustomer (depending on which OurCustomer the user belongs to) -User Inbox The logged in users own queue (cases / tickets assigned to him) Users should also be able to view the inbox of other users in the same OurCustomer if they have the permission, or to view ALL inboxes if it is a super admin Agreed upon price should include design, code & DB..