Handling Electronic Communications

Field

The present disclosure relates to computer systems and methods in the field of handling electronic communications.

Background

A prevalent form of electronic communication which is utilised today is email. Emails are electronic communications which have an address in a particular format (a username and a domain name) and which are routed using that address to recipient end users. Emails may have one or more recipient designated in the email, and in that case, the emails are routed to each of those recipients. There are different categories of recipient. A primary recipient is identified in an “to” field, and secondary recipients may be identified in “cc” (copy) or “bcc” (blind copy) fields.

Each email recipient has a computer device with a user interface which presents the emails to them as they are received. The user interface is termed an “inbox”. An email arriving in an inbox is presented to a user. The email may be presented in bold text indicating that it has not yet been read, and when a user clicks on the email, the content of the email is presented to the user. At that time, the incoming email may be marked as unbolded text indicating that it has been read. There are different paradigms for displaying and marking emails in an inbox. For example, emails may be presented in the order of incoming date or associated with previous conversations or in other ways. However they are presented, the recipient needs to monitor their inbox (or have their inbox monitored for them). Each email needs to be considered. Some emails may be dismissed based only on their heading or brief preview which is visible to a user, and other emails may be dismissed based on category. However, in general, most emails need to be accessed and the content read to consider whether and what action is necessary.

Globally, there are just over 3.7 billion email users worldwide, with 269 billion emails sent each day. At present, Microsoft Outlook is the primary application that is used mainly to send and receive emails across all desktop computers. Note that emails may be sent and received by any type of computing device, not just desktop computers. Particularly in the field of clinical work, healthcare professionals must appropriately and accurately handle each email. Clinicians of all categories have inboxes which they need to manage. In the health sector, in England, the National Health Service (NHS) is a publicly funded national health care system. Approximately 900,000 inboxes are expected to be actively managed just within the NHS. An estimated 50 million emails are processed each day by NHS employees. Most of these employees are not dedicated to inbox management, but are required to manage their inboxes alongside their other roles.

There are several existing difficulties with current inbox management, which are felt by inboxes in all areas, but exacerbated in the healthcare context.

Email management takes too long each day. That is, email management consumes time which could be used by the person for other tasks particularly in the health care setting.

With an average inbox receiving 50 emails each day (based on an analysis of NHS inboxes across England), there remains a high risk of missing relevant emails and not prioritising emails efficiently. The volume of email can become overwhelming daily or at time, for example during an on-call week of night shifts, or after periods of annual leave, and may result in high stress, risk of burnout, and worry about backlog and clinical working during time off.

Searching through emails is possible. However, inboxes quickly become full if they are not appropriately managed. The sheer number of emails in an inbox can make searching through an inbox hard to do to deliver results with accuracy or in accordance with search intention. Further, searches may often be done under time pressure or ‘last minute’.

Inbox management includes several tasks, most of which are manual. One task is reading an email and considering its content. That email may then be deleted, left in the inbox or moved into an appropriate folder. In some inboxes, emails may automatically be categorised into particular folders on receipt, based on the addressee, header of the email, or user-implemented rules. The senders of emails generally expect a reply, either a minimal acknowledgement or a considered reply. If emails are not responded to in a timely fashion, the email sender may send repeated requests for acknowledgement, which causes further cluttering of the inbox. The sender may continue to send reminders even when the recipient has opened the email and acted on it, if the recipient has not acknowledged the email.

Inboxes currently provide an “out of office” facility. This enables a user of an inbox to set an “out of office” notification which will be sent back when a sender sends an email to their inbox or displayed to users within the same domain. That is, an automated acknowledgement of receipt is sent to the sender of the email, indicating that the present recipient is out of office. At that point, the sender of the email needs to decide what further action to take. The “out of office” notification may, for example, advise an alternate potential recipient who may be able to carry out the task of the original recipient.

While these features are helpful, they do not address the challenges identified above.

Summary

The present inventors have developed a solution for handling electronic communications which addresses these issues. They have also developed a framework for evaluating the efficacy of their novel system and method. The new system will allow people to efficiently manage their emails every day. The system may employ artificial intelligence and personalisation to transform how people manage their emails and additionally the system may become responsive to the user’s flexible availability. The system may report on the performance of inbox management by a user, to aid the user or their managers.

One aspect of the invention relates to decluttering inboxes.

According to this aspect there is provided a computer system configured to receive and handle electronic communications, the computer system comprising: a plurality of computer devices each comprising a user interface associated with a named addressee user and having a display configured to display a plurality of electronic communications to the named addressee user, each electronic communication being selectable by the user via input means of the user interface to cause the electronic communication to present content of the electronic communication to the user, and computer memory configured to store electronic communications to be displayed on the display; and an electronic communications triaging module configured to determine at least one of content of an electronic communication and one or more addressee of an electronic communication and select an action based on the content and/or addressee wherein the action has the effect of preventing the incoming electronic communication from being displayed at the user interface of the computer device of at least one addressee of the incoming electronic communication. Preventing the incoming electronic communication from being displayed at the user interface may comprise not providing the electronic communication to the user in any form. In that case the electronic communication may be stored by the triaging module in computer storage remote from the computer device. In other embodiments, the electronic communication may be sent to the computer device of the user for storage in a folder of un-displayed communications, which is accessible by the user for viewing at a time of his choosing. For example they may be accessed and viewed in a panel separate from a user ‘inbox’.

The triaging module may take the form of a routing module configured to receive incoming electronic communications and to detect a set of named addressees in at least some of the electronic communications. The routing module may be further configured to determine a subset of the named addressees as a group of responsible named addressees and to transmit the electronic communication only to a subset of the computer devices associated with the responsible named addressees and to prevent the incoming electronic communication from being displayed at the computer devices of the remaining named addressees of the set.

The set of named addressees may be defined in a group identifier.

The routing module may be configured to determine one or more named addressee in at least some of the electronic communications, and to determine an alternate addressee based on the content of the electronic communication, wherein the routing module is further configured to transmit the electronic communication to the alternate named addressee and to prevent the electronic communication from being displayed at the computer device of the named addressee.

The action selected by the triaging module may be to determine a sender of the electronic communication and to generate an auto response based on the determined content of the electronic communication. The triaging module may be configured to effect the action by transmitting the auto-generated response to the electronic communication sender.

As mentioned, the inventors have further provided a technique for an evidence-based methodology for determining the effectiveness of such a system. According to this aspect of the invention, there is provided a method of monitoring the performance of a software tool configured to manage electronic communications, the method comprising: providing a computer device having a user interface associated with a named addressee user and having a display configured to display a plurality of electronic communications to the named addressee user, each electronic communication being selectable by the user via input means of the user interface to cause the electronic communication to present content of the electronic communication to the user; installing a monitoring component of the software tool to access the computer device and to monitor the handling of the electronic communications by the named addressee user at the user interface of the computer device to determine a base set of metrics; installing a user interface component of the software tool to modify the user interface of the computer device; monitoring the handling of electronic communications by the named addressee user at the computer device to determine a new set of metrics associated with the handling of electronic communications by the user at the modified user interface; and comparing the base and new sets of metrics to determine the difference between the handling of electronic communications at the user interface compared to the modified user interface.

The software tool may generate metrics based on one or more features based on the modified user interface. Example features are described in more detail later.

Such metrics may comprise objective data arising from technical data representing the technical state of the electronic communications, such as time spent on one or a number of communications, or a total number of communications handled in a monitoring period. Also, questionnaires may be provided (via the user interface or by any other means) to the addressee users of computer devices of the first and/or second sets to obtain subjective data from such users. The metrics may be formed as a combination of the objective and subjective data.

According to this technique, a clinical trial technique is utilised to confirm the value of the system.

In another feature, performance of inbox management may be monitored. This can help to identify overload and erratic inbox handling, which may indicate factors such as fatigue or stress which can contribute to a degradation in wellbeing. It can also help to measure the communication wellness of the user

According to this aspect of the invention, there is provided a method of monitoring the handling of electronic communications presented to a recipient at a user interface of a computer device, the method comprising: recording in computer memory, one or more first datapoint for each incoming electronic communication, each first datapoint in a performance category to be monitored; displaying at least some of the incoming emails at the user interface for action by the recipient; recording one or more second datapoint for each incoming communication which has been displayed to the recipient, the second datapoint relating to an action taken by the recipient when accessing the electronic communication; and determining a performance monitoring period and aggregating the first datapoints and second datapoints over all electronic communications received and displayed to the recipient in that monitoring period to provide a performance indicator for that monitoring period.

The first datapoints may comprise the time of receipt of an incoming electronic communication and/or a severity score which has been assigned to the electronic communication based on an estimated time needed to address the email based on its content.

The second datapoint may comprise the time at which the recipient actioned the incoming communication and/or the action taken and the time taken to action by the recipient.

Aggregating the datapoints may comprise the performance indicators shown in Annex A.

Another aspect of the invention enables a recipient device to act as an avatar for the recipient in the handling of electronic communications. According to this aspect, there is provided a computer device configured to receive, record, analyse and handle electronic communications, the computer device comprising: a user interface associated with the named addressee user and having a display configured to display a plurality of electronic communications to the named addressee user, each electronic communication being selectable by the user via input means of the user interface to cause the electronic communication to present content of the electronic communications to the user, computer memory configured to store electronic communications to be displayed on the display, a schedule access module configured to access a schedule of the named addressee user and to determine from the schedule the presence or absence of the named addressee user and to act on the electronic communication based on that determination. Embodiments may provide additional communication modules integrated into the communication environment of the avatar to handle emails as well as messages on mobile devices such as texts, messages via Whatsapp, Teams, Zoom chats, electronic health record messaging platforms for handling as per emails.

The computer device may form part of a computer system in which there is a plurality of such computer devices, each associated with the respective named addressee user. The computer system may comprise a routing module configured to access a scheduling module that holds schedules for the named addressee users. The routing module may determine from the scheduling module whether the intended recipient of an electronic communication is present or absent based on their schedule, and determine how to route the electronic communication accordingly.

If the intended recipient is indicated as available, the electronic communication is routed to their inbox. If the intended recipient is not immediately available, an alternate recipient is selected for the electronic communication and the electronic communication is routed to that alternate recipient. A notification is sent to the sender of the electronic communication indicating that their electronic communication has been re-routed, and may give some information about the re-routing, for example, indicating the new recipient and indicating that the cause of the re-routing was based on the schedule of the originally intended recipient.

Aspects of the invention further provide additional features to aid a user in achieving efficient inbox management. Such features may cause email users to feel that they have more control over the administrative pressures of their job, therefore leading to an improvement in their wellbeing, particularly as during off duty time, emails may be re-routed away from the user. In many countries, there is a mandate to protect users from work related communication outside working hours which presently is not available to health care workers in many countries. The avatar will endeavour at all times to confirm whether a user is on duty or off duty as part of their unavailability preventing stacking up of communications often causing stress on starting work with a backlog.

The routing/triaging module may select an alternate addressee or addressees based on capacity. Capacity is a parameter associated with each user (more specifically, the inbox of each user). A computer memory stores a capacity measure for each user in the system. Capacity may be measured in a number of different ways. One measure is to count the number of emails in an inbox which have not been handled by a user. Note in this context that handling could in one embodiment mean reading, such that any unread emails would be counted as a measure of how many emails are left in an inbox. In an alternative embodiment, emails may automatically be removed from an inbox once they have been marked as handled by a user. In that case, the count of emails remaining would be emails which have not been designated as handled by a user (or by an auto tool). Users with the lowest number of emails in their inbox may be considered as having more capacity than users with a higher number of emails remaining in their inbox.

Another measure of capacity may be associated with complexity scores for emails. A complexity score may be associated with each email in an inbox. The complexity score may be automatically allocated based on a tool determining the content of the email, or may be assigned by the sender of the email. In some embodiments, a tool may learn how to assign complexity scores by setting complexity scores and then monitoring user performance relating to those emails with the assigned complexity scores.

A user response pattern may be taken into account when considering capacity. Some users may be more efficient at handling their inbox either in a particular period of time, or overall. User response patterns may be monitored and taken into account when determining a capacity value for a particular inbox. A user response may be determined in terms of the amount of time that a user takes to handle a particular email. It is assumed that complexity of an email is correlated with the amount of time taken to deal with it.

Note that the triaging module may operate when the intended addressee of an email has a nonhandling setting set for their inbox. For example, a non-handling setting may be an “out of office” setting set for their inbox. In alternative embodiments, the triaging module may be effective when the intended addressee is “in office,” but has a non-handling setting which is a status which means that they are not at that time handling their emails. For example, in a clinical setting, such a status may be “patient-facing”. Such a setting could be auto set based on rotas, or set by a user. For example, such a setting could be instigated by clicking on a button or using verbal commands in the user interface.

Note that when a user is out of office for a prolonged period, e.g., a period longer than it would take to resolve a task in an email, there is no reason that the user should receive an email during this period. By re-routing an email to an alternate recipient without displaying the email to a first out-of-office recipient, the volume of emails that the first user has to resolve upon returning to the office may be reduced. This may have a positive effect on the first user’s wellbeing. Note that in some examples a user interface region, referred to herein as a “don’t drop the ball (DDtB) panel”, may be implemented on the first user’s inbox UI, as described with respect to Figure X. The DDtB panel may provide an alternate list region in which emails received during a period of unavailability are displayed, and wherein a completion status of those emails is displayed.

The concept of an email “avatar” is presented herein. An avatar can take the form of a tool which can learn how a user handles their inbox. For example, an avatar could predict how much time might be needed to deal with the current quantity of emails in an inbox, based on number and complexity, for example.

An avatar may have a “learning mode” in which users indicate email complexity and the time needed to handle it. Alternatively, in the learning mode, the tool the avatar could monitor the handling of particular emails based on their content and the time taken by a user to deal with it and whether that time was during work time or outside work specified shift time if available.

The learning mode may also be referred to as “estimate mode”.

The avatar may have a correlate mode in which it compares actual time usage by a user handling their inbox with the estimates that it learnt. It may then understand the discrepancy and improve its own learning.

The avatar may have an advanced predictive mode in which it can handle a user’s inbox in a more sophisticated manner; the trained mode may also be referred to as an “advanced” mode.

One way of determining the importance of an email is to use a natural language processing tool to extract language-based features. Such features may then be correlated to the amount of time spent by a user on that email.

In some embodiments, the avatar will also note and understand how much of that time handling communications was during work shift and outside hours additionally and make attempts to reduce off duty communication management with both predictive algorithms and user training.

Additionally, the avatar may attempt to select communication reading and replying modes other than typing, such as reading out loud when allowed, reducing physical device facing time. This is considered extremely desirable by health care and other workers particularly as device handling and sharing may be a source of transmission of physical risks such as virus particles. In some embodiments, the avatar could request the sender of the email for an estimate of time which the sender believes the recipient would need to handle the email. The avatar could use that time estimate, or could modify that time estimate based on its learning.

Note that the avatar could actually implement a number of different models (for example machine learning models. One machine learning model could learn issues around time. Another machine learning model could understand users’ predicted responses, and then another machine learning model could learn about auto routing.

In some embodiments, a sender may indicate how much time would be needed to handle an email without a request being made by the avatar. In some embodiments, a rules-based auto routing system could be implemented based on time estimates (for example, from a sender) and the number of emails in an inbox.

Avatars could learn over time which emails are important based not only on content but also on addressee. For example, emails which are “cc” or “bcc” could be downgraded in importance. In some embodiments, they could be removed entirely from the addressee’s inbox and summarised to present a summary of content over each time period, for example each hour or each day.

An unsubscribe feature may be implemented in which it is possible for a user to unsubscribe from a thread of email distribution, even informing other users of reasons if available. A collation of unsubscribe reasons will be grown from user training allowing more sophisticated inclusion and exclusion of users, compared to the current practice of many users included by default even after leaving their posts and moving organisations.

A rollback feature may be implemented by which it is possible to return an inbox to a previous state.

For a better understanding of the present invention and to show how the same may be carried into effect, reference will now be made by way of example only to the accompanying drawing.

Brief description of the drawings

Figure 1 is a schematic block diagram showing modules of an inbox management tool.

Figure 2 illustrates an existing graphical user interface showing an inbox.

Figure 3 is a flow chart illustrating a process for scoring inbox management. Figure 4 shows regional dispersion of survey participants; graph showing total number of participants plotted according to daily survey response numbers across specific recorded dates.

Figure 5 is a graph showing number of participants against types and frequencies of communication used during peak of the COVID- 19 pandemic.

Figure 6 is a graph showing estimated daily average number of email and WhatsApp messages, respectively, received by staff across a range of workday modes both before and during COVID- 19.

Figure 7 is a graph showing number of staff responses to the statement “The NHS needs a framework to manage work communication” with relation to their email volume.

Figure 8 shows a highly schematic diagram of a plurality of email inboxes, interconnected across a network.

Figure 9 shows a flowchart that illustrates an exemplary process by which an avatar learns a user patterns of email management.

Figure 10 is a table that shows exemplary performance indicators for email users.

Figure 11 is a table that shows exemplary markings for emails in particular channels.

Figure 12 is a table that shows exemplary markings for particular sending actors.

Figure 13 is a highly schematic diagram that shows an exemplary email user interface in which certain features disclosed herein are implemented.

Figure 14a shows an exemplary interface for defining a new rule for a rules-based highlighter.

Figure 14b shows an exemplary interface for voting on a new entry to a global dictionary.

Figure 14c shows an exemplary interface for defining a new selectable hyperlink in a hyperlink menu of an inbox user interface.

Figure 14d shows an exemplary interface for creating a shared email folder.

Figure 14e shows an exemplary interface for defining a time period, defining a trigger word or phrase, and nominating a recipient email address to which any emails including the trigger which are received within the time period are re-routed.

Figure 15 shows a portion of an exemplary inbox user interface which includes a selectable feature corresponding to a shared folder. Figure 16 shows a portion of an exemplary inbox user interface which includes a “Don’t Drop the Ball” panel.

Figure 17 shows a workflow that represents the Don’t Drop the Ball re-routing process.

Detailed description

The present disclosure addresses a new system for managing inboxes. Although the invention is described in the context of managing emails in an inbox, it will readily be appreciated that the principles described herein may be applied to any type of electronic communication.

The disclosure addresses several different facets of inbox management and performance. The concept of “performance” is a novel concept presented herein and is particularly important in maintaining favourable working practices and mental health of inbox users. The concepts are described herein in the context of a clinical field in which clinicians and other personnel are managing their inboxes themselves. Note that the term ‘clinician’ may be used herein to refer to any email user within a clinical field. This may include doctors, nurses, assistants, researchers, other healthcare professionals. However, it will readily be apparent that the principles may be applied to any other field for inbox management. The concept of “performance” is related to the effect on users of the time that they are taking to manage their emails.

Each day, it is estimated that in England alone, 200,000 clinicians spend time managing their emails. These emails vary widely across a variety of needs from clinical queries to appraisal, scheduling meetings, discussing research projects, service commitments etc. There is an extensive range of tasks required by users when responding to emails. However, responding to the email itself is a task which is added to the other tasks that they are supposed to do in their day. Research has shown (as discussed later herein) that clinicians in particular spend too much time handling their emails, and as a result may become stressed or perform poorly in other areas. They may end up handling their emails in a non-optimal fashion as a result of this. For example, they may prioritise “quick” emails, while leaving urgent (perhaps more complex) emails until later in the day when they are less able to cope.

Figure 2 illustrates a graphical user interface showing a user’s inbox in an existing system. As shown in Figure 2, the inbox shows emails that have been received addressed to that user (either as a direct recipient or in copy), each email denoted 20. There is a version shown on a desktop denoted by reference numeral 1A and the version shown on a mobile device denoted by reference numeral IB. In both cases, incoming emails are shown in sequence as they are received. A conversation mode is known in which incoming emails may be sorted into conversations. Furthermore, emails may automatically be diverted into specific folders, folders being shown listed on the left-hand side of the desktop GUI 1A. The inbox is largely passive in its engagement with the user. Apart from auto-routing into individual folders, and spam/junk management, the handling of emails is left to the users themselves. That is, a user must monitor his inbox and determine by viewing each email whether or not they need to act on that email immediately or whether the email could be de-prioritised. Note that the present system does provide certain possibilities to mark emails from the sender’ s side, for example with an urgency marking, but the sender does not understand the context in which the emails will be received. An email marked urgent from a send side may not necessarily be urgent to the recipient. Furthermore, at present, users of inboxes do not have any feedback given to them about their own inbox performance.

Before describing the features of a performance monitoring system for monitoring inbox performance, a method for assessing the effectiveness of such a system is outlined. The principles of a clinical trial, of the type used for medicine and drugs, are adopted.

The purpose of the trial is to examine the use of the software tool presented herein. As described in more detail later, the software tool provides functions such as separating clinical patient related emails from non-clinical emails, ensuring clinical emails are all responded to as needed, ensuring time is scheduled for clinical email management and various other solutions to release time from email for clinical activities and to improve clinical satisfaction with email management.

A set of computer devices is assigned to each of a number of users. Each user has their inbox presented to them on a user interface of their computer device. In principle, it may be possible for two users to use the same computer device (and access their own inbox), but in most scenarios that would not be practical.

A performance monitoring module is connected to record inbox activity. The performance monitoring module records at least one datapoint for each incoming email to the inbox. These datapoints will be discussed later. At least some of the incoming emails are displayed to the user on the user interface in their inbox. When a user actions an email, one or more second datapoint is recorded associated with that email and with that user. Monitoring periods are determined, and the first and second datapoints are aggregated over the monitoring period to provide one or more performance indicator. The performance indicators will be discussed later.

The users are asked to manage their inboxes for one or more monitoring period, and the performance indicators are generated for each user over the one or more monitoring period. This is to set a control benchmark against which the performance of the software tool will be tested.

During the control period, baseline data is collected using the datapoints, the baseline data being collected on email traffic, time management, filing habits, response rates and other aspects. This is objective data because it arises from technical data representing the technical state of the electronic communications, or the technical result of actions taken by a user. Subjective data may also be collected by providing a questionnaire to the users concerning their satisfaction and confidence with email management techniques.

After the control monitoring periods, the software tool is loaded into each computer device to manage each user’s inbox according to the features described herein. Suitable training is given to the users to enable them to use the software.

After training the software tool is activated to enable the new user interface and corresponding datapoints are selected to provide corresponding performance indicators. In addition, a questionnaire is provided to obtain subjective data.

An additional monitoring period may be implemented, wherein the software may be deactivated or removed, following a monitoring period in which the tool has been active.

The objective data established in the control period may be compared with the objective data in the one or more trial period, to assess improvement in performance. In the case that an additional monitoring period is prescribed, wherein the software is not active, the objective data established in the monitoring periods may also be compared to assess a user’s ability to manage their inbox without the tool, after having become accustomed to the features of the tool. Similarly, the subjective data may be compared in the control and trial periods.

An alternative method of assessing the effectiveness of such a system is also given, the method comprising: providing first and second sets of computer devices, each computer device having a user interface associated with a named addressee user and having a display configured to display a plurality of electronic communications to the named addressee user, each electronic communication being selectable by the user via input means of the user interface to cause the electronic communication to present content of the electronic communication to the user; installing a monitoring component of the software tool to access the first and second sets of computer device and to monitor handling of the electronic communications by the named addressee user at each computer device to determine a base set of metrics based on data received from each of the computer devices; installing a user interface component of the software tool to modify the user interface of the second set of computer devices without modifying the user interface of the first set of computer devices; monitoring the handling of electronic communications by each named addressee user at each of the first and second sets of computer devices to determine a first set of metrics associated with the first set of computer devices and a second set of metrics associated with the second set of computer devices; and comparing the first and second sets of metrics to determine the difference between the handling of electronic communications at the user interface of the first set of devices compared to the modified user interface of the second set of computer devices.

The new software tool will now be described. The software tool is implemented by one or more computer program which is executed on one or more computing device. Certain functions of the software tool may be implemented by executing a computer program on one or more processor of a user computing device (for example with a GUI with which the user engages). Other functions may be executed at a ‘backend’, implemented by a server or other central processing device or network of devices. Computer memory may be provided internally of or accessible by the processing devices. In particular, each user computing device may have local memory, and may access remote (backend) memory.

The aim of the software tool is to improve user experience when handling their inbox, and to address the challenges outlined above. In particular, the following themes are addressed.

It is possible to reduce email time management, therefore releasing clinical time for clinicians to carry out the tasks for which they are mainly employed. It is possible to automate and augment certain email responses, to improve clinical effectiveness.

It is possible to improve clinical confidence and satisfaction, and thus, enhance clinician’s wellbeing.

The system enables clinical emails needing the attention of a clinician to be visualised as a priority within seconds, such that a clinician may prioritise those emails for handling.

The tool may provide a clinician with an estimate of time that they would need to manage incoming emails in a certain period, to allow the user to allocate the correct amount of time to emails with a certain level of certainty.

The tool enables cover for colleagues to be managed in a more automated fashion by automatically determining that a particular recipient may not be the optimal recipient (for a number of reasons) and re-routing the incoming communication to an appropriate colleague.

The tool will now be described in more detail.

The tool comprises a triaging module 10. The triaging module 10 has a number of functions which aim to declutter the inbox of a recipient. The triaging module is located to receive incoming emails 20. Each incoming email comprises at least a header 200 and content 202. The header comprises details of an addressee, for example John.Smith@company.com. The address comprises a user name and a domain name, as it is well known in the field. The address defines a unique recipient for the email. Headers may include direct recipients or “copy” recipients. Copy recipients may be direct copy (cc), or blind copy (bcc). In conventional systems, the named addressee is used to route the email to a particular inbox associated with that particular recipient. In the present system, the email is received by the triaging module 10 which determines how to route the email based on a number of parameters.

According to one parameter, the triaging module can determine whether or not the primary intended recipient is available to receive the email at the time in which it is received. For that purpose, the triaging module has access to schedules 12 of a number of recipients in the domain of the email system. Each recipient may have their own schedule, or only some of the recipients may have schedules. The schedule may comprise for example a work rota which indicates whether emails received into that particular inbox for that particular work purpose will be read by the intended recipient at that time. If it is determined using the schedules that the particular recipient is not available, the triaging module accesses a teams module to determine possible alternate recipients for the email. Each recipient in the system has a list of comprising one or more alternates who may deal with their emails. The triaging module checks the first recipient on the list, and if they are available, routes the email to that recipient. The triaging module issues a notification 30 to the sender of the email to advise him that the email has been automatically re-routed.

In some embodiments, the re-routing may include some level of user interaction. For example, the triaging module 10 may, upon determining that the first recipient is soon going to be unavailable, provide a user interface element configured to control the triage module 10. The interface element may comprise one or more selectable option. Each of the one or more selectable option may be associated with a corresponding one of the alternate recipients. The first recipient may select one such selectable option, thereby selecting which of the alternate recipients receives the email and becomes responsible for the associated task.

In some embodiments, the triaging module 10 may implement a contract feature and an action tool. The contract feature may allow the alternate recipient to accept or decline a task included in a re-routed email. For example, upon re-routing of an email to an alternate user, a user interface feature comprising selectable options to accept or decline the re-routed email may be provided on the inbox user interface of the alternate user.

The action tool of the triaging module 10 may provide one or more reminder or prompt to a user who is responsible for a particular task included in an email, be they a first recipient or an alternate recipient. A prompt may be provided in a user interface element, such as a pop-up notification, and may identify the task for which the recipient is responsible, alerting the recipient of the task’s incomplete status. Prompts may be sent at regular time intervals while the task remains incomplete.

In some embodiments of automatic re-routing, the one or more alternate recipient may be ranked according to a suitability or specialism matching score of each alternate recipient, the suitability score based on, for example, capacity to receive more emails, schedule availability, and/or one or more other parameter. The triage module may attempt to re-route an email to an alternate recipient with a highest suitability score. If the most suitable alternate recipient accepts the task included in the re-routed email, that user becomes responsible for the task and may receive prompts with respect to that task, as described above. If the most suitable alternate recipient declines the task in a re-routed email, the email may be re-routed again to a second- most suitable alternate recipient. Note that the above process may be repeated until a suitable alternate recipient accepts the task. That is, a task included in an email may be tracked by the host system until a contract between the first recipient and an alternate recipient, to whom the email is re-routed, is signed. When the task has been completed, the action tool marks the electronic communication to indicate that it has been actioned. A task complete flag may be set in computer memory in association with the electronic communication. The task complete status may be visually indicated to each other recipient of the electronic communication (for example by colour, border or a message) so that if they access the electronic communication, it will be clear that the task has been completed, and they do not need to attend to it.

Further, by providing prompts to resolve tasks, as described above, the action tool reduces the likelihood that an important task is overlooked or forgotten about. Such a feature may reduce anxiety levels of email users, as the users have increased confidence that outstanding tasks will be flagged if they are not immediately dealt with.

Known systems do not provide features that assist a user in preparing for upcoming leave. The inbox user interface described herein may provide a feature that alerts a user of upcoming scheduled leave. The feature may remind the user, for example through notifications surfaced on the inbox UI, to switch on out-of-office auto-emails, to focus on clearing urgent emails, and to review their to-do list before going on leave. Note that in some examples the feature may automatically implement out-of-office auto-emails, and may automatically identify the most urgent emails in the user’s inbox.

Figure 16 shows an exemplary portion of an inbox UI 1600, the inbox UI 1600 comprising a “Don’t Drop the Ball” (DDtB) panel 1602 associated with a memory location in which rerouted emails are stored. The DDtB panel 1602 may be configured to display data pertaining to emails which have been re-routed. Details of mechanisms by which emails are identified for re-routing are described earlier herein. However, by way of example, emails displayed in the DDtB panel 1602 may be identified by the system or by the user as comprising an action request, and/or being associated with a deadline.

The DDtB panel 1602 of Figure 16 comprises a first email structure 1604, which corresponds to a first re-routed email. The first email structure 1604 comprises a plurality of fields in which data pertaining to the corresponding re-routed email is displayed. A deadline associated with an action request included in the associated email is displayed in a deadline field 1606. An initial recipient field 1608 identifies a user who was initially designated as responsible for the action request of the email corresponding to email structure 1604. In the example of Figure 16, the user of the exemplary inbox UI 1600 was the intended responsible recipient for the action request included in the email corresponding to email structure 1604; they are identified as such in the initial recipient field 1608.

The first email structure 1604 further includes a triaged user field 1610, configured to identify one or more alternate recipient to whom responsibility for the action request included in the corresponding email is passed, upon re-routing of the corresponding email. That is, the triaged user field 1610 may comprise one or more email address of one or more corresponding alternate user. The first email structure 1604 further comprises a task description field 1612, configured to provide a summarised description of the action request included in the associated email. It will be appreciated that the deadline displayed in field 1606 and the task description of field 1612 may be automatically constructed by the host computer system, based on content of the corresponding email.

The exemplary DDtB panel 1602 of Figure 16 further shows a second email structure 1614 corresponding to and displaying data pertaining to a second triaged email. In the example of Figure 16, the second email structure 1614 displays data pertaining to an email re-routed to the user of the exemplary inbox UI 1600. That is, the user of inbox UI 1600 has been made responsible or has accepted responsibility for the corresponding email. In the example of Figure 16, the second email structure 1614 further comprises a task complete flag 1616, indicating that the user responsible for the email’s associated action has completed that action. Note that since the user of inbox UI 1600 is responsible for the action request identified in email structure 1614, the email may also be displayed in a main list region of their inbox. It will be appreciated that the DDtB panel 1602 is provided to reduce, within a main email list region of an inbox UI, the volume of irrelevant emails for which a user is not responsible, including emails received during a prolonged period of unavailability.

Figure 17 shows a workflow that represents the Don’t Drop the Ball re-routing process.

Another issue that both arises from and contributes to high email-related stress is the risk of email data breaches. Known systems have minimal risk reduction features in place for identifying potential data breaches and notifying users of the risk. Such features may include default pop-up notifications that identify an addressee as being outside an internal email domain. However, these features do not identify a source of potential data breaches within emails, and would provide such a notification to the sending user whether or not the email would breach privacy rules. There remains a high likelihood that mistakes which would lead to a data breach would not be identified. Consequently, users may experience increased stress or anxiety when sending confidential emails. Note also that such increased stress and anxiety may itself increase the likelihood that a user makes a mistake.

The inbox UI may include a data breach detection system that identifies email content which, if sent outside a designated email domain, may constitute a data breach. In a medical context, for example, the designated email domain may be an NHS domain. The data breach detection feature may provide a pop-up notification on the surface of the inbox UI, alerting the user to a potential data breach in an email and identifying the confidential content therein. Note that the pop-up notification may be provided upon user selection to send the email. Alternatively, the notification may be provided upon detection of confidential information being input as content to an email.

Exemplary content that is identified as a potential data breach may include such information as names, home or work addresses, dates of birth, contact details or any other relevant identifying information. Note that in a medical context, personal information such as medical record data included in an email may also be identified as a possible breach of privacy. The data breach detection feature may use a rules-based approach and/or artificial intelligence such as NLP to determine whether an email contains confidential information, and whether that information is at risk of being distributed to addressees outside the designated domain.

Another parameter that is used by the triage module 10 to distribute emails to alternate recipients may be the content of the email. A content module 16 in the triaging module 10 assesses the content of the incoming email 20. This may be done for example using natural language processing trained in the medical field to assess the meaning in the email. The content module comprises a natural language processing module which uses NLP (natural language processing) techniques to extract meaning from human language used in the emails to make decisions based on the extracted meaning. Some forms of NLP use artificial intelligence (Al) techniques. NLP tools are known, which use feature extraction from text to determine semantic meaning. An ontology may enable useful meaning to be extracted from free text human generated language as used in electronic communications such as email.

Natural language processing algorithms can be applied to understand email conversations and identify automatic actions such as calendar management, confirmations etc. Natural language processing algorithm can be applied to evaluate each email and assign prioritisation scores and order based on an auto-ranking function. This enables several tasks of managing the inbox, which are currently done manually by the user, to be completely automated. For example, tasks such as identifying unwanted emails, saving important dates, categorising emails and archiving emails may be carried out by the triaging module based on the content of the email as determined by NLP.

The triaging module assesses (based on the meaning) whether the incoming email provides sufficient information to a clinician for the clinician to provide the requested response. For example, a patient may make an inquiry but without giving adequate information. In existing systems, a clinician would need to read the email and then send a separate email requesting further information. In the present case, this is automatically handled by the triaging module.

Based on the triaging, the triaging module 10 sends certain emails to a display module 40 to control the display of emails at the recipient’s inbox. Note that these emails incoming to the display module 40 may include emails which were originally addressed to the particular recipient, or emails that have been auto-forwarded from the triaging module associated with another inbox. The display module has the function of marking emails according to particular channels. The marking of emails in particular channels is shown in Figure 11.

Emails may also be marked based on the sending actor. Examples of sending actors are given in Figure 12.

Other ways in which emails and content therein may be marked visually are now described. A system hosting the inbox user interface may provide a rules-based highlighter feature. The rules-based highlighter may be configured to identify content within an incoming email, according to one or more predefined rules. For example, the rules-based highlighter may identify, within an email, words and phrases that are included in a global dictionary. In a medical context, the global dictionary may comprise words and phrases related to medical practice. The rules-based highlighter may be further configured to identify a particular format of characters indicative of an ID code. For example, in a medical context, the highlighter may be configured to identify patient ID numbers, such as NHS numbers, Medical Record Numbers (MRNs) or other identifiers. It will be appreciated that the highlighter feature may be configured to identify other important content within an incoming email.

The rules-based highlighter may perform the above-described analysis on email content as each incoming email is received. Subsequent selection of an email by the recipient causes presentation of the content of the email. Upon presentation of the selected email, the system may apply a visual indicator, such as highlighting or a background colour change, to the important content of the presented email. The highlighter may apply a visual indicator to a full sentence if the sentence comprises a deadline or a patient management request. In some embodiments, rules-based highlighting of content in an email may only be applied to incoming emails whose content includes 50 words or more.

The system may be trained to determine a body of an email, excluding salutations, signatures and disclaimers, such that these regions are not highlighted.

Figure 13 shows an exemplary inbox user interface (UI) 1300. Figure 13 includes highlighted content 1318, the visual appearance of which has been modified by the rules-based highlighter. That is, content 1318 includes a visual indicator, which indicates that the content 1318 has been identified as important by the rules-based highlighter.

The rules according to which the highlighter feature identifies important content may be customisable by each user to personalise highlighting of email content. For example, the inbox user interface may provide a feature that allows a user to provide additional words and/or phrases to be identified by the rules-based highlighter as important.

In the example of Figure 13, a selectable user interface feature 1304, labelled “Add Highlighter Rule” is shown on the inbox UI 1300. Selection of selectable feature 1304 may cause the user interface to display a rule configuration interface on the surface of the inbox UI, the rule configuration interface configured to receive user input of a word or phrase that the user wants the highlighter to identify as important.

Figure 14a shows an exemplary rule configuration interface 1400. The exemplary rule configuration interface 1400 comprises a word input region 1402, a selectable confirmation option 1404 configured to confirm the user input, and a selectable cancel option 1406 the cancel the rule configuration. Upon input of a word or phrase into the word input region 1402, the word or phrase entered therein may be added to a data structure in memory 803, the data structure containing all such important words or phrases.

Words and phrases stored in a global dictionary may also be updated. For example, the inbox user interface may provide a platform through which users submit potential additions to a global dictionary. Such a platform, when displayed on the surface of the inbox UI 1300, may be visually similar to the rule configuration interface 1400 of Figure 14a. Words or phrases entered to the dictionary submission platform may be stored to a “potential dictionary entries” data structure in a network memory 803. In the example of Figure 13, the global dictionary submission platform may be accessible via selection of a corresponding selectable feature 1308, referred to herein as the dictionary submission feature 1308. The addition of new words and phrases to the global dictionary may be decided by vote; e.g., by multiple users through a voting feature of the inbox UI.

Figure 14b shows an exemplary voting platform 1408. The voting platform 1408 comprises a prompt message 1410, which indicates the function of the platform 1408, and a vote subject region 1412 comprising a word or phrase on which the user votes. The voting platform 1408 further comprises a selectable “yes” option 1414 and a selectable “no” option 1416, selection of which records the user’s opinion, respectively for or against the addition of the term in the vote subject region 1412 to the global dictionary. A term that is successfully voted into the global dictionary may be removed from the potential dictionary entries data structure and saved instead to a global dictionary data structure. In some examples, a term may be successfully voted in upon reaching a predetermined threshold number of “yes” votes. In other examples, a submitted word or phrase may be voted upon within a predetermined time period and addition to the global dictionary may be based on a majority vote.

An email inbox user interface may comprise a list region 18 and a presentation region 22, as shown in Figures 2 and 13. The list region 18 of Figure 13 comprises a plurality of received emails 1320, labelled “Email 1” to “Email 5”, wherein each entry in the list region 18 represents a received email 1320 and may display a sender address and a subject of the corresponding email. The presentation region 22 of Figure 13 displays content of a received email 1320 that has been selected for presentation. In the example of Figure 13, the email 1320 labelled “Email 1” in the list region 18 has been selected for presentation, and includes a visual indicator that indicates that the content shown in presentation region 22 corresponds to Email 1. In some embodiments, the rules-based highlighter may assign a visual indicator to a received email 1320 in the list region 18, the visual indicator being indicative of a severity or urgency level of that email. The rules-based highlighter may determine the severity level of each incoming email by determining a number of instances of important content identified in each email. The highlighter tool may then assign a visual indicator to each received email 1320 in the list region 18. Note that a visual indicator for a particular email may be displayed on the list region 18 of the inbox user interface 1300 whether or not that particular email is open in the presentation region 22. In some embodiments, the position of each email within the list region 18 may be automatically determined based on a severity level. This feature may be referred to as “smart viewing”. The severity level used for smart viewing may be determined by calculating the number of instances of important content within an email, according to the rules-based highlighter. In other examples, a density of important content may be calculated to generate a severity level; e.g., by dividing the total number of important content instances by the word length of the email. By ordering emails in the list region using a severity score, the most important, pressing, and complicated emails — which include more terms identified by the rules-based highlighter — may be relocated to the top of the list region 18.

A relevance rank may also be applied to relocate emails within the list region 18. For example, patient-related emails may be displayed above educational or general correspondence emails when the user is a clinician. Similarly, emails related to research projects may rank highly, and be ordered as such on the list region, if the user is a researcher. The above-described rankings may be weighted based on preferences of each user, either through a user survey or based on preferences determined by suitably trained Al software.

An advanced hyperlink feature is now described with reference to Figure 13. In some examples, the advanced hyperlink feature may work in conjunction with the rules-based highlighter feature described above. The advanced hyperlink feature may be accessed by selecting (e.g., by right-clicking with a mouse) content 1316 within an email. The user may manually select content 1316 to access the advanced hyperlink functionality, or may select content that is deemed important by the rules-based highlighter. Upon selection of an instance of content 1316 within an email, a hyperlink menu 1314 user interface feature, comprising one or more selectable hyperlink options 1310, 1312; exemplary uses of selectable options 1310 and 1312 are described later herein. The hyperlink menu 1314 may be displayed on the surface of the inbox UI 1300; for example, next to the position on the UI 1300 at which the user selection is made.

In the example of Figure 13, content 1316 has been selected, and a corresponding hyperlink menu 1314 is displayed, which comprises a first selectable option 1312, labelled “link 1”. The first selectable option 1312 may be associated with a hyperlink to an intranet or internet page, to which the host system navigates upon selection of the first selectable feature 1312. Consider that the selected content 1316 includes an identification number. In some examples, the system may navigate to an intranet or internet page which includes a search region. In such an example, the system may automatically paste the ID number in the selected content 1316 into the search region and automatically retrieve data associated with that ID number.

The hyperlink menu 1314 may be customisable. Figure 14c shows an exemplary hyperlink creation interface 1418, wherein a user may define a hyperlink name in a name region 1420, and define a corresponding URL or internal link in a link region 1422. The exemplary hyperlink 1418 of Figure 14c further includes selectable options 1424 and 1426, which may be selected to respectively confirm or cancel the creation of a new link. Though not shown in Figure 13, it will be appreciated that a selectable UI feature such as features 1302-1308 may be provided on the inbox UI 1300, via which the user may access the hyperlink creation interface 1418.

A shared folder feature may also be provided. The shared folder feature may work in conjunction with the rules-based highlighter and advanced hyperlink features, and may assist in reducing the number of emails that need to be send and received by a user. The shared folder feature may provide a memory location accessible to multiple users via their respective inbox UIs 1300, to which emails may be stored.

As described above, the shared folder feature may work in conjunction with the advanced hyperlink functionality. The exemplary hyperlink menu 1316 of Figure 13 provides a second selectable option 1310, configured to create a new shared folder.

Upon selection of the second selectable option 1310 in the hyperlink menu 1314, a shared folder creation interface 1428, as shown in Figure 14d, may be displayed on the surface of the inbox UI 1300. The shared folder creation interface 1428 of Figure 14d includes an address input region 1430 in which a user may define one or more address who is to have permission to access the new shared folder. The folder creation interface 1428 of Figure 14d further includes a folder naming input region 1432, in which the user may define a folder name. Note that in some examples, the folder naming input region 1432 comprises a default name, which may correspond to the highlighted portion of content 1316 which has been selected by the user to access the hyperlink menu 1314. The exemplary shared folder creation interface 1428 of Figure 14d further includes selectable options 1434 and 1436, which may be selected to respectively confirm or cancel the creation of a new shared folder.

Upon creation of a new folder by selecting a corresponding option in the hyperlink menu 1314, the email 1320, in which the content 1316 has been selected, may be saved automatically to the new shared folder. The new shared folder and the email saved therein may then be accessible to all users who have permission to access to the new shared folder. In some examples, an email 1320 may be saved to an existing shared folder. That is, in examples where the selected content is already associated with a shared folder, the hyperlink menu 1314 may include a selectable option to add the email 1320 to that shared folder.

In some examples, the shared folder functionality may not be provided as part of the advanced hyperlink feature. Instead, shared folders may be manually created by a user, for example through a designated region or feature of the inbox user interface. In such examples, users may manually navigate to a shared folder creation interface 1428 to create a new shared folder.

Reference is now made to Figure 15, which shows a portion of an exemplary inbox UI 1500. The exemplary inbox UI portion 1500 of Figure 15 comprises a shared folder icon 1502, which may, when selected, allow the user to access data (such as emails) stored within a corresponding shared folder. In the example of Figure 15, the user may also edit the data stored in the shared folder associated with icon 1502, for example by adding an email. The user may select an email 1504, move a cursor 1506 while continuously selecting the email, such that the cursor 1506 hovers over the shared folder icon 1502, then release selection of the email 1504 to cause the email to be saved to the shared folder. That is, a particular email may be added to a shared folder by dragging and dropping the email over a corresponding shared folder icon 1502. Note that the email stored to the shared folder may remain in the list region of the inbox UI 1500, being copied into the shared folder rather than moved.

In a medical context, shared folders may be useful tools for reducing the number of emails sent between doctors and assistants. For example, rather than sending an email which may become lost in a high- volume list of other emails, important emails may be saved into an appropriately named and easily locatable shared folder.

An analytics module carries out email analytics as described below. The analytics module allows patents, trends and biases to be identified and spotted such that they can be reported before experiencing unexpected consequences. The analytics module enables a smart predictive time management process to be implemented with real-time update based on information received in the inbox. The amount of time needed by a clinician to resolve each email may be determined (by prediction or specific information), so that the overall time to deal with a particular state of emails in an inbox may be determined. The analytics module provides data driven time planning by indicating an amount of time required each day to spend in responding to emails. The analytics module may identify efficiencies to be achieved when analysing data across multiple inboxes such as within a firm where multiple employees are accepting client requests, or in a clinical team where different members may have different responsibilities.

Machine learning may further be utilised in the triaging module and the analytics module for certain purposes. Chat bots may be used to enable a first degree of conversation to be automatically carried out with the sender of email. In a clinical context, this would support the feature mentioned above where a patient may make an inquiry but with inadequate symptom information, for example for a clinician to respond to the inquiry. Using machine learning, a chat box could determine that further information concerning the symptoms is required and make a request automatically by sending a return email without forwarding the initial email onto the clinician. Once the patient has responded with additional symptom data, the email may then be forwarded to the clinician’s inbox.

Machine learning may also support the analytics module by enabling data to be analysed with the simple statement or question. It can rapidly iterate with additional questions by adding follow-up queries or statements. The semantic models automatically enrich data for more natural interactions.

Machine learning may also enable decisions to be made based on data available within the inbox. Emails may be clustered based on pattern recognition.

Emails marked by the display module are supplied to a user interface 60 of a user’s computer device to be shown in their inbox.

A user may engage with the emails in their inbox by clicking on them (or selecting them in some other way) to open them and read their content. The markings supplied by the display module assist the user in determining how to manage their inbox. For example, an email may be marked (by the triaging module, for example using the content module 16 (to indicate the urgency or severity of the email). The urgency may relate to the time within which a response is required, and the severity may relate to the content of the email and therefore the amount of time that the clinician may be expected to spend on it.

A performance module 70 monitors the performance of the user when engaging with his inbox. The performance module allows a user to understand how he is engaging with his inbox, and therefore how his engagement may be improved. Furthermore, it allows a manager of that person to assess how that person is behaving in relation to their inbox. This can support good inbox management practices, and aid in the mental health and wellbeing of the users of inboxes. The performance module uses datapoints to provide particular parameters. These parameters may feed into an overall performance score, by waiting of individual parameters.

The performance module may provide a dashboard which shows a number of features visually rendered to a user. These features may include the current time, the total time spent on the inbox by the user, the average email response time (which could be aggregated over different periods, for example, the present date, week to date, month to date etc.), a countdown times which is set when a user opens an email and clocks a recorded time when the user finishes that email (or all emails), the total time needed to resolve all emails. The total time needed to resolve all emails may be calculated by the performance module based on the datapoints when a user starts to engage with an email and finishes engaging with an email. The total time feature may be indicated visually for different categories. For example, a visual indication of the total time needed to resolve all emails with a high severity score may be indicated.

The dashboard may also show the total number of emails in the inbox, the number of emails which have been responded to in a given period (for example, today, week to date, month to date etc.), the number of high severity emails requiring attention, the number of medium severity emails requiring attention, the number of low severity emails requiring attention, the number of emails marked as junk and removed and the number of emails archived. Numbers of emails in different categories may also be reported.

The dashboard may display a visual analogue scale rating of a confidence level of a user’s ability to manage their volume of email consistently.

Figure 3 is a flow chart that demonstrates a process in which data pertaining to electronic communications received at a user’s email inbox and data pertaining to the user’s response to such electronic communications are aggregated over a monitoring period to determine a quantity of performance indicators and scores, the performance indicators and scores being indicative of a user’s style of interaction with their inbox.

The process of figure 3 begins upon receipt of an electronic communication, such as an email. A first set of data points pertaining to the received communication are then stored to a memory in step S2. The first set of data points may include but is not limited to: time of receipt, level of importance etc. The first set of data may further include data generated by the system that is based on the content of the electronic communication that has been received. Upon receipt of the electronic communication, for example an email, the system displays (S3) the email at a user interface, for example at an email inbox interface. After viewing a communication displayed at step S3, the user may then act on the email in a step S4. Such actions could include but are not limited to: sending a reply, deleting the email, moving the email to a new location, forwarding the email to another addressee, or flagging the email as being of a particular importance level.

A second set of data points pertaining to the user’s action may then be stored to the memory in a step S5. The second set of data points may include but is not limited to: type of action, time of action, time taken to act, or data pertaining to content of a reply. Further examples are discussed herein.

Following a user action at step S4, the system may continue in a standby mode S6, awaiting receipt of further electronic communications, whereupon the above described process will be repeated for each new electronic communication that is received.

Whilst in the standby mode S6, the system may await a signal indicating that the current monitoring period is complete. This is demonstrated by the loop created between processes S6 and S7, connected by lines 301 and 303. Receipt of further electronic communications within the current monitoring period may cause the above described process to repeat for that communication. When, in step S7, the system determines that the monitoring period is complete, a period-end analysis process begins, wherein steps S8, S9, S10 and Si l are taken. When the S7 condition is found to be true (Y), the system may create a new directory in the memory wherein data for the new monitoring period will be stored.

In step S8, the first and second data points respectively stored in steps S2 and S5 are retrieved from memory. Step S9 then aggregates the data points, allowing generation of performance indicators and user scores in step S10, which may subsequently be displayed to the user in a step 11, for example through an electronic communication such as a notification or email.

Scores generated for a user may be indicative of their efficiency in managing their inbox or may be indicative of the mental state or stress levels of that user. For example, a ‘wellbeing score’ may be assigned, which indicates the mental wellbeing of the user based on their inbox management style. Data collected over a plurality of monitoring periods may then be capable of showing trends in performance indicators or scores. With reference to figure 8, the tool 801 may implement a multiple-avatar system 807 accessible to each user inbox 817 via, for example, a network 821. The multiple-avatar system may be able to learn about a user’s inbox management style and preferences, and act as an effective proxy for the user in circumstances where, for example, they are unable to respond or are overloaded with high volumes of work. For example, a multiple-avatar system 807 may include a time estimate avatar 809, a predictive response avatar 811 and an autorouting avatar 813 to form a 3-avatar system.

Each avatar in the multiple-avatar system may have a quantity of modes in which it can operate. A first mode in the multiple-avatar system 807 may be a learning mode 815 which monitors a first user’s interaction with their inbox 825 and identifies patterns in their behaviour. For example, the learning mode 815 may recognise patterns in the subjects of emails which tend to take a more significant time to resolve. The learning mode 815 may further be capable of recognising at which times and on which days the user is most focussed and is most efficient in handling emails. By way of example, a time estimate avatar 809 may be able to use this data in conjunction with data from subsequent modes to effectively schedule time for responding to emails.

The learning mode 815 of the time estimate avatar 809 may also be configured to guide the user’s interaction with the inbox user interface 825, such as by asking the user to predict how much time they think they will need to resolve an email. The learning mode 815 may be able to, for example, recognise situations in which the user can or cannot accurately estimate the time they will need to resolve an email to improve the speed of learning and more quickly begin to improve the user’s interaction with their inbox 825. The learning mode 815 may also be configured to ask the user how long they anticipate a recipient of an email they are sending will spend resolving the email. Based on the accuracy of the estimate, the time estimate avatar 809 may be able to communicate with the recipient user’s avatar system 427 to suggest an allocation of time for resolving the email.

A second mode in the avatar system may be a correlation mode 817, which may attempt to predict a user’s behaviour in a particular situation, based on the analysis performed in the learning mode 815. The correlation mode 817 may then compare its predicted outcome to the actual outcome of the user in order to refine its predictive ability and improve its understanding of the user’s behavioural patterns and inbox management preferences. Consider, for example, the flow chart in figure 9. Figure 9 depicts a flow chart which demonstrates the avatar system’s analysis of an incoming email and subsequent action taken by a user; note that the process of figure 9 incorporates at least the learning and correlation modes of at least the time estimate avatar 809. Upon receipt of an email at a step S91, the time estimate avatar 809 analyses the content of the email and predicts how long the user will take to resolve the subject of the email in a step S92. The avatar 809 in a learning mode 815 may then, in a step S93, ask the user to provide a user estimate of how long the same email will take them to resolve. Upon receipt of a user input at a step S94, the avatar may monitor aspects of the action taken by the user to resolve the email; this monitoring process, step S95, may include monitoring the time the user takes when resolving the email. When the user resolves the email, the time estimate avatar 809 may store in a memory 803 the estimate it generated in step S92 and the estimate provided by the user in step S94; this process is represented by step S96. Following storage of the estimate data, the time estimate avatar 809 in a correlation mode 817 may compare and perform analysis on the data in a step S97, the avatar 809 to better understand the user. Following the process represented by the flow chart in figure 9, the time estimate avatar 809 may be able to improve its accuracy in guessing how long a user will take to resolve a particular email and, when the avatar is mature enough to be in its advanced mode 819, the avatar 809 will be able to confidently inform the user how long each email in their inbox will take to resolve.

The following description relates to the functions of different trained avatars. A third mode in the avatar system 807 may be an advanced mode 819 which can, based on factors such as past analysis of a user’s interaction with their inbox 825, difficulty of emails, current workload and capacity to receive further work etc., accurately predict a user’s reaction to incoming emails. Based on the predicted response, a predictive response avatar 811 in the advanced mode 819 may be able to effectively act on behalf of the user, such as by offering to send an automatic reply in the written style of the user. In another example, a time estimate avatar 809 in the advanced mode 819 may be able to schedule time that a user should dedicate to their emails, based on their other commitments in the day and their historical patterns in inbox management efficiency throughout a day. In this case, the advanced time estimate avatar 809 may recognise that the user most effectively manages their inbox on a Monday morning. When the user arrives on the Monday, the time estimate avatar 809 may estimate how long the user’s current set of unresolved emails will take to resolve and suggest or automatically schedule a period of dedicated inbox management time, in which the user has no other commitments. In addition to recognising times at which a user’s performance peaks, an advanced predictive avatar system, which understands the user’s preferences and behaviours, may be capable of recognising which periods in which days are the most suitable times for the user to perform their inbox management duties. The avatar system may recognise these most suitable periods based on its understanding of the user, as well as based on a work timetable or rota of the user.

By way of example, consider a user who has a free period, on duty, with no urgent commitments between 2pm and 4pm. The avatar system may estimate the time it thinks the user will need to complete their inbox management tasks, and may assess whether the user has time to complete them in the 2-4pm period. If the avatar system considers the free period to be sufficiently long for the user to complete their inbox management tasks, the system may notify the user of its prediction and may offer to or automatically schedule the 2-4pm period as a dedicated time for administrative duties.

If the avatar system does not predict that the user can finish their inbox management tasks within the free period and during working hours, further features may be offered or automatically implemented. For example, the avatar system may notify the user that there is not enough time in their free period for them to resolve all administrative tasks and may offer to or automatically implement functionalities that may reduce the inbox management workload such that it is achievable in the free period. To this effect, the avatar system may utilise the auto-routing, flagging or triaging functionalities such that the user can schedule sufficient time to complete their administrative duties.

In some cases, the avatar system may recognise that there will not be a suitable period of time in which a user can perform their inbox management duties. In such a case, the avatar system may implement one or more features capable of easing the administrative pressure on that user. By way of example, the avatar system may implement an auto-routing feature such that a difficult email, which needs a considered response, may be sent to another user who is capable of resolving it and who has lower administrative pressure or more free time in which they can resolve the email. The automated distribution of administrative tasks in this way may, on average, reduce the number of emails in the inbox of the users in a workplace, both during and outside working hours, thereby reducing the stress of inbox management and improving the wellbeing of staff in the workplace and outside when off duty.

To help users to practise healthier inbox management, the avatar may recognise when a user is regularly using work email outside of working hours and provide a feature on the surface of the inbox UI which provides a single-click option for the user to delay sending emails until working hours. The avatar may also provide recommendations of strategies for reducing email volume.

The avatar may also provide a feature whereby a first user may designate one or more trigger word and/or phrase and nominate one or more alternate user, to whom all emails containing the one or more trigger word and/or phrase are redirected. The avatar may provide this feature when the first user is about to become unavailable to answer emails, for example by clocking out, going on leave, attending a meeting etc. It will be appreciated that the avatar may further receive input, by the first user, of a time period in which to implement the above-described nominated auto-routing. In other examples, the avatar may recognise from the first user’s schedule that they are about to become unavailable, and may suggest that the user provide the one or more triggers and one or more nominated alternate users required to implement the above feature.

Referring again to Figure 13, the exemplary inbox UI 1300 includes a recipient nomination feature 1302 which, when selected, causes a recipient nomination interface to be displayed on the surface of the inbox UI 1300. An exemplary recipient nomination interface 1438 is shown in Figure 14e.

The recipient nomination interface 1438 of Figure 14e includes an address input region 1440 configured to receive user input of one or more recipient email address, a trigger definition region 1442 configured to receive user input of a trigger word or phrase, and a time period definition region 1444, configured to receive user input of a time period in which to implement the recipient nomination feature described above. Note that in some examples, a default time period may be entered to time period definition region 1444, the default time period being defined based on a leave schedule of the associated user. The exemplary recipient nomination interface 1438 of Figure 14e further includes selectable options 1446 and 1448, which may be selected to respectively confirm or cancel the nomination of a recipient during a period of unavailability.

The multiple-avatar system 807 may be capable of implementing any number of other features described herein in order to improve a user’s level of interaction with their inbox 825. For example, based on the avatar system’s 807 recognition of a scheduled period of patient-facing work, the avatar system 807 may implement an ‘unable to respond’ feature 823, whereby each incoming email during that period is automatically re-routed to another capable user who is best suited to handling that email.

In some embodiments, the multiple-avatar system 807 described above may utilise NLP or Al techniques to learn, correlate and subsequently improve a user’s inbox management style.

In some embodiments, the multiple-avatar system 807 may be a rules-based system which determines an appropriate response to a particular situation by acting in accordance with a plurality of pre-defined rules.

In some embodiments, there may also be one or more higher order avatar system 805 that oversees and monitors the performance of the personal avatar systems. For example, the overseer avatar system 805 may identify areas in which the personal avatar systems tend to learn less quickly, and may act to improve these areas.

Based on a quantity of factors such as number of unread emails, wellness score and perceived stress levels, the tool 801 may be capable of, through its auto-routing avatar 813, automatically re-routing emails to a different user who may be more capable of dealing with the email at that time. By distributing emails based on present workload, the wellbeing and mental state of users may be improved and more consistent across the workplace. In such a case, the system may comprise a memory 803 which is configured to receive regular or real-time updates of the wellbeing scores of users in the workplace. Upon receipt of an email, the system may, based at least upon a plurality of the most recent wellbeing scores stored in the memory 803 for users in the workplace, determine that a second user is, based on factors such as style of interaction with their inbox, current number of emails and capacity to receive further work, determined by the system to be, at the time of receipt, more capable than the first recipient of dealing with the email. The system may then re-route the email such that the second user, who is at that time more capable of handling the email, receives the email instead of the first user.

Since the capacity of users to receive further work may be determined based on factors including the content of the email to be re-routed, and the inbox management style of the user, automatic re-routing of emails may allow work to be distributed among users such that each user receives work that is well-suited to their strengths.

Emails may be received which are part of a conversation which includes a quantity of users. A user’s avatar system may be capable of recognising which conversations have been initiated by the first user, and may be capable of offering to the user an option to receive no further emails pertaining to a particular conversation. For example, using data collected and produced by the learning and correlation modes of the avatar, an avatar in its advanced predictive mode may be capable of recognising that a particular conversation has finished, or that the user is no longer an important recipient of the emails in the conversation. As a result, the avatar system may implement an automated rerouting or removal of past and future emails in that conversation such that the inbox of the user does not contain high volumes of unnecessary email communications. This process may further reduce the time a user must spend filtering through emails to determine which emails require an urgent or considered response.

At present, email inboxes often include an ‘out of office’ feature, the activation of which causes automatic replies to be sent, notifying the sender that the intended recipient is not currently able to resolve the email. There are a number of issues with this feature, several of which are identified herein. Firstly, the ‘out of office’ feature does not stop emails from reaching a user’s inbox 825. Also, in cases where an out-of-office user is the sole addressee of an email, that user will remain the sole recipient unless the sender has redirected the email themselves, for example in response to an automatic reply indicating the recipient’s out-of-office status. On their return, the out-of-office user may have a large quantity of emails in their inbox 825, with no indication of which emails have been resolved in their absence.

With particular reference to a clinical working environment, there are certain circumstances, such as patient-facing time, in which an employee is in the office but is unable to respond to their emails. There is currently no provision for such intra-day absence circumstances, neither for senders of emails to be aware of the situation, nor for recipients to indicate their inability to respond.

The tool 801 described herein includes a feature that can be used to indicate a user’s inability to respond to emails. The feature 823 may be configurable to allow periods of time within a day wherein inbox management can’t be done, such as patient-facing hours, and therefore incoming emails must be negligible. During such periods, other features of the tool may be employed, such as automated re-routing of emails to other capable employees. In some cases, this feature may be implemented manually by a user. In other cases, the system may be capable of understanding a user’s work rota, recognising periods where the user won’t be available, and automatically implementing the feature 823 during these periods.

Implementation of this feature 823 allows employees who are not capable of responding to emails to focus on their other commitments in the knowledge that new work from their emails will be negligible during that period. Further, senders of emails may receive a prompter response if their email is redirected to an alternative suitable recipient.

The tool may also provide a dashboard configured to display performance data for a user. For example, data pertaining to, amongst other things, a user’s efficiency or wellbeing score may be displayed. The data displayed on the dashboard may be used, for example, as an appraisal tool to indicate to a user the areas in which they perform well, the areas in which they can improve, and how the user might make those improvements.

The appraisal feature may have further functionalities. The appraisal feature of the dashboard may be capable of indicating to a user the quality of the state of their inbox and suggesting or automating a solution to any identified problems. By way of example, at the end of a monitoring period, the appraisal tool may provide a statistical summary which indicates to a user how often an email was received but warranted or received no reply. The tool may further be capable of recognising that the user is included in a particular conversation but is not an important recipient, has not replied consistently, or that the conversation has ended. The appraisal tool may estimate how much time could be saved if such emails were not received, and may offer to automate one or more features described herein, which may act to reduce wasted inbox management time through the next monitoring period.

The appraisal tool may, for a given period of monitoring, be capable of providing to a user an estimate of how much time the tool has saved during the given period. The appraisal tool may base its estimate, for example, on the, the number and difficulty of emails received, the quantity and type of features that were implemented and the automated or suggested actions of the tool during the given period of monitoring.

The data displayed on the dashboard feature may be provided to a system capable of screening users for diagnosing communications-related stress in email users. That is, for a particular user subject, performance data recorded and aggregated over a monitoring period may be analysed by the diagnosis screening system to determine whether the subject user is exhibiting signs of email-related stress, such as erratic or inconsistent response rates, or long amounts of time spent using email out-of-hours. Note that the diagnosis screening system may be capable of recognising stress levels in the subject user by analysing data indicative of the user’s email response actions. The diagnosis screening system may, upon determining that a subject user is at risk or is currently displaying indications of communication-related stress, provide information to the subject user through the inbox UI, notifying them of the risk to their wellbeing and proposing non-clinical strategies to improve email interaction, such as identifying email volume reduction strategies.

Emails may be sent to multiple email addresses, either by directly addressing multiple recipients, or by copying, or ‘cc-ing,’ other recipients. Generally, addressees who have been copied into the conversation have been so because they are less responsible for or less involved in the subject of the email than those who have been directly addressed. Even so, an email may be sent with several of direct addressees, but where only a subset thereof is heavily involved in the email subject. As a result, users may receive a high volume of emails for which they do not need to respond. Since it is not immediately clear whether a user has been directly addressed or copied into the conversation, filtering out emails which are irrelevant can be a timeconsuming and unnecessary task.

The present tool may be capable of automating a process of filtering emails which do not require the attention of the recipient. For example, the tool may recognise that a first user has been copied into the email conversation or, based for example on the content of the email, determine that the first user was not a necessary recipient of the email. Alternatively, in the case that the first user is a direct recipient of an email, the tool may recognise that there is a plurality of other direct addressees, and that the first user was, for example, the sixth person to be addressed directly. In such circumstances, the tool may determine that the email does not need the attention of the first user, and may perform an automated process to resolve the email or remove the recipient from the email conversation.

Email user interfaces often offer a functionality whereby one or more users may be added to an email group. In cases where a group may include a high quantity of employees, it is beneficial to a sender of an email to address the group rather than type the individual email addresses of all those comprised within the group. However, email user interfaces often provide no option for a user to remove themselves from an email group. If, for example, a particular user has changed team or position in the workplace, they may not need to receive emails that were circulated to their former group. However, since there is currently no way for a user to opt out of an email group, they may continue to receive unnecessary emails until they are removed manually by someone with the ability to do so. Remaining in email groups that are irrelevant may cause the user to spend more time filtering emails that are important or unimportant, relevant or irrelevant. The tool may also include a feature that is capable of automatically removing a user from email groups, for example by recognising that the user rarely responds to emails circulated in that group and, as a result, offering an option of exiting the group to the user. Alternatively, the system may implement a selectable feature on the inbox user interface, which may provide a manually activated option to leave a group.

Alternatively, if, for example, the avatar system recognises that the user has a high volume of inbox management tasks to complete but is still an important and relevant recipient of the emails to a particular conversation or group, the avatar system may offer to or automatically notify the other members of the conversation that the user will not be able to respond in the immediate future, but would like to remain party to the emails addressed to the particular conversation or group.

The tool may also implement an acknowledgement feature in the inbox user interface. This functionality may reduce the quantity of unnecessary acknowledgement emails that users send and receive, by implementing a non-email response feature for acknowledging and reacting to an email. Upon selection and subsequent opening of an email by a first user, the acknowledgement feature may be implemented as a selectable feature within their inbox user interface. The first user may deem that the selected email needs no considered response, but the first user may want to acknowledge their receipt of the email, such that the sender, a second user, knows that it has been received. The acknowledgement feature, when selected, may offer a quantity of acknowledgement types, such as: “thanks,” “sure,” “I’m on it,” etc., from which a user may select an appropriate option; such options may be displayed, for example, in a dropdown or pop-up menu.

Upon selection of a particular acknowledgement type from the quantity thereof, the second user may receive a prompt on their inbox user interface, such as a pop-up notification or other visual indicator, which provides the acknowledgement from the first user.

In some embodiments, there may be a feature whereby acknowledgement types may be customisable or created by a user.

The acknowledgement type may be a textual response, but could be or include one or more graphical or emotive characters, such as a “smiley face” or “thumbs up” character or real time or recorded verbal inputs such as ‘thank you - stepping out of this thread’. The aspects of the invention described herein particularly address challenges that have been exacerbated by the global pandemic of Covid 19. COVID-19 has reduced ‘face to face’ working with patients, relatives and between staff in the NHS, creating greater reliance on non- ‘face to face’ or digital communication (DC) for its 1.3 million employees.

The volume of DC that NHS healthcare staff deal with and the impact of this on their worklife balance have not been previously determined both before and during COVID-19

Outside the NHS, DC leads to expectation of availability outside of normal working hours and a negative impact on employees, impaired recovery, cortisol changes and low mood.

Amongst other benefits, the presently described techniques and systems inform the development of the largest UK employer (the NHS) to support staff into new patterns of working reducing the risks of additional stress and burnout. They are equally applicable to other sectors where dependence on DC is increasing.

To inform the present techniques, the following research protocol was adopted. Consenting healthcare staff with an NHS email address were invited to complete an HRA-approved, online, multi-centre survey of a potential of 108 items amidst the COVID- 19 pandemic following the first peak in April 2020.

The survey asked which platforms staff used to communicate, how often, and how things had changed between the present during the COVID-19 pandemic compared retrospectively to the last 3 months of 2019.

Additionally, staff were asked about whether DC was manageable, whether it slowed down their main work, caused time intrusions outside work, whether they could ‘switch off’ and there was a need for an NHS framework to manage DC.

Results

Survey response: 3611 surveys were opened using Qualtrics and JISC survey platforms. 3047 staff (85% female) provided consent and evaluable data - over 30 days (average rate 102 per day), between 21 ^st May and 19 ^th June 2020.

Communications platforms: Emails were the most frequently used DC tool, followed by the phone, the internet, WhatsApp, Microsoft Teams, paper, Zoom, and then bleeps and other apps such as Hospify and Pando. Communications volume: Staff reported a somewhat (27%) or a marked (43%) increase in DC. Using emails as one marker of volumes, prior to COVID- 19 staff estimated they received a mean of 14 emails on an average working day, increasing during COVID- 19 to 17 emails. The mean email volume rose further to 29 emails on a busy day amidst the pandemic. Extrapolating nationally, for the approximate 1.2 million accounts with NHSMail, allowing for 1 in 5 staff working part-time, we estimated 329.8 million emails per month before COVID- 19 compared to the reported number by NHSMail of 323.1 million emails in November 2019.

DC was ‘manageable during work’ had 17.8% disagreement before COVID-19 increasing to 31.1% during the pandemic, with 51.1% and 63.6% of staff agreeing DC ‘slowed down their main work’ respectively.

Impact off duty: DC took up family and home time outside work for 48% of staff during COVID-19, compared to 23% before, with 57% of staff reporting that they could not ‘switch off’ communications during COVID- 19 when they wanted to, compared to 36% before COVID- 19.

Call for Framework: 4 out of 5 (82%) staff agreed that the NHS and other healthcare employers need guidance on actively managing the volume of work communication to improve staff wellbeing, with only 3% disagreeing.

Based on the research, the following conclusions were reached.

DC is an increasing means of working in the NHS accelerated by COVID-19: provided herein is the first data regarding types and volumes.

The pandemic has caused an increase in DC volume and a large proportion of staff reported they cannot ‘switch off’ outside work.

An NHS framework is urgently needed before this issue escalates further. we expect the solutions offered herein to reduce DC volume and off duty infringement I, thereby acting to improve staff emotional wellbeing, work-life balance, staff productivity, resilience, job satisfaction and retention.

Working example of solutions for NHS England

Effective communication is one of the key domains of good clinical practice for doctors, nurses, and all health professionals in the NHS. The majority of staff in the NHS work in multidisciplinary or multi-agency teams, communicating with their direct team, with other professionals involved in providing care, with patients and their relatives and advocates. Ineffective communication is associated with low staff morale, poor patient experience, adverse patient outcomes and increases staff stress and burnout rates.

On 30 ^Lll January 2020, the World Health Organisation declared a public health emergency of international concern in relation to the COVID-19 outbreak in China. The NHS declared an internal, level 4 serious incident, and commenced preparations and on 17 ^Lll March all NHS Trusts were asked by the NHS Chief Executive and Chief Operating Officer to take immediate measures to reduce the spread and prepare for an imminent surge of COVID-19 patients resulting in an unprecedented shift in all aspects of healthcare services to maximise efforts to manage COVID-19 patients.

For many healthcare staff, this meant an overhaul of work patterns and redeployment to emergency rotas in areas of urgent need. Other healthcare workers returned to frontline clinical duties from academia, research or retirement. Conversely, some staff became unavailable for frontline clinical duties as they were unwell, shielding or self-isolating. Remote working increased, minimising face-to-face contact with patients, relatives and other staff. These shifts in working patterns were recognised from the outset of the pandemic as an urgent public health issue, and a number of research studies began to investigate the psychological impact on health workers (Refs) with regard to staff stress and burnout rates, already increasing issues prior to the pandemic.

Communication between healthcare staff plays a pivotal role during emergencies, particularly the use of digital technologies such as instant messaging using technologies such as WhatsApp, which increase during emergencies requiring coordinated staff responses. Surprisingly, there are no published systematic or objective evidence collection within the NHS on non- ‘face to face’ communication methods, volumes and the impact of these, on staff wellbeing and worklife balance.

Our research tackles these gaps, collecting both subjective and objective data on digital communications (DC) during and prior to COVID- 19 for descriptive comparison. These data inform a strategy to protect mental wellbeing of staff as we navigate COVID-19 and adapt to new ways of working, involving considerably more non- ‘face to face’ communication. Digital communication represents non- ‘face to face’ communications between any health care staff or between staff and healthcare users (patients, relatives and non-NHS professionals; example - equipment providers) for any health care purpose. Outline

The ‘Communications and COVID-19’ study was designed as a multi-centre, online questionnaire to widely survey staff relating to digital communication, its relationship to work- life balance and the impact on these of the COVID- 19 pandemic. Adult healthcare workers with an NHS email address were eligible to participate in the study. The survey was composed of a maximum of 108 stems in 5 sections requiring a response. Five-point Likert scales (Strongly Disagree to Strongly Agree) were used where possible and descriptive results are presented. Formal statistics have been avoided, as this was a non-interventional survey without formal data monitoring to confirm subjective answers.

Study design

Section 1 of the study asked respondents to provide their gender, age group, work role, working pattern, their healthcare employer type and whether they were redeployed or not. Specific questions regarding the volume of direct contact with patients suspected of COVID-19 were included.

Section 2 asked respondents to select communication platforms used during the COVID-19 pandemic and the frequency of their use. A specific question regarding use and understanding of Microsoft Teams was included as this communication platform was made newly available to all NHS email users between the 6 ^th to the 20 ^th March 2020 to facilitate remote working.

Section 3 examined the volume and time spent on DC at work and off-duty, during COVID-19 and compared to ‘before COVID- 19’ considering the period October to December of 2019.

Section 4 asked respondents about their ability to manage DC, any disruption DC may cause with work, travel, home life or leisure time, and the ability to disconnect when needed, during and before COVID- 19.

Finally, Section 5 examined respondents’ views on whether they felt guidance or a policy on managing work related communication would be useful.

Study development and delivery

The survey was conducted using two online platforms: the QualtricsXM survey platform providing advanced design and analytics features and a second platform JISC Research Surveys as a back-up alternative. As part of the testing and validation, the survey on both sites were piloted with the help of a small number of clinicians prior to the launch. The study received approval by the Health Research Authority (20/HRA/2445) extremely promptly prior to approaching study participants. The HRA also confirmed that participating NHS organisations were not required to formally confirm Capacity and Capability to undertake the research. NHS organisations included in the National Directory maintained by the NHS Research & Development Forum, were invited to take part in the study. Links to the survey on both platforms were made available on the NHS Research & Development Forum website. An invite was also sent to the member organisations of the UK Research and Development leaders’ forum to pass on to their members to support adoption of the research. A provisional target of 400 survey respondents with a stretch target of 800 was considered sufficient to provide initial insights.

Informed consent and data processing

Participants were informed that all data collected would be maintained in line with the Data Protection Act 2018, and used to provide medical insight and an evidence base to shape and improve standards, solutions, and support to manage clinical communications issues. Informed consent to take part in the survey, and to analyse and publish the data collected as part of the survey, was confirmed online to be able to proceed with the survey.

Analysis and results

General Survey Results (Figure 4.)

3611 respondents initiated the study, with 3047 staff having an NHS email address providing consent and evaluable survey data. The survey opened on 21 ^st May 2020 and closed on 19 ^th June 2020 having overwhelmed the target of 800 responses within the first two weeks. After 30 days, having collected data from community trusts and secondary care trusts, from mental health workers as well as ambulance crews, the survey data were felt to be generalizable across roles and across England and Wales, thus was closed, having averaged 102 responses per day peaking at 368 responses on 10 ^th June 2020, and been at its lowest on the first day of 7 local respondents from the Royal Free. Responses were lower at the weekends and highest on Wednesdays as shown in Figure 4.

Missing Data

Data were missing in sections of the survey, but of 3047 responses, only 109 had more than 40 response points empty of the 108 data points possible and none had more than 79 points empty. Response rates to all survey questions exceeded 2500 respondents, usually approaching 3000 responses, and a quarter of staff took 19 minutes to respond during the COVID-19 period. A section on WhatsApp was introduced on 28 ^th May, a week after the launch and was thus unavailable to earlier respondents.

Section 1 Baseline Survey data (Table 1.)

In our results, the large majority of respondents were women (85%), with the highest concentration in the age categories 51-60 years (29%) followed by the 41-50 age category (27%), with about a quarter of respondents working remotely and about one in ten staff having been redeployed. Almost half of all staff were working full-time working hours or shifts as usual.

Interestingly in the NHS staff survey results of 2019, in acute and community trusts, 77% of 251 thousand respondents were also women and the 41-50 age category were represented by 26% and the 51-65 age range at 32% which are relatively similar to our respondents.

Temporal Consistency Check

The baseline survey demographics results were re-examined in tertiles over time, with percentages rounded to the nearest complete day closest to 33.3% (Day 1-12), 66.6% (Day 13- 20) and the final tertile (Day 21-30). Demographics were very similar across the three tertile periods, but as time progressed there were small increases in staff working part-time (18.7% to 21.4%), working remotely (21.5% to 27.3%), working in their usual post (19.2% to 25.9%) and their frequency of physical exposure to patients with COVID- 19. The remote working response was available in several stem questions and was chosen between 15.3% and 22.9% across various sections as a check of internal survey validation.

The work location responses showed representation from acute hospitals, community trusts, mental health trusts, and, via the ‘other’ section even ambulance trusts. Academic locations were likely to overlap with tertiary care units, hence low numbers; GP practice trusts came on board with permissions later during the survey. The work location proportions represented the speed with which organisations both approved this form of research and shared the survey link via internal communications methods to their staff, with some trusts using an internal internet advert, whilst others would include the invitation in the weekly or more frequent chief executive update to all staff. The survey was available via both mobile and desktop platforms and aesthetically enhanced by using graphics in the main invitation, and this appealed to many responders, with 79% agreeing to complete a bonus final section ranking types of communication, and 333 responders providing a commentary in the free-text final question with many staff attesting to stress or the volume of calls from patients and relatives wanting information about their family member admitted to their hospital.

Note, we deliberately avoided asking employers’ name, but the location of their IP address (Figure 1) showed that responders were distributed widely throughout England.

Section 2 Communication Types and Frequency (Figure 5.)

Through a review of literature, social media, and by asking many staff, we determined a large range of digital communication platforms that staff used in their day-to-day duties, from email to Microsoft Teams, from NHS library approved apps like Hospify and Pando, to WhatsApp and Twitter. Despite many instances of governance and data-handling training dissuading staff from using WhatsApp and other non-secure technologies prior to COVID- 19, it was clear that NHS staff were utilising the ubiquitous WhatsApp platform, making it the third most frequently used platform, combining constant and hourly use behind only emails - the clear lead, followed by the phone.

NHS approved clinical messaging technologies like Hospify and Pando were not frequently used, but did show some uptake, even in this relatively small sample of the entire NHS workforce. Figure 5 shows the types of communications platforms in use and the frequency of use, asked at the peak of COVID- 19. The electronic health care record (ehrec) of patients was surprisingly low in our opinion, behind Teams and Zoom as platforms. Compared to the phone, bleeps are clearly considerably diminishing but text messaging remains in high use.

Section 3 Communication Volume and the Impact of COVID- 19 (Figure 6.)

This section of results relies on subjective assessments from respondents as to volume of digital communication. Given the need to have some form of numerical assessment, we chose to ask information about the number of emails and WhatsApp messages - platforms which show users how many unopened messages are present to be read. Additionally, other than calls, these were the most frequent communication types. The data relating to these two typed platforms are shown in Figure 6. We surveyed responders on volumes on three different types of days, to be imagined by participants; a quiet day, an average day and a busy day, each shown before and during COVID-19. There are clear rightward shifts across these days, with staff choosing a higher category of email and WhatsApp ranges with each type of day, and ‘During’ COVID- 19 compared to ‘Before COVID- 19’ (considering the last 3 months of 2019). Despite the increased DC due to COVID-19, there is a larger DC volume variation between a quieter and a busy day.

The majority of staff reported a somewhat (27%) or a marked (43%) increase in work DC due to COVID-19. For example, on an average working day, staff estimated they received 14 emails per day before COVID- 19. During the COVID- 19 pandemic, staff estimated getting an average of 17 emails on an average day and 29 emails on a busy day, suggesting DC had generally increased due to COVID-19, although 18% reported reduced volumes (Table 1). The majority proportion of 70% reporting an increase in DC, was similar in both the first and last tertile subgroups and reduced only slightly to 68% in the middle tertile, again providing some temporal consistency on the results of this survey.

National Extrapolation of Email Volume

We calculated that if we used the lower range value limit for each category of email responses, with the exception of the ‘1-10’ category being given a value of 5, for an average day, prior to COVID-19, with the proportion of staff in each category scaled up by 1,221,204 inboxes, allowing for 20% of staff working as part time at 33% of a full time worker’s duration and assuming 20 working days in a month (absorbing 25 working days annual leave a year), then the estimate of monthly email volume would be 329.8 million emails per month. Freedom of Information request to NHSmail provided the volume of emails in November 2019 of 323.1 million emails. This suggests only a 2% overestimate from our ‘bottom up’ approach from 2844 staff, probably due to a small positive reporting bias of our respondents, given that they do tend to reply to emails, including this invitation to a survey. We were surprised by how closely our estimate matched the actual monthly email count.

Section 4 Communications, Work Life Balance and Need for National Guidance (Table 2. Figure 7.)

We asked basic questions regarding work communications being manageable and the ability to switch off as wanted. This was an attempt to keep the survey both efficient on a mobile phone and with stems still easy to understand and follow. This is probably why over 2766 respondents provided data for each of these questions even near to the end of the survey (median completion time of almost 13 minutes). Staff responded that before COVID- 19, 76% could manage work-related communication at work, with 18% struggling. During COVID-19 these figures changed to 61% and 31% respectively. A majority of staff (57%) could not switch off during the pandemic, compared to 36% prior to this. A high proportion reported work communication subjectively slowed down their main work during both periods - 51% before and 64% during COVID-19. The main impact, however, was outside work, with family and home time being taken up with work- related communications for 48% of staff during COVID- 19, compared to 23% before. Of the 14% strongly reporting intrusion of home life, 49% reported emails volumes ranging from 51 to >250 emails on a busy day, compared to 15% not reporting any intrusion of home life. Additional disruption of leisure time is shown in Table 2 and, surprisingly, travel time was not disrupted - perhaps due to the lockdown making travel easier for some staff, as road traffic was markedly reduced and restricted only to key workers.

Section 5 Policy issues

An overwhelming 82% of staff agreed that the NHS and other healthcare employers need guidance on actively managing the volume of work communication to improve staff wellbeing, with only 3% disagreeing and 14% unsure (Figure 4). Surprisingly staff with both high and low email volumes on an average day before COVID-19, agreed to this need for an NHS DC framework.

The disclosure above provides the details necessary to implement the following examples.

A first example provides a computer system configured to receive and handle electronic communications, the computer system comprising: a plurality of computer devices each comprising a user interface associated with a named addressee user and having a display configured to display a plurality of electronic communications to the named addressee user, each electronic communication being selectable by the user via input means of the user interface to cause the electronic communication to present content of the electronic communication to the user, and computer memory configured to store electronic communications to be displayed on the display; and an electronic communications triaging module configured to determine at least one of content of an electronic communication and or more addressee of an electronic communication and to select a recipient of the electronic communication based on at least one of the content and/or addressee, wherein the electronic communications triaging module is configured to select an action based on the content and/or addressee wherein the action has the effect of preventing the incoming electronic communication from being displayed at the user interface of the computer device of at least one addressee of the incoming electronic communication.

In some embodiments, the electronic communication triaging module comprises a set of clinician recipients and selects one or more of the clinician recipients to receive the electronic communication based on the content and/or addressee.

In some embodiments, the content defines a clinical task.

In some embodiments, the triaging module may comprise a tracking component configured to determine whether the selected recipient of the electronic communication has actioned the content of the electronic communication.

In some embodiments, the triaging module comprises a routing component configured to receive incoming electronic communications and to detect a set of named addressees in at least some of the electronic communications. In such an embodiment, the routing component may be further configured to determine a sub-set of the set of named addressees as a group of responsible named addressees and to transmit the electronic communication only to a subset of the computer devices associated with the responsible named addressees and to prevent the incoming electronic communication from being displayed at the computer devices of the remaining named addressees of the set.

In some embodiments, the computer system comprises computer storage which stores each set of named addressees in association with a group identifier of the set.

In some embodiments, the group identifier identifies a group comprising members of a clinical team or clinicians having a common clinical skill, role or responsibility.

In some embodiments, the routing component is configured to determine one or more named addressee in at least some of the electronic communications, and to determine an alternate addressee based on the content of the electronic communication. The routing component may be configured to transmit the electronic communication to the alternate named addressee and to prevent the electronic communication from being displayed at the computer device of the named addressee.

In some embodiments, the action selected by the triaging module is to determine a sender of the electronic communication and to generate an auto response based on the determined content of the electronic communication. The triaging module may be configured to effect the action by transmitting the auto generated response to the electronic communication sender.

In some embodiments, the triaging module is configured to determine the content of an electronic communication using language-based rules.

In some embodiments, the triaging module is configured to determine the content of the electronic communication using natural language processing by a machine learning model.

In some embodiments, the computer system comprises a schedule access module configured to access a work schedule of the named addressee user and to determine from the work schedule, the presence or absence of the named addressee user and to act on the electronic communication based on that determination.

In some embodiments, the triaging module is configured to determine if an intended recipient being one of the named addressees is indicated as available, and if so, to route the electronic communication to the inbox of that addressee user, and if not, to select an alternate recipient and to route the electronic communication to that alternate recipient. In some embodiments, the triaging module is configured to send a notification to the sender of the electronic communication indicating that the electronic communication has been routed to an alternate recipient.

In some embodiments, the computer system comprises computer storage which holds in association with each of a set of addressees the capacity of that addressee, and wherein the alternate recipient is selected based on the capacity.

In some embodiments, the triaging module is configured to operate when the intended addressee of the electronic communication has a non-handling setting set for their inbox.

In some embodiments, the capacity associated with each addressee takes into account a user response pattern of that addressee.

In some embodiments, the capacity of each addressee is based on a current quantity of emails in an inbox of the addressee.

In some embodiments, the current quantity of emails is indicative of at least one of the number of emails and the complexity of each email.

Another example provides a method of monitoring the handling of electronic communications presented to a recipient at a user interface of a computer device, the method comprising: recording in computer memory one or more first datapoint for each incoming electronic communication, each first datapoint in a performance category to be monitored; displaying at least some of the incoming emails at the user interface for action by the recipient; recording one or more second datapoint for each incoming communication which has been displayed to the recipient, the one or more second datapoints relating to an action taken by the recipient when accessing the electronic communication; and determining a performance monitoring period and aggregating the first datapoints and second datapoints over all electronic communications received and displayed to the recipient in that monitoring period to provide a performance indicator for that monitoring period.

In some embodiments, the first datapoint comprises the time of receipt of an incoming electronic communication. In some embodiments, the first datapoint comprises a severity score which has been assigned to the electronic communication based on an estimated time needed to address the email based on its content.

In some embodiments, the second datapoint comprises the time at which the recipient actions the incoming electronic communication and/or the action taken by the recipient.

In yet another example, there is provided a computer system for monitoring the handling of electronic communications for use as an aid in screening for a diagnosis of communication related stress or anxiety of a recipient of the electronic communications, the computer system comprising: computer memory; one or more computer processor configured to record in the computer memory one or more first datapoint for each incoming electronic communication, each first datapoint in a performance category to be monitored; a display configured to display at least some of the incoming emails at the user interface for action by the recipient; the one or more computer processor configured to record one or more second datapoint in the computer memory for each incoming communication which has been displayed to the recipient, the second datapoint (s) relating to an action taken by the recipient when accessing the electronic communication, and to determine a performance monitoring period and aggregate the first datapoints and second datapoints over all electronic communications received and displayed to the recipient in that monitoring period to provide a performance indicator for that monitoring period.

Yet another example provides a method of monitoring the performance of a software tool configured to manage electronic communications, the method comprising: providing a computer device having a user interface associated with the named addressee user and having a display configured to display a plurality of electronic communications to the named addressee user, each electronic communication being selectable by the user via input means of the user interface to cause the electronic communication to present content of the electronic communication to the user; installing a monitoring component of the software tool to access the computer device and to monitor the handling of the electronic communications by the named addressee user at the user interface of the computer device to determine a base set of metrics associated with the handling of electronic communications by the user at the user interface. installing a user interface component of the software tool to modify the user interface of the computer device; monitoring the handling of electronic communications by the named addressee user at the computer device to determine a new set of metrics associated with the handling of electronic communications by the user at the modified user interface; and comparing the base and new sets of metrics to determine the differences between the handling of electronic communications at the user interface compared to the modified user interface.

In some embodiments, the metrics comprise objective data based on technical data representing the technical state of the electronic communications selected from time spent on one or a number of communications and a total number of communications processed in a monitoring period.

According to another example, there is provided a computer system configured to receive and process electronic communications, the computer system comprising: a plurality of computer devices each comprising a user interface associated with the named addressee user and having a display configured to display a plurality of electronic communications to the named addressee user, each electronic communication being selectable by the user via input means of the user interface to cause the electronic communication to present content of the electronic communication to the user, and computer memory configured to store electronic communications to be displayed on the display; and an electronic communications triaging module configured to determine content of an electronic communication and to control the manner in which the content of the electronic communication is displayed to the user by selecting one or more portion of the content for highlighting in a displayed version of the electronic communication to the user. In some embodiments, the electronic communications triaging module is configured to highlight portions of the content of an electronic communication based on highlighting rules.

In some embodiments, each computer device is configured to detect that a user has selected a highlighted portion of the displayed content of the electronic communication and to cause the electronic communication to be stored in a file in the computer memory based on the highlighted portion.

In some embodiments, the electronic communications triaging module is configured to determine that the highlighted portion represents an identifier and to generate in the displayed content of the electronic communications a selectable icon for selection by a user to access one or more hyperlink associated with the identifier.

In some embodiments, each computer device is configured to display the plurality of electronic communications based on the highlighting of the content but without presenting the highlighted content to the user prior to selection of the electronic communication by the user.

According to yet another example, there is provided a computer system configured to receive and handle electronic communications, the computer system comprising: a plurality of computer devices each comprising a user interface associated with a named addressee user and having a display configured to display a plurality of electronic communications to the named addressee user, each electronic communication being selectable by the user via input means of the user interface to cause the electronic communication to present content of the electronic communication to the user, and computer memory configured to store electronic communications to be displayed on the display; and an electronic communications triaging module configured to determine at least one of content of an electronic communication and or more addressee of an electronic communication and to select a recipient of the electronic communication based on at least one of the content and/or addressee, the electronic communications triaging module comprising a tracking component configured to determine whether the selected recipient of the electronic communication has actioned the content of the electronic communication.