An algorithm to calculate personal busyness levels, and a means of communicating this information
Publication Date: 2010-Sep-06
The IP.com Prior Art Database
In today's office environment, it is common to collaborate with people from various different teams and backgrounds, with varying levels of availability. The busiest may not have time to indicate when they might get back to coworkers about common issues, and indeed everyone struggles from time to time to accurately gauge when they will get to a particular task. One solution to this problem is to help coworkers gauge the busyness of those around them by providing some clues about this busyness. Current solutions to the problem involve asking coworkers, which is distracting and can be a sensitive topic. We propose an algorithm to calculate a person's busyness, and convey this information via one of a number of mechanisms.
An algorithm to calculate personal busyness levels , and a means of communicating this information
To calculate busyness, multiple metrics are used in combination: sources of data can include number of unread emails and unlistened-to voicemails, calendar entries, to do items, keyboard activity, 'away' or 'busy' statuses on IM, and data from project management tools).
When the user first sets up the system, they adjust the relative priorities of each of these sources to best reflect their own approach to working and emphasise what they feel will be the most appropriate metrics. After this initial set up, further input is not required.
The system runs in the background, tracking the specified metrics to dynamically produce a "busyness rating" for each participant, and publishing this on their behalf.
The system would run silently for several weeks during a 'training period'. This will record a set of metrics representing the individual's level of activity and their level or responsiveness. This training period is necessary to establish which metrics are useful in measuring an individual's busyness and their responsiveness. (For example, the number of meetings a line manager might have as default will far exceed those of a developer; so Manager M may appear vastly busier than Developer D if the system only counted number of meetings.)
The busyness algorithm
Users choose which metrics should be most heavily weighted in the algorithm. Say that Bob uses the system, and knows his management of his email leaves much to be desired; as such, the number of unread emails in his inbox is not a good indicator of business. However, Bob is a manager and feels that meetings are a useful metric. So he adjusts a slider-based interface to give maximum weight to meetings, and minimum to emails.
The system runs in the background, and in this instance doesn't put much weight on information from Bob's inbox, but heeds his calendar strongly. When he has an above-average number of meetings, it increases his busyness rating. (Details below.)
In an extended scenario consider that Alice uses the system. Alice provides a supporting roll that involves sending and receiving a lot of email. Alice assigns a high weighting to her unread email count. The system also knows (from the training period) that if Alice has an unread email count of 100 then the average age of an email when it is replied to is 1 day, but if Alice has an unread email count of less than 50 then the average age of an email when it is replied to is 2 hours.
Regarding issues of privacy:
* Use of a rating rather than exact details (such as "Bob has 25 meetings this week, and normally has 15 meetings a week") stops people tracking colleagues' activities too closely.
* We only show this information to coworkers or contacts listed as 'trusted' by users of the system