Skip to content

Known Issues and Proposed Upcoming Changes - Jul 16 #23

@Dreyhh

Description

@Dreyhh

Known Issues

1. Fix slow load times for emails and client details in some cases.

2. Create table for email templates by credit since currently they are just being harcoded.

Proposed Upcoming Changes

1. Keep track of user activity.

In particular we need records of events such as email was processed, email was sent, etc. This is needed in order to derive some useful analytics including avg user response time etc, some derived info such as "client sentiment" could be generated as well.

2. Develop user analytics dashboard.

Needed to allow the user (and admins) to view the analytics derived from the user activity data.

3. Develop admin (org) page.

When a user is the admin of some org instead of a client list they should be able see information about the org members, including something like mentioned in point 2 for all the users in their org as well as perform some org actions ( adding members, remove them, define credits, requirements, etc)

4. Develop an endpoint to enable integrations such as HubSpot

5. Develop a "Conversation Summary" section.

Since we will keep track of emails we can generate a summary of the conversation so the user can keep track of it more easily.

6. Develop an "Alerts" system.

Inform (via email) users in case there is a client that has been waiting response/or has not responded for a given number of days

7. Develop generalization of the current "Generate Draft".

A "Generate Reponse" option is needed in case the user wants to reply to a client's message that is not asking for list of documents, for this we could use the summary of the conversation and some knowledge base such as an FAQ, of course this should include the case where the intent is to generate the list of documents, IMO we should separate the two to avoid cases where the response type is not inferred correctly.

Worth mention

  • Keep track of token usage per user, we need a way to keep track of costs.
  • Handle the case when we recieve emails from addresses that do not match registered clients i.e user B receives email from address A that is not in the list of clients from user B, do we create a provisional client and process the documents anyway? - the downside of this is possible increased token usage but should be low.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions