REFERENCE TO RELATED APPLICATIONSThis application claims priority to U.S. Provisional Patent Application No. 61/441,781, filed Feb. 11, 2011, which is incorporated by reference.
TECHNICAL FIELDThe systems and methods described below relate generally to the field of task management systems that include communication functionality. More particularly, the systems and methods relate to facilitating collaboration between parties by integrating communication aspects into a task workflow system and providing context-based options for creating workflows and responding to workflow-related communications.
BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1 is a block diagram of a computing device.
FIG. 2 is a block diagram of a task management system.
FIG. 3 is a timeline diagram of example operations of a task management system.
FIGS. 4-29 are plan views of a graphical user interface of a computing device.
FIG. 30 is a flow diagram of an operation of the task management system.
SUMMARYThe systems and methods described here combine workflow and task management features with collaborative communication capabilities to provide an integrated task management system. The task management system consolidates tasks, messages, alerts, and notifications for workers and facilitates communications between parties. The task management system can use contextually available information relating to the tasks, messages, alerts, notifications, and communications to optimize efficiency, and ensure that tasks and messages are prioritized and timely completed.
A computer-implemented method for handling a workflow comprises receiving a workflow request to perform a task of a microflow that includes the task, and a contact address associated with the task at a processor, sending a message to the contact address that includes at least a response to the workflow request, a status associated with performance of the task, a completion status associated with completion of the task, an inquiry related to the workflow request, and a request to open a communication session. The method further includes storing the task in at least one workflow queue in a memory, dynamically prioritizing the task at the processor, and presenting at least one of an indication of a workflow request, an indication of a message, an indication of a request to open a communication session, and the task at a human-machine interface such as a display.
The computer-implemented method can also include receiving at least one of a second workflow request to perform a second task of the microflow, a notification message, an alert message, a message include a plurality of response options, and a request to open a communication session at the processor. The computer-implemented method can also include receiving a second workflow request to perform a second task of the microflow at a second processor, and receiving at the first processor a notification message associated with at least one of acceptance at the second processor of the second workflow request, performance of the second task, and completion of the second task. The workflow request can include one of an importance level, a requested start time, a requested completion time for at least one of the task, and the microflow, a requested length of time to complete at least one of the task, and the microflow, and a location for performance of the task, and the task can be task dynamically prioritized based at least in part on at least one of a time factor, a milestone, an environmental factor, a personnel factor, and a priority. The time factor can include at least one of the current time, an expiration of a timer, a preset time prior to the requested completion time of the task, an elapsed time since the workflow request was requested, an elapsed time since the workflow request was accepted. The milestone can include at least one of the start of performance of the task, a completion of the task, and the non-performance of the task. The environmental factor can include at least one of a sensor input from a sensor, a signal from an external system, and a data obtained from an external information source. The personnel factor can include at least one of a change in available personnel, a shift change associated with a time, and an availability of an individual for performing the task. The priority can be based upon at least one of the importance level, a priority set by a user override, a priority based at least in part on an importance factor and a time factor, a priority based at least in part on the location for performance of the task, a priority set in accordance with the type of task, a priority set in accordance to at least one of a business policy rule associated with the task, and a regulatory compliance rule associated with the task.
The message in the computer-implemented method can be sent in accordance with a medium associated with the contact address, and can be selected from the group consisting of a text message, a multimedia message, an email message, a voice call, a video call, a conference call, a web-based session using a uniform resource locator, and a call to an interactive voice response system. The medium can be based on at least one of a preferred medium selection associated with the contact address, a previously selected medium used in sending a message, and a user override selection of the medium.
The computer-implemented method can also include determining a response to the workflow request prior to sending the message that includes the response. The operation of determining can be based at least in part on one of a location associated with the performance of the task, a number of tasks in the workflow queue, the type of task, a past performance of a task of a microflow, a current performance of a task of a microflow, and a user availability setting, and the response can be selected from the group consisting of rejecting the workflow request, and accepting the workflow request.
The computer-implemented method can also include presenting a prompt that includes the response and receiving an input for responding to the prompt at the human-machine interface and the response can be based at least in part upon the received input. The computer-implemented method can also include sending a plurality of messages in a response-sequence order. A subset of the plurality of messages can include at least one of a status of the performance of the tasks, and user-selectable context-driven responses, each of which is based at least in part on a previous message in the plurality of messages. The computer-implemented method can also include receiving an indication that the task was completed by a third party, updating the workflow queue based at least in part on the indication, and dynamically prioritizing a second task.
A computer-readable storage medium having computer-executable instructions stored thereon to instruct a processor to perform a method comprises sending a workflow request to a first recipient, where the workflow request is associated with a microflow and includes a task, and a contact address associated with the task, receiving at least one of a response to the workflow request, a status associated with performance of the task, and a completion status associated with a completion of the task; and logging in a memory at least one of the workflow request, a timestamp associated with sending the workflow request, the response, a timestamp associated with the response, the status, a timestamp associated with the status, the completion status, a timestamp associated with the completion status, a message associated with at least one of the workflow request, the task, the status, and the completion status, a timestamp associated with the message, a communication session opened with the first recipient, and a timestamp associated with the communication session.
The processor in the computer-readable storage medium can also be configured to perform the method of sending at least one of a rescind notification of the workflow request to the first recipient, a message to remove the task from the workflow queue to the first recipient, and the workflow request that is associated with the microflow to a second recipient. The processor can also be configured to perform the method of receiving a message to delegate the task to a second recipient from the first recipient, and sending at least one of the task and the workflow request to the second recipient. The processor can also be configured to perform the method of presenting a list of preconfigured tasks at a human-machine interface, selecting the task from the list of preconfigured tasks, presenting a list of contact addresses, selecting an address of the first recipient from the list of contact addresses, presenting a list of importance levels, selecting an importance level of the task from the list of importance levels, presenting one or more informative messages associated with the task, performing an operation including at least one of selecting an informative message, selecting and modifying an informative message, creating an informative message, creating the workflow request that includes the task, the importance level, the informative message, and one or more preconfigured response options, and addressing the workflow request to the address of the first recipient. A presented order of the preconfigured tasks can be based at least in part on at least one of the most frequently selected preconfigured tasks, the most recently selected preconfigured tasks, sensor data associated with a preconfigured task. A presented order of the list of contacts is based at least in part on at least one of the most frequently selected contact addresses, the most recently selected contact addresses, an availability status of one or more contacts in the list of contacts, a logged-on status of one or more contacts in the list of contacts, a contact address associated with the selected preconfigured task in a previous workflow request, a contact address belonging to a same group as the selected contact address, a contact address authorized to perform the selected preconfigured task, and a contact address identified as having a skillset associated with the selected preconfigured task.
The processor in the computer-readable storage medium can also be configured to perform the method of accepting an input, at the human-machine interface, for customizing at least one of the task, an importance level, an informative message, a response option associated with the task, and a list of contact addresses authorized to send the task that includes at least one of the first recipient, and a group. The processor in the computer-readable storage medium can also be configured to perform the method of storing at least one of the task as a preconfigured task, the importance level as an importance level of the preconfigured task, the informative message as an informative message associated with the preconfigured task, the response option as a preconfigured response option associated with the preconfigured task, and the list of contact addresses authorized to send the preconfigured task.
A system comprises a computing device having a processor configured to receive a workflow request that is associated with a microflow that includes a task, and a contact address associated with the task, and send a message to the contact address that includes at least one of a response to the workflow request, a status associated with performance of the task, a completion status associated with completion of the task, and an inquiry related to the workflow request, open a communication session with the contact address, store the task in at least one workflow queue, dynamically prioritize the task, and present at least one of an indication of a workflow request, an indication of a message, an indication of a request to open a communication session, and the task at a human-machine interface. The system can include a memory configured to store the workflow queue, a communications interface configured to receive the workflow request, send the message, and open the communication session, and a human-machine interface configured to accept an input and present the task. In a configuration, the computing device is a mobile computing device, and the communications interface is a wireless communications interface, and the human-machine interface includes at least one of a display configured to present at least one of the workflow request, the task, the contact address, a display of an icon associated with the type of task, a display of a shape associated with a priority of the task, a display of a color coding associated with a priority of the task, a display of a shading associated with a priority of the task, and a display of an alert, an audible element configured to present at least one of an audible message about the task, and an audible alert, a vibratory element configured to present a vibratory alert, and an input means for accepting the input.
The system can prioritize a task based at least in part on a time factor that includes at least one of the current time, an expiration of a timer, a preset time prior to the requested completion time of the task, an elapsed time since the workflow request was requested, an elapsed time since the workflow request was accepted, and a milestone that includes at least one of a start of performance of the task, a completion of the task, and a non-performance of the task, and an environmental factor that includes at least one of a sensor input from a sensor, a signal from an external system, and a data obtained from an external information source, a personnel factor that includes at least one of a change in available personnel, a shift change associated with a time, and an availability of an individual for performing the task, and a priority that is based on a least one of an importance level of the task, a priority set by a user override, a priority set by the location for performance of the task, a priority set by the length of time to complete the task, a priority set by the type of task, and a priority set in accordance to at least one of a business policy rule associated with the task, and a regulatory compliance rule associated with the task.
DETAILED DESCRIPTIONThe apparatuses, devices, systems and methods disclosed and described in this document can be used to handle task management aspects and communication aspects of an integrated task management system. Those of ordinary skill in this art area will recognize from reading this description that the apparatuses, devices, methods, and systems described can be applied to, or easily modified for use with, other types of equipment, other arrangements of computing systems such as client-server, peer-to-peer, or distributed systems, other protocols, and at other layers in communication protocol stacks.
Throughout this disclosure, references to components or modules generally refer to items that logically can be grouped together to perform a function or group of related functions. Like reference numerals are generally intended to refer to the same or similar components. Components and modules can be implemented in software, hardware, or a combination of software and hardware. The term software is used expansively to include not only executable code, but also data structures, data stores and computing instructions in any electronic format, firmware, and embedded software. The terms information and data are used expansively and includes a wide variety of electronic information, including but not limited to machine-executable or machine-interpretable instructions; content such as text, video data, and audio data, among others; and various codes or flags. The terms information, data, and content are sometimes used interchangeably when permitted by context. It should be noted that although for clarity and to aid in understanding some examples discussed below might describe specific features or functions as part of a specific component or module, or as occurring at a specific layer of a computing device (for example, a hardware layer, operating system layer, or application layer), those features or functions may be implemented as part of a different component or module or at a different layer.
The examples discussed below are examples only and are provided to assist in the explanation of the apparatuses, devices, systems and methods described herein. None of the features or components shown in the drawings or discussed below should be taken as mandatory for any specific implementation of any of these the apparatuses, devices, systems or methods unless specifically designated as mandatory. For ease of reading and clarity, certain components, modules, or methods may be described solely in connection with a specific figure. Any failure to specifically describe a combination or sub-combination of components should not be understood as an indication that any combination or sub-combination is not possible. Also, for any methods described, regardless of whether the method is described in conjunction with a flow diagram, it should be understood that unless otherwise specified or required by context, any explicit or implicit ordering of steps performed in the execution of a method does not imply that those steps must be performed in the order presented but instead may be performed in a different order or in parallel.
FIG. 1 illustrates anexemplary computing device100. Thecomputing device100 can a desktop computer, a server, a mobile computing device such as a smartphone, or any other suitable computing device as would be understood in the art. Thecomputing device100 includes aprocessor120 that can be any suitable type of processing unit, for example a general purpose central processing unit (CPU), a reduced instruction set computer (RISC), a processor that has a pipeline or multiple processing capability including having multiple cores, a complex instruction set computer (CISC), a digital signal processor (DSP), an application specific integrated circuits (ASIC), a programmable logic devices (PLD), and a field programmable gate array (FPGA), among others.
Thecomputing device100 also includes one ormore memories130, for example read only memory (ROM)140, random access memory (RAM)150,cache memory122 associated with theprocessor120, or other memories such as dynamic RAM (DRAM), static ram (SRAM), flash memory, a removable memory card or disk, a solid state drive, and so forth. Thecomputing device100 also includes storage media such as astorage device160 that can be configured to havemultiple modules162,164,166, such as magnetic disk drives, floppy drives, tape drives, hard drives, optical drives and media, magneto-optical drives and media, compact disk drives, Compact Disk Read Only Memory (CD-ROM), Compact Disk Recordable (CD-R), Compact Disk Rewriteable (CD-RW), a suitable type of Digital Versatile Disk (DVD) or BluRay disk, and so forth. Storage media such as flash drives, solid state hard drives, redundant array of individual disks (RAID), virtual drives, networked drives and other memory means including storage media on theprocessor120 ormemories130 are also contemplated asstorage device160.
Thememory130,processor120, andstorage drive160 can include nonvolatile memory for storing computer-readable instructions, data, data structures, program modules, code, microcode, and other software components for storing the computer-readable instructions in non-transitory computer-readable mediums in connection with the other hardware components for carrying out the methodologies described herein. Software components can include source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, or any other suitable type of code or computer instructions implemented using any suitable high-level, low-level, object-oriented, visual, compiled, or interpreted programming language.
In various configurations, thecomputing device100 can include asystem bus110 for interconnecting the various components of thecomputing device100, or thecomputing device100 can be integrated into one or more chips such as programmable logic device or application specific integrated circuit (ASIC). Thesystem bus110 can include a memory controller, a local bus, or a peripheral bus for supportinginput devices190,output devices170, or communication interfaces180.Example input devices190 andoutput devices170 include keyboards, keypads, gesture or graphical input devices, motion input devices, touchscreen interfaces, displays, audio units, voice recognition units, vibratory devices, computer mice, and any other suitable user interface.
Thecommunication interface180 allows thecomputing device100 to communicate with other device across a network. Thecommunication interface180 can be an Ethernet interface, a radio interface, a telephony interface, a Universal Serial Bus (USB) interface, or any other suitable communications interface.Example communication interfaces180 can includes wired data transmission links such as Ethernet and TCP/IP, as well as PSTN communications links such as Tls (or better), integrated services digital network (ISDN), Digital Subscriber Line (DSL), or dialup modems that implement, for example, the point-to-point protocol (PPP). Thecommunication interface180 can include wireless protocols for interfacing with private or public networks. For example, thecommunication interface180 and protocols can include interfaces for communicating with private wireless networks such as a WiFi network, one of the IEEE 802.11x family of networks, or another suitable wireless network. Thecommunication interface180 and protocols can include interfaces for communicating with public wireless networks, such as cellular networks.
FIG. 2 illustrates a block diagram of networked computing devices configured as atask management system200. Although illustrated as including both apublic network202 and aprivate network204, this is done for purposes of illustration only. In various configurations thetask management system200 can be implemented using only onenetwork202,204, a combination of apublic network202 and aprivate network204, and any other suitable combination including multiplepublic networks202 and multipleprivate networks204. Eachnetwork202,204 can be, for example, an intranet, the Internet, a telephone network, a cable network, a wireless network, a packet-switched network, a circuit-switched network, or any other suitable network. Example networks can include an asynchronous transfer mode (ATM) network, a packet-switched network running, for example, the TCP/IP suite of protocols, a wireless network running one or more of the IEEE 802.11x, IEEE 802.15, or IEEE 802.16 family of protocols (WiFi and Zigbee, among others), a cellular network using code division multiple access (CDMA or CDMA:2000), global system for mobile communications (GSM), a cellular network running a 3G or 4G protocol, or another suitable network, including networks using protocols currently in development or yet to be developed.
Thetask management system200 can be configured to use secure communication protocols such as Internet Protocol security (IPsec), Secure Sockets Layer (SSL), Transport Layer Security (TLS), secure hypertext transfer protocol (HTTPS/1.1) or any other suitable encrypted protocol. Encryption can also be performed using a suitable type of cipher, including a private key cipher, a symmetric private key cipher, a public key cipher, and an elliptic curve cipher, among others. Specifically, encryption can be implemented using the Advanced Encryption Standard (AES), the Data Encryption Standard (DES), triple DES (3DES), or another suitable cipher.
Thetask management system200 can include a firstmobile computing device206, a secondmobile computing device208, anadministrative computing device214, aworkflow server210, adata store212, and an interactivevoice response system216. As will be described in more detail herein, a user of the firstmobile computing device206 can send aworkflow request301 to the user of the secondmobile computing device208. Either of the users can open a communication session between themobile computing devices206,208, for example to discuss aworkflow request301 or performance of tasks. Communication sessions can include those normally associated with telephony services or the communication sessions can be internet-based communications such as voice over internet protocol (VoIP). Either of the users can send messages to themobile computing device206,208 of another user. Messages can include text messages, pictures or images, audio, or video, and can be short message service (SMS) messages, multimedia message service (MMS) messages, and other suitable message types. Themobile computing devices206,208 can also receive notifications, and alerts that can be readable text or data such as a structured set of data.
The messages can be acknowledged messages and include a response set, for example a read receipt, an acknowledgement (ACK), an indication of not acknowledged (NACK), and a call back indication among other message types. A response set can be contextually-relevant to the task or tasks in a workflow request, and can include a predetermined response sequence order. The messages can be selected from a list, can be part of an interactive text session, can include forms, can include uniform resource locators (URL), and can launch applications and plug-ins, and so forth. The response set may include the selection of one or more of a set of offered choices that answer an associated prompt.
The workflow requests, messages, communication requests, notifications, and alerts can be sent from othermobile computing devices206,208, or from other client interfaces using desktop applications, web-based applications, and telephony clients among other suitable clients and interfaces. An application programming interface (API) can provide an interface for either clients or servers to communicate withmobile computing devices206,208 or theworkflow server210. The API can also allow other users or other systems to provide information to or create workflows on thetask management system200. Both users and servers can create workflows on thetask management system200.
A user of anadministrative computing device214 can configure workflow requests on theworkflow server210 that are sent to users of themobile computing devices206,208. The user of theadministrative computing device214 can also perform supervisory functions such as monitoring the issuance of workflow requests to themobile computing devices206,208 of the users, reviewing the performance and completion of tasks by the users, and performing analysis and determining metrics relating to task performance by the users.
Theworkflow server210 can operate as a message and communications gateway between themobile computing devices206,208. For example, themobile computing devices206,208 andworkflow server210 can be configured as a client-server type architecture. In various configurations, theworkflow server210 can communicate workflow requests and receive acknowledgements and status updates from the users over one or more of thenetworks202,204. Theworkflow server210 can also be integrated with an interactive voice response system (IVR)216 for communicating with users using voice recognition or touchtone keypad interactions. Theworkflow server210 can use one or multiple servers. Theworkflow server210 can use one or multiple software modules and be split between multiple servers or aggregated onto a single server or virtual server.
Theworkflow server210 can store workflow requests, messages, communications, alerts, and notifications, and logs of information relating to the workflow requests, messages, communications, alerts, and notification in thedata store212. Theworkflow server210 can store time stamps for each of these events to facilitate later review and analysis. The logging and capturing of this information down to the individual message, permits both the users and the system administrator to review tasks and communications at a fine level of granularity. Theworkflow server210 captures all of the related tasks, workflow requests, acknowledgements, notifications, alerts, messages, and communications that together make up a microflow, and permits the users and the administrator to review the sequence of individual events, user actions, and user interactions of the microflow. The users and administrator can review the microflow after completion of the tasks associated with the microflow, or during the execution of the microflow. A user may have visibility only into the portion of the workflow in which the user is participating, while the administrator typically has visibility of the entire workflow.
A workflow can describe a process for a major activity such as producing a video, or treating a patient in hospital. The workflow steps employed by different individuals may vary in the details but can also be quite similar. For example, best practices or regulatory guidelines can create similarities in workflow steps. Complex workflows are composed of smaller workflows and for team-working workflows may be decomposed into specialist activities or to share the workload to gain time efficiency through parallelism. The breakdown of a complex workflow continues until a unit of work is the right size and type to be a microflow. A microflow is one or more tasks including the workflow request associated with the one or more tasks, and any other related notifications, alerts, messaging, and communication sessions associated with the tasks or workflow requests.
Tasks can be assigned, revoked, reassigned, and completed by one or multiple users. Tasks in aworkflow request301 can generate multiple new tasks, each of which may be performed by the same user or different users working in collaboration. Completion of a task can depend on the completion status of other tasks being performed by other users. A workflow can also comprise a single task, sent in aworkflow request301 to a single user to be performed. Theworkflow server210 captures logs and information regarding all of the related activities of workflows thereby permitting review, real-time and post analysis, and the development of performance metrics. Workflows can be analyzed to ensure that business policies are being adhered to and that regulatory policies are being complied with.
Theworkflow server210 can be any kind of suitable server, including a virtual server operating over anetwork202,204, or multiple servers. Themobile computing device206,208 can be any kind of suitable computing device including, but not limited to a cell phone, a mobile phone, a smart phone, a computing tablet, a laptop, a portable computing device, and a computing device mounted in a moving platform, for example a vehicle, among other suitable platforms. Although thetask management system200 is illustrated withmobile computing devices206,208, in various configurations thetask management system200 can include non-mobile, or fixed, computing devices such as desktop computers, computing devices embedded in non-mobile platforms, and other non-mobile computing devices. Practical usage scenarios can have a mix of users using fixed computing devices and mobile computing devices.
FIG. 3 illustrates an exemplary timeline ofoperations300 performed by atask management system200. The timeline ofoperations300 visualized inFIG. 3 is for the purpose of illustrating some of theoperations310,320,330,340,350,360,370 possible in atask management system200 and is not intended to illustrate the complete set of allpossible operations310,320,330,340,350,360,370. Theoperations310,320,330,340,350,360,370 can be performed in a different order than presented, and are presented in the current order for purposes of providing a clear description only.
In afirst operation310, at point A in the timeline, a first user of a firstmobile computing device206 creates aworkflow request301 having a task to be performed, at least in part, by a second user of a secondmobile computing device208. Theworkflow request301 passes through theworkflow server210 and is forwarded to the secondmobile computing device208. Once theworkflow request301 is received by the second user of themobile computing device208, the second user can select aresponse303 at point C in the timeline and send thatresponse303 back to first user. Theresponse303 passes through theworkflow server210 and is forwarded to the firstmobile computing device206 of the first user. Although thefirst operation310 is described for aworkflow request301 sent to a second user of a secondmobile computing device208, the second user and secondmobile computing devices310 can include multiple second users as well. For example, in a configuration the second user can be a group and the recipients of theworkflow request301 can include themobile computing devices208 of each member of the group. Similarly, this applies to theother operations320,330,340,350,360, and370.
Referring now toFIG. 3 andFIG. 4, an example of aworkflow request301 created at point A is illustrated.FIG. 4 illustrates ascreenshot400 for creating anew workflow request301. The first user presses thenew workflow selection404 on thedisplay402 of the firstmobile computing device206. The first user is presented the option of creating anew workflow request406, or selecting from a number of preconfigured workflow requests408. Thetask management system200 can use contextual information in determining which preconfiguredworkflow requests408 to display to the first user. For example, the first user can see only the preconfiguredworkflow requests408 that the first user has authority to send. Thepreconfigured workflow requests408 can be ordered alphabetically, ordered based on frequency of use, or ordered based on other information such as time of day or recently sent or received workflow requests301. Thepreconfigured workflow requests408 can be grouped into folders of related workflows to facilitate selection, sorted by the first user, and searched by the first user. If permitted by the task management system, the first use can create anew workflow request406.
The first user can also be a recipient of workflow requests301. The first user can select thetask selection414 to review the current tasks assigned to the first user. The first user can select the sentselection410 to review workflow requests301 sent by the first user to recipients such as the second user. The first user can sendworkflow requests301 to themselves as well, and therefore be both a recipient and a sender of thesame workflow request301. For example, the first user may want to send an alarm to their ownmobile computing device206 to remind them of an imminent event. The first user can also select thehistory selection412 to review the history of sent and received actions of tasks that have ended. At this top level, thehistory selection412 can be configured to show all tasks and actions of the first user. The first user can select one of the entries to display actions associated with the task, notification, alert orworkflow request301, as describe in the detailed description accompanyingFIGS. 20 and 21.
Referring now also toFIG. 5, ascreenshot500 illustrating aneditable workflow request301 is presented. The workflow request includes aworkflow name502. The first user can select or modify thecontact address504 of the recipient of theworkflow request301, thedue time506, theimportance508 of theworkflow request301, and optionally include amessage510 for the recipient of theworkflow request301. The first user can then press asend selection512 to send theworkflow request301 or a cancelselection514 if the first user opts not to send thisworkflow request301.
The task associated with theworkflow request301 can be a process task, where the second user is requested to perform a task and respond appropriately with an acceptance and eventually a completion message once the task is performed. The task can be a notification or message, where a simple acknowledgement of the task completes the task. A task can also be a communications request, where one party requests the other party to open a communications session, after which the task is complete. The task can also be a voting task, where theworkflow request301 is sent to a group, and based on theresponses303, the first user picks one or more second users to perform the task. The task can also be a multiple choice question, where the second user is request to select a choice from one or more selections. For example, the multiple choice question can be, “When can you do this task”, with possible selections “1—immediately”, “2—in 1 hour”, “3—today”, “4—tomorrow”, and “5—cannot perform”.
Theworkflow request301 also includes the contact address of the first user. This facilitates collaboration between the first user and second user, so that message can be easily sent and communication sessions can be easily initiated between the first user and the second user. For example, theacknowledgement options1302 discussed later with regards toresponses303 from the second user to theworkflow request301 can include options for contacting the first user. For some tasks, such as tasks that are delegated, the workflow request can include one or more second contact address (not shown) to which the second user sendsresponses303 and messages.
Referring now also toFIG. 6, ascreenshot600 illustrating animportance selection toolbar602 is presented. In a configuration, if the first user attempts to modify theimportance508 of theworkflow request301, animportance selection toolbar602 can be presented. Theimportance selection toolbar602 facilitates in the selection of theappropriate importance508 for theworkflow request301.Example importance508 can include normal, important or very important. Theimportance508 can be configured by the system administrator to suit the needs of their organization, and can have more or less than three levels. For example, a hospital may use the terms Normal, Stat, Emergency. Theimportance508 can be configured to trigger an alert to the second user when theworkflow request301 is received by the second user. For example, aworkflow request301 configured to have animportance508 of critical can cause a pop-up alert window, an audible alert, a vibratory alert, and so forth. Theimportance508 can force the second user to acknowledge or otherwise respond to theworkflow request301. Ascreenshot1400 of an alert1402 is presented inFIG. 14 and the accompanying detailed description. In an alternate configuration, theimportance508 can include a measure of time urgency, for example critical, urgent, time sensitive, non-urgent, and so forth.
Theimportance selection toolbar602 presents one way in which selectable options forimportance508 can be selected. As would be understood by those familiar in the art, this type of selection toolbar can be used for making selections for other fields displayed in other screenshots through this disclosure. Theimportance selection toolbar602 is just one kind of toolbar possible; other kinds of toolbars and other types of graphical user interfaces known in the art, or yet to be developed, are also known or contemplated in this disclosure.
Theimportance508 for a particular type ofworkflow request301 can be preconfigured by a system administrator. Theimportance508 can default to aparticular importance508 but a user can override thedefault importance508 if desired. Theimportance508 can also be limited to certain values. For example, a business policy or regulatory policy can prohibit setting theimportance508 to certain values, for example lowering the urgency below very important, or prevent the first user from modifying theimportance508 altogether. In another example, the ability to change theimportance508 can be limited to certain users, for example those users identified as supervisors or those users belonging to a supervisor group.
Similarly, thedue time506 can be a fixed selectable time, or a time interval added to the current time. For example, the first user can be presented with a choice of selecting a fixe time for thedue time506 or a time interval, for example 15 minutes, 30 minutes, an hour, a day, and so forth (not shown). If the first user selects the time interval, for example 15 minutes, then that time interval is added to the current time to produce the due time. The system administrator can preset a time interval for the task, which the first user can override.
The priority of a task can be derived from a combination, a product, or a weighting of other factors. Thetask management system200 can use a strict priority algorithm, a weighted round robin algorithm, or another suitable algorithm based on business policies or regulatory policies. For example, priority can be a combination, a product, or a weighting of an importance factor and a time factor. The importance factor can be, for example, whether a task is of normal importance, high importance, or very important. The time factor can be a normal urgency, a high urgency, and very urgent. These factors can be combined, multiplied, or weighted to provide a priority rating. The priority of a task can be dynamically reprioritized as new tasks andworkflow requests301 are received.
In addition, each of the factors can be represented by an icon. One set of icons can represent the importance factors and another set of icons can represent the time factors. The icons can be displayed along with theworkflow request301 as a visual indication of the urgency of the tasks. In addition to icons, thetask management system200 can display shapes, colors, shading, and any other suitable symbol or combinations of symbol to provide information to the users. For example, thetask management system200 can display an icon associated with the type of task, and overlay an additional icon associated with the importance factor and a color coded symbol associated with the time factor. Similarly, icons and symbols can convey information such as completion status of a task or busy status of a user. In a configuration, tasks having normal urgency and normal importance do not use an icon or symbol in order to reduce the amount of clutter on the display and to highlight those tasks that are of a higher urgency or higher importance.
Icons or symbols can be dynamically changed based on contextual information available to thetask management system200. For example, a time factor icon can be changed from normal urgency, to high urgency, to very urgent as time progresses towards the requested completion time for the task associated withworkflow request301, while an icon for the importance factor remains unchanged. For example, aworkflow request301 can be sent at 10:00AM with a time factor of normal urgency, or standard urgency, and a due time of 1:00 PM. Thetask management system200 can be configured, for example using a rule, such that if theworkflow request301 is not acknowledged, or if performance of the associated task has not commenced, within 30 minutes of thedue time506 of the task, the urgency of theworkflow request301 and the associated task can be changed to high urgency, and at 15 minutes the urgency can be changed to very urgent. The change in urgency can trigger the pop-up alert window, the audible alert, the vibratory alert, and force the second user to acknowledge or otherwise respond to theworkflow request301. Similarly, the urgency can dynamically change based on other factors such as external events including environmental factors, events reported by sensors, milestone events such as commencement of performance of a task, completion of related tasks in the workflow by the user or other users, personnel shift changes, and so forth. Thetask management system200 can use this priority in ordering the presentation of tasks displayed from a user'stask queue1102 illustrated inFIG. 11.
Referring now also toFIGS. 7 and 8,screenshots700 and800 illustrating selection of thecontact address504 are presented. The first user'saddress book702 can be organized intogroups704, for example the groups all contact addresses706,favorites708 or recently used contact addresses504,nursing710, and so forth. The first user can select one of thegroups704 to drill down to individual contact addresses504, or press theback selection712 to return to the screen for creating anew workflow request301 shown inscreenshot400. If the first user selects one of thegroups704, for example thefavorites708 selection, they are presented withscreenshot800 that presents contact addresses504 associated with thatgroup704. Referring toFIG. 8,contact address504 associated with thegroup704 calledfavorites708 is presented. Each of the contact addresses504 can include an icon orstatus identifier802. Thestatus identifier802 can provide, at a glance, information about the availability of the user associated with thecontact address504.Example status identifiers802 can include color identifiers such as green, yellow, red, blue, and so forth that identify whether the user associated with thecontact address504 is available to accept new workflow requests301, is busy performing a task, is available or unavailable for incoming communication requests, is currently in a communication session with another user, has turned off their mobile computing device or is out of range, and so forth. Thestatus identifier802 can be configured by thetask management system200. Thestatus identifiers802 can indicate the relative amount of tasks andworkflow requests301 in the user'stask queue1102. Thestatus identifiers802 can be solid colors, shaded or have markings, include symbols, include overlapping icons, be flashing, or use other suitable techniques for conveying status information. If the first user does not select acontact address504, the first user can select theback selection712 to return to the address book screen. Theback button804 can display contextual information about the display or screen that the first user will return to upon pressing theback selection804. In a configuration, the first user can select thestatus identifier802 of acontact address504 to receive additional information about the status of that user.
The first user can select thecontact address504 to use for the communication. Referring now also toFIG. 9, ascreenshot900 of acontact address504 is presented. Thescreenshot900 presents thename902 of the user that is associated with thecontact address504, which can be different from, or the same as, the text used in thecontact address504 itself. In a configuration, the first user can modify the text of thecontact address504 to make thecontact address504 more user friendly, for example using a nickname for a user. In addition to the name, there can be several different options for communicating with the second user that is associated with thecontact address504. For example, thecontact address504 can include amobile phone number904, anoffice phone number906, an email address (not shown), a home phone (not shown), and other suitable contact addresses504. Thecontact address504 can also includeadditional information910 about the user associated with thecontact address504, such as groups the user is associated with and titles, positions, or roles performed in the workplace.
In the configuration illustrated in thescreenshot900, only some of the possible fields are illustrated. This can be done to comply with a business policy. For example, a business using thetask management system200 may require all users to use anIVR system216 for receiving and responding toworkflow requests301 so that there is uniformity in how users are informed ofworkflow requests301 and how they send acknowledgements andresponses303. Another example of a business policy is a privacy policy. A privacy policy may limit what kind of information of the second user is available to the first user.
In another configuration, thefields904,906 that are displayed can be limited to those that are populated with information. This can reduce the amount of clutter on the display and make it easier for the first user to select theappropriate field904,906 for sending theworkflow request301. In yet another configuration, thefields904,906 that are displayed can be based on context or contextual information. For example, if thetask management system200 is aware that the second user associated with thecontact address504 is currently contactable by either theirmobile phone904 orwork phone906, then thetask management system200 can limit the display to just thoseselectable fields904,906.
After the first user has selected thecontact address504 and the particular mode of communications for sending theworkflow request301 to the second user, the first user can select theback selection912 to return to the previous screen. Theback selection912 can display information about the display or screen that the first user will return to upon pressing theback selection912. In a configuration, theback selection912 can use the standard navigation controls available through the operating system of the second mobile computing device.
The first user can select the contact address, for example thecontact address504 associated with the user “Anne Brown”. After selecting, the user will return to thegroup704 called “Nursing”710 to display other members of the group “Nursing”. In this way, the first user can select multiple contact addresses504 for sending theworkflow request301 before returning the first user back to the screen for creating anew workflow request301 shown inscreenshot400.
Referring now toFIG. 10, ascreenshot1000 illustrating manual entry of acontact address504 associated with task of aworkflow request301 is presented. In addition to using the address book functionality described inFIGS. 7-9, the first user can also manually enter acontact address504. In particular, thisscreenshot1000 illustrates the entering of a phone number for a phone action task. The first user can enter thephone number1002 using akeypad entry1004. In a configuration of thetask management system200, the first user can enter information using other means available on the firstmobile computing device206, for example, voice recognition. In various configurations,other contact address504 information can be entered including, but not limited to, an email address or a name. The information entered by the first user can also be used to look up an address in the address book, or to create anew contact address504. More generally, this could be used to set the email address for launching a pre-addressed email, or embedding a web-base uniform resource locator (URL) for launching a web page.
Returning back toFIGS. 2 and 3, once the first user of the firstmobile computing device206 has created the workflow request and addresses theworkflow request301 to thecontact address504 of the secondmobile computing device208, the first user sends theworkflow request301. Theworkflow request301 can be received by theworkflow server210 prior to, or in conjunction with, receipt of theworkflow request301 by the secondmobile computing device208. InFIG. 3, the timeline ofoperations300 illustrates the case where theworkflow request301 is received first by theworkflow server210 and then forwarded to the secondmobile computing device208 by theworkflow server210.
The inclusion of aworkflow server210 in the communication path betweenmobile computing devices206,208 provides several benefits described below. However, in a configuration, the workflow requests301 and subsequent communications can be sent directly betweenmobile computing devices206,208 using a peer-to-peer communication path without aworkflow server210. In another configuration, themobile computing devices206,208 can send copies of messages or summary information about the workflow requests301 and subsequent communications to theworkflow server210 and the othermobile computing device206,208.
One benefit of using aworkflow server210 is that theworkflow server210 can optionally validate or alter information in theworkflow request301. For example, theworkflow server210 can validate that theworkflow request301 is being sent to a current employee. Theworkflow server210 can alter who theworkflow request301 is sent to. For example, if the intended recipient of theworkflow request301 has another user filling in for them, then theworkflow request301 can be forward to that user. Theworkflow server210 can also police theworkflow request301 by verifying theworkflow request301 against one or more business policy rules or regulatory policy rules.
Another benefit of using aworkflow server210 is that theworkflow server210 can log the various messages and communications between themobile computing devices206,208. In various configurations, theworkflow server210 can save copies of the messages and save information about the communications between themobile computing devices206,208. In various configurations, theworkflow server210 can be used to perform analysis of the messages and communications as described below.
Another benefit of using aworkflow server210 is that theworkflow server210 can work in conjunction with a presence server to determine if thecontact address504 needs to be changed in order to send theworkflow request301 to the second user of the secondmobile computing device208. For example, if the secondmobile computing device208 is present on a local WiFi intranet, an example of aprivate network204, theworkflow server210 can send the message using an email message. However, if the secondmobile computing device208 is present only on apublic network202 such as a cellular network and the second user does not have a data plan for the secondmobile computing device208, then theworkflow server210 can send theworkflow request301 to the second user'smobile computing device208 using the short message service (SMS), for example by instructing the second user of the secondmobile computing device208 to dial into theIVR216 to receive and respond to theworkflow request301.
Theworkflow server210 forwards theworkflow request301 to the secondmobile computing device208. The second user of the secondmobile computing device208 receives theworkflow request301 and can present theworkflow request301 to the second user. Theworkflow request301 can be presented to the second user in multiple different ways. For example, theworkflow request301 can be presented on a human-machine interface such as a display on the secondmobile computing device208. A display is only one type ofoutput device170 of acomputing device100. Theworkflow request301 can also be presented as an auditory message, for example using a text-to-speech feature, by playing a sound file, such as a .wav, .mp3, or other auditory means.
Theworkflow request301 can be presented with an alert, such as a visual alert on the display, a vibratory alert, an audible alert, or a combination of alerts. Theworkflow request301 can be presented as a combination of an alert and a displayed message. These presentations and alerts can alert the second user that anew workflow request301 has been received and can provide information to the second user about the type of, urgency of, orimportance508 of,workflow request301. For example, the second user may carry their secondmobile computing device208 in a pocket. For example, the combination of a vibratory alert, and an audible alert particular to the kind of task in theworkflow request301 can immediately alert the second user to the type ofworkflow request301.
Theworkflow server210 can send aworkflow request301 to the second user using one or multiple methods, including but not limited to using anIVR system216, an email, a text message, instant messaging, and multimodal communications among other methods. The second user can be notified about anew workflow request301 or change to an existing task orworkflow request301 which then triggers the secondmobile computing device208 to poll theworkflow server210 to receive theworkflow request301. Theworkflow request301 can be received in an XML message, for example if the task management system uses RESTFUL web APIs between theworkflow server210 and secondmobile computing device208. Theworkflow request301 and task can include metadata for creating the communications sessions for processes with other servers such as an email server, a web server, a call server, among other servers.
In another configuration, the notification can be a SIP notification, and theworkflow request301 can be received in a SIP notification. In another example, the alert can be a call-in number associated with theworkflow request301. The alert can be sent to a second-user's pager or mobile phone to prompt the second user to call into theIVR system216. The second user can have a personal identification number (PIN) for responding to the workflow request and theworkflow request301 can have a numeric identifier. The second user calls into theIVR system216 and the IVR system can read out the message, for example using a text-to-speech module. The second user can speak their response to theIVR system216 and using a speech recognition module theIVR system216 can generate theresponse303. The second user can also press number keys on a phone to send responses using the dual-tone multi-frequency (DTMF) in-band signaling used by the phone for dialing. The second user can also opt to respond to theworkflow request301 using email, text messaging, and other methods available to the second user. Thetask management system200 can support multi-modal communications wherein theworkflow request301, messages, acknowledgements,responses303, and notifications are performed using the same, or different, communication mediums.
When the second user is not reached or has not responded back with an acknowledgement orresponse303, theworkflow server210 can take additional steps before escalating theworkflow request301 as described in greater detail later in the disclosure relating to server-generated workflow requests304. For example, theworkflow server210 can make calls to the second user a preconfigured number of times using a preconfigured interval between each of the calls. Theworkflow server210 can attempt to reach the second user using different mediums based on the information available to theworkflow server210 in the contact address associated with the second user. The second user can provide a preferred contact mode for theworkflow server210 to use in contacting the second user. For example, the second user can configure a preferred order of addresses, such asmobile phone number904 and thenoffice phone number906, in thecontact address504 for contacting the second user.
Referring now toFIG. 11, ascreenshot1100 illustrating a display of tasks from a user'stask queue1102 is presented. The display of the user'stask queue1102 can be a scrollable display of tasks. The user'stask queue1102 can be asingle task queue1102 or can includemultiple task queues1202. For example, there can be atask queue1102 associated with tasks of a particular priority level, urgency, orimportance508. Thetask queue1102 can include tasks andworkflow requests301 sorted by due date. Thetask queue1102 can be an unsorted or sorted list from which the display of tasks is first prioritized and then displayed to the user. There can be aseparate task queue1102 forworkflow requests301 andseparate task queue1102 for tasks associated with the workflow requests301 that have already been accepted by the second user.
The tasks can be prioritized using rules and combinations of rules. Example rules for prioritizing the tasks can include prioritizing by a time factor, for example based on the current time, the expiration of a timer associated with the task, a preset time or threshold time prior to the requested completion time of the task, the elapsed time since the workflow request was requested or accepted by the second user. Another example rule can include prioritizing based on a milestone event such as the start of performance of the task, the completion of the task, or the non-performance of the task. Another example rule can include prioritizing based on environmental factors such as an input from a sensor, for example a sensor on a piece of monitoring equipment, a signal from an external system, or data available to the task management system that is obtained from an information source such as an external database. Another example rule can include prioritizing based on personnel factor such as changes in available personnel, for example if a second user has quit or been terminated, a shift change such as a shift change associated with a particular time, and the availability of a second user or a group of second users for performing the task.
Another example rule can include prioritizing based on theimportance508, for example theimportance508 requested by the first user, anurgency508 determined by the second user or an administrator, for example animportance508 changed by the second user performing a user override function to change theimportance508, an urgency determined by the location for performance of the task, for example a location used in conjunction with the current location of the second user. In this example, if the second user is in close proximity to the location for the performance of a task, the urgency orimportance508 for that task can be temporarily increased so as to alert the second user of the task nearby that needs to be performed. Similarly, if the second user performs work in two different locations, the tasks can be prioritized so that the second user is not unnecessarily bounced between the two different locations during performance of tasks from the second user'sworkflow queue1102. This is an example in which thetask management system200 can use contextual information to prioritize tasks and increase overall user efficiency. The prioritization can also be based on an urgency orimportance508 set by the type of task. Some task types can have an urgency orimportance508 set according to a business policy rule associated with the type of task or a regulatory compliance rule associated with the type of task. The business policy rule or regulatory compliance rule can use other factors in combination with the urgency orimportance508, including but not limited to, the role or position of the first user or second user, the locations of the second user or other users, the time of day, and so forth.
The secondmobile computing device208 can present an indication that there is anew workflow request301 by displaying anumerical icon1106 in thetasks selection414. The secondmobile computing device208 can display theworkflow request301 in the second user'stask queue1102, or task list. In an alternate configuration, the second user must first accept theworkflow request301 before the task appears in the user'stask queue1102. Theworkflow request301 can be displayed withicons1108,1110, colors, shading, or other indicators that provide information to the second user without requiring the second user to first select and individually view theworkflow request301. For example, theworkflow request301 can be displayed with animportance icon1108 that shows theimportance508 of theworkflow request301, and atask type icon1110 that provides the second user with information about the nature of theworkflow request301. The presentation of the tasks can be sorted or ordered by priority, urgency, orimportance508, by recipient name, by due time, by task type, or by another suitable field. Selecting an area of the screen, or performing a gesture such as a swipe, can trigger a popup for selecting the sorting options (not shown). In another configuration, a sort selection (not shown) can trigger the display of the sorting options.
The status of the second user can be displayed using, for example, a color indication in thestatus window1112. For example, if the second user is going to begin performance of a task, the second user can quickly set their status to busy by tapping thestatus window1112. The status can be selectable from a group of selections (not shown) or toggled between two states, for example an available state displayed as a green indication in thestatus window1112 and a busy state displayed as a red indication in thestatus window1112. Thetask management system200 can use contextual information and a rule to set the status of the second user in thestatus window1112 without additional input from the second user. Thestatus window1112 provides a visual indicator to the second user of the change in status. For example, if the second user begins performance of a particular kind of task, thetask management system200 can apply a rule and changed the status of the second user to busy and change thestatus window1112 to red. When the user has completed the task, thetask management system200 can set the status of the user back to available and change thestatus window1112 to green.
Referring now also toFIG. 12, ascreenshot1200 of theworkflow request301 is presented. Theworkflow request301 includes theworkflow name502, amessage510 included with theworkflow request301, thedue time506, and the name of the first user, orsender1202, of theworkflow request301. Alog selection1208 allows the second user to view actions, messages, and communications associated with theworkflow request301. Twoaction selections1204,1206 allow the second user to respond to theworkflow request301. Theaction selection1206 opens a window ofacknowledgement options1302 to accept or reject the task.
Thecommunication selection1204 allows the second user to quickly open a communication session with requester1212, such as a telephone call, an email, a message service, a proprietary messaging service, or an SMS or short message service session with the first user to discuss theworkflow request301. Thesender1202 and requester1212 can be the same user, for example the first user as illustrated. In another example, thesender1202 can forward aworkflow request301 that thesender1202 received from a third user. The third user can be the user that created theoriginal workflow request301. In this example, therequester1212 can be the user that created theoriginal workflow request301 that was sent to the first user, while thesender1202 is the first user who received theworkflow request301 from therequester1212. The first user can forward theworkflow request301 to the second user for performance of the task, or in other words the first user can delegate the task to the second user. Thecommunication selection1204 can display therequester1212 so that in the event that the second user attempts to open acommunication session302, the second user can communicate directly with the originator of the workflow request, namely therequester1212, and not the first user who only delegated the task to the second user.
Thetask management system200 can use contextual information, such as information about therequester1212, thesender1202, other parties, and other information, to determine therequester1212 that is to be displayed with thecommunication selection1204. For example, if theoriginal requester1212 is unavailable,task management system200 can change therequester1212 to another user, supervisor, or help system that can assist the second user. In this way, thetask management200 can improve the user experience for the second user by displaying contextually relevant information and useful selection options to the second user.
Referring now also toFIG. 13, ascreenshot1300 of theacknowledgement options1302 is presented. The second user can select the acceptselection1304, thedecline selection1306, or by pressing theback selection1308 the second user can defer acceptance of theworkflow request301. If the user selects the acceptselection1304, the task associated with theworkflow request301 can be marked as in progress. The task associated with theworkflow request301 can be prioritized as described above, which can change the order in which the task is displayed in the second user'stask queue1102. If the user selects thedecline selection1306, theworkflow request301 can be removed from the second user'stask queue1102. In various configurations, theworkflow request301 can be placed into the second user'stask queue1102, when it is received prior to the acceptselection1304 ordecline selection1306 and then removed if the second user selects thedecline selection1306, or the task can be placed in the second user'stask queue1102 only once the acceptselection1304 has been selected.
Referring back toFIG. 3, at point C in thefirst example operation310, the secondmobile computing system208 can send aresponse303 to theworkflow request301. Theresponse303 can be based at least in part on the selection made by the second user, and can be for example, an acceptance ofworkflow request301, a rejection of theworkflow request301, and a deferring of an acceptance of theworkflow request301, among other suitable responses. Theresponse303 can be sent to theworkflow server210 and forwarded to the firstmobile computing device206 by theworkflow server210.
Continuing to refer toFIG. 3, at point B in the timeline of thefirst example operation310, either of the first user or the second user can initiate a dialog with the other user by opening acommunication session302. For ease of explanation, point B and thecommunication session302 are illustrated as occurring after theworkflow request301 has been sent to the second user at point A but before theresponse303 at point C has been sent. However thecommunication session302 can also be initiated prior to sending theworkflow request301, included in theworkflow request301, or initiated after the second user sends theresponse303 to theworkflow request301.
Thecommunication session302 can be initiated by either party, and once thecommunication session302 is open, thecommunication session302 can comprise one or more messages sent by either party. In a configuration, text interactions and messaging can be supported natively by thetask management system200, while phone calls and other communications are initiated externally by placing calls through a call server (not shown). Also, thecommunication session302 can be multi-modal and use one or more mediums, for example a text message, a multimedia message, an email message, a push-to-talk type communication session, a voice call, a video call, and a conference call. Thecommunication session302 can also be performed through an interactivevoice response system216 or using a web-based session based on, for example, a uniform resource locator, as appropriate. Thecommunication session302 can be a real-time simultaneous dialog, such as a two party voice call, a push-to-talk type communication, or a messaging type communication such as SMS or email. Some types ofcommunication sessions302, such as voice calls, have explicit steps of setting up a communications pathway or bearer channel, connecting the parties to that channel for the duration of the call, and then an explicit tearing down of the channel. Other types of communication do not require explicit set up and tear down steps, but can be used as needed.
By the term “open a communication session”, Applicants intend the term to mean initiating an application layer use of a type of communication that permits one or both parties to communicate voice, messages, and/or data, as appropriate for the type of communication, to one another. In some instances, the communication pathway or channel exists prior to the opening of thecommunication session302 and can be used by thetask management system200 as needed without setting up a separate communications pathway. For example, thetask management system200 can include a message handling module in theworkflow server210. In other instances, opening a communication session requires that a communications pathway or bearer channel be set up for thecommunication session302 and then torn down at the conclusion of thecommunication session302. For the purposes of this disclosure, the term opening acommunication session302 generally refers to a use of a communication protocol at the application layer, as opposed to the presentation layer, session layer, transport layer, data communication layer, network layer, data link layer, or physical layer of the seven layer Open Systems Interconnection (OSI) model. In some configurations, thetask management system200 can be implemented so as to use aspects of one or more of the layers. In some instances, thetask management system200 can be tightly integrated with the type of communications, for example by providing the messaging system for passing text messages. In other instances, thetask management system200 can make system level or application level calls to an external system, or to applications or functions, to open thecommunication session302 between one or more parties. For example, voice calls can be handled by initiating the appropriate system level calls to themobile computing device206,208.
Referring back to thescreenshot1200 inFIG. 12, the second user can select thecommunication selection1204 to open acommunication session302 with the first user. Thecommunication type icon1210 displays the default type of communication and communication medium. As illustrated for the example inscreenshot1200 the default communications type can be instant messaging. Thesender1202 can specify the type of communication or allow thetask management system200 to set the default type of communication. For example, if the first user used a template to create theworkflow request301, then the default communication type can be the communication type set in the template. Theworkflow server210 of thetask management system200 can apply a business policy or regulatory policy to change the communication type. For example, for regulatory purposes, some types ofworkflow requests301 may require a voice communication between the parties. An example of this can be aworkflow request301 from a medical doctor or medical professional that, for purposes of insurance coverage and regulatory compliance, requires the recipient of theworkflow request301 to verbally confirm the task instructions with the medical professional.
The second user can select thecommunication selection1204 to make the secondmobile computing device208 open acommunication session302,308 with therequester1212, who can be, for example, the first user. Referring also now toFIG. 16, ascreenshot1600 of a dialog between a first user and a second user is displayed. The first user, in theworkflow request301, included amessage510 asking the second user if they could “witness meds”. The second user can send areply1602 to themessage510 of the first user using thecommunication session302. For example, in thereply1602 the second user can negotiate a time for starting performance of the task in theworkflow request301 by typing thereply1602 into thetext input box1604 and selecting thesend selection1606. The second user can return to the display shown inscreenshot1200 without sending areply1602 by selecting theback selection1610. The second user can send apredetermined phrase1702 by selecting thephrases selection1608.
Referring also toFIG. 17, ascreenshot1700 ofpredetermined phrases1702 is presented. Thepredetermined phrases1702 can be preconfigured based on theworkflow request301. Thepredetermined phrases1702 can be based onprevious replies1602. The second user can select theback selection1704 to return to the dialog between the first user and the second user shown inscreenshot1600. The user can select one of thepredetermined phrases1702 to have the text of thatpredetermined phrase1702 placed into thetext input box1604. For example, if the second user selects thepredetermined phrase1702 “Can you give me 5 mins?” as the selectedphrase1706, then the text of the selectedphrase1706 is placed into thetext input box1604 as illustrated in the screenshot ofFIG. 18 and as described in the accompanying detailed description below.
In a configuration, thecommunication session302 can be preconfigured as astructured communication session302. After each message sent or received by a user, thepredetermined phrases1702 can be reconfigured based on factors such as the previously selectedpreconfigured phrase1702, a received text or a receivedpreconfigured phrase1702 from the other user, an acceptance of theworkflow301, a rejection of theworkflow301, and a performance of a task associated with theworkflow request301, among other factors. The structuredcommunication session302 is an example of a response-sequence ordered set of messages. Astructured communication302 can be preconfigured by an administrator of thetask management system200 to facilitate the flow of the issuance ofworkflow requests301, the acceptance ofworkflow requests301, the messages sent incommunication sessions302, and the performance of tasks associated with theworkflow request301, among other operations. Thepredetermined phrases1702 can be selected by thetask management system200 based on phrases sent in messages during previous operations and microflows.
Referring also toFIG. 18, ascreenshot1800 of editing text in thetext input box1604 is illustrated. Before selecting thesend selection1606, the second user can perform atext edit1802 of the “Can you give me 5 mins?”phrase1706 in thetext input box1604. For example, the second user can perform atext edit1802 to change “5” minutes to “10” minutes as illustrated in thescreenshot1800.
Theworkflow server210 can log the messages sent between themobile computing devices206,208 using thecommunication session302. In various configurations, theworkflow server210 can save copies of the messages or save information about the communications between themobile computing devices206,208. For example, if text messages are used, theworkflow server210 can save a copy of each text message. Similarly, theworkflow server210 can save copies of audio and video messages, including pictures. For voice and other streaming media, such as a call-basedcommunication session308, theworkflow server210 can be configured to save copies of the communications that pass through theworkflow server210. However, for communications that are performed directly between themobile computing devices206,208, and that do not pass through theworkflow server210, such as voice calls, theworkflow server210 can log information about the call, such as the time of the call and the parties that took part in the call. This log information can be accessed by an administrator using anadministrative computing device214 or by users byviewing logs1902.
Referring now back to thescreenshot1200 ofFIG. 12, the second user can select thelog selection1208 to view information about the messages, communications, and actions associated with theworkflow request301. Referring now also toFIG. 19, ascreenshot1900 of the log window is presented. Thesecond computing device208 can display thelog1902 of the messages, communications, and actions associated with theworkflow request301. The second user can select one of the elements from thelog1902 to view additional details (not shown). Referring now also toFIG. 20, ascreenshot2000 of the sent window is presented. The first user can select the sentselection410 to view workflow requests301 that the first user sent to the second user and other users. By selecting one of the workflow requests301, the first user can view information about theworkflow request301. Referring now also toFIG. 21, ascreenshot2100 of the sent item log is presented. The first user can view information about theworkflow request301 including themessage detail2102 and thelog2104 associated with theworkflow request301.
Continuing to refer toFIG. 3, in asecond example operation320, at point D in the timeline, theworkflow server210 creates a server-generatedworkflow request304 to be performed by the user of the secondmobile computing device208. The second user can select aresponse303 at point C in the timeline and send thatresponse303 back to theworkflow server210. Example server-generatedworkflow requests304 include those generated by recurring timers, for example daily tasks that need to be performed, and those generated by expiration of timers, including those related to tasks that are due or overdue. Theworkflow server210 can send a server-generatedworkflow request304 based on a threshold event, such as an approaching due time.
Another example server-generatedworkflow request304 can be an escalation request associated with aworkflow request301. Thetask management system200 can send the escalation request to members of a group, for example a group of users that perform a similar role or function as the second user. For example, if the second user is a nurse in a hospital, then the escalation request can be sent to other nurses on the same shift to see if one of those nurses is available to perform the task associated with theworkflow request301.
There can also be multiple escalating tiers of escalation requests. If aworkflow request301 is not accepted, or if the task associated with the workflow requests301 is not performed within a threshold amount of time, then theworkflow request301 can be escalated to another user or group, for example a supervisor. If theworkflow request301 is still not accepted, or the task associated with the workflow requests301 is still not performed, then theworkflow request301 can be sent back to the first user, or an alert can be sent back to the first user. Similarly, at any step in the escalation process, alerts and notifications can be sent to the first user, the second user, groups, supervisors, an administrator, and so forth.
The server-generatedworkflow request304 can be bidirectional, requiring the second user to send thatresponse303 back to theworkflow server210. Theworkflow server210 can send a server-generatedworkflow request304 that presents an alert1402 to the second user based on a triggering event. A trigger can be caused by an external event, such as a sensor reading. The server-generatedworkflow request304 can be a message or notification that triggers an alert1402 by changing the urgency orimportance508 of aworkflow request301. Referring now toFIG. 14, ascreenshot1400 of an alert1402 is presented. Theworkflow server210 can send the alert1402 to secondmobile computing device208 that can be presented to the user on the display of the secondmobile computing device208. In various configurations, the alert1402 can be generated different ways, for example by a timer in the secondmobile computing device208, by a signal received from a sensor, by a reprioritization of a task orworkflow301 by the first user or theworkflow server210, and so forth.
Referring again back toFIG. 3, the server-generatedworkflow request304 can also be a unidirectional request that does not require aresponse303 from the second user. For example, if the second user has not responded to aworkflow request301, the server-generatedworkflow request304 can rescind theworkflow request301 and remove it from theworkflow queue1102 of the second user. The server-generatedworkflow request304 can also remove a task from theworkflow queue1102 of the second user. These operations can be performed, for example, to assign the task to a second user. After rescinding theworkflow request301 or removing the task from the user'sworkflow queue1102, theworkflow server210 can send theworkflow request301 to another user.
The server-generatedworkflow request304 can also place tasks directly into theworkflow queue1102 of the second user, without sending arequest301,304 and then waiting for the second user to review and send aresponse303. This can reduce the number ofrequests301,304 andresponses303 for mandatory and periodic tasks routinely assigned to, and accepted by, the second user. Similarly, these functions can be performed by a first user under certain conditions. For example, the first user can rescind aworkflow request301 that the first user created, or remove the task associated with theworkflow request301 from the queue of the second user, for example to send the task to another user using aworkflow request301. In a configuration, a first user that has supervisory privileges or administrative privileges can place or remove tasks directly into theworkflow queue1102 of a second user.
Referring back toFIGS. 2 and 3, another example of a server-generatedworkflow request304 is a workflow request that is created by an administrator using anadministrative computing device214. Theadministrative computing device214 can be directly connected to theworkflow server210, or networked to theworkflow server210 across anetwork202,204. In this configuration, the workflow request is a server-generatedworkflow request304 because it is sent directly from theworkflow server210 to a user'smobile computing device206,208. In a configuration, theadministrative computing device214 can also sendworkflow requests301 to theworkflow server210 as described for example byoperation310.
Continuing to refer toFIG. 3, in athird example operation320, at point A in the timeline, the first user of a firstmobile computing device206 creates aworkflow request301 having a task to be performed by a second user of a secondmobile computing device208. Theworkflow request301 is sent to theworkflow server210 to be forwarded to the secondmobile computing device208. At point E in the timeline, theworkflow server210 can create a rule-basedresponse305 for the secondmobile computing device208 that is sent to the firstmobile computing device206. The rule-basedresponse305 can be an acceptance, and a rejection, among other suitable responses. If theworkflow server210 accepts theworkflow request301, theworkflow server210 can add theworkflow request301 or the task associated with theworkflow request301 to theworkflow queue1102 of the secondmobile computing device208. If theworkflow server210 rejects theworkflow request301, both the firstmobile computing device206 and the secondmobile computing device208 can receive a notification of the rejection. The basis for the determination of whether to accept or reject theworkflow request301 can be based on contextual information available to theworkflow server210 and the application of a rule. An example of a rule is to reject aworkflow request301 if the second user is currently busy performing a task and has aworkflow queue1102 filled with tasks that would prevent the second user from performing theworkflow request301 by the required time. Rules can be created by an administrator using theadministrative computing device214 and configured to be applied in a desired order.
In an example, the secondmobile computing device208 can be powered off, out of range for accepting communications, or can be logged out of thetask management system200. The second user of the secondmobile computing device208 can also alert thetask management system200 that the user is currently busy, for example if the user is performing a task or has set their status to busy or unavailable. This status setting, or availability setting, permits the second user to set their current availability for receivingworkflow requests301, messages, and calls to busy or unavailable. The availability setting of the user can work in conjunction with the urgency orimportance508 setting to permit the task management system to use context specific rules and information about the workflow requests301, messages and calls to determine whether to allow incoming workflow requests301, messages, and calls to interrupt the second user. For example, if the second user has set their secondmobile computing device208 to busy, so as to not receive further workflow requests, messages, and calls, theworkflow server210, secondmobile computing device208, or another portion of thetask management system200 can use a rule to determine whether to override the availability setting set by the user. For example, this rule can be based at least in part on contextual information about the reason the first user is busy, as well as the urgency orimportance508 and type of workflow request, message, or call.
In an example, if the first user is a hospital professional and has their availability set to busy during a consultation with a patient so as to not be interrupted, then a rule may allow aworkflow request301 that includes code blue emergency and that has an urgency orimportance508 of a high enough level to override the busy availability setting of the first user and alert the first user to theworkflow request301. In another example, during performance of a task from the second user'sworkflow queue1102, a rule can temporarily set the availability status of the second user to busy, depending on the task, in order to minimize interruptions during performance of the task. By providing contextual information about the task being performed and applying that information to incoming communications using configurable rules, an administrator can configure the communication aspects and task management aspects of thetask management system200 to match the needs of the workplace, without burdening the users with multiple screens of individual configurations.
Referring now toFIG. 15, ascreenshot1500 ofcurrent status options1502,1504 for the user's availability setting is presented. The second user of the secondmobile computing device208 can select thelogout selection1502 to log out of thetask management system200. The second user can also select thebusy selection1504 to send an indication to thetask management system200 that the user is currently unavailable. Selecting thebusy selection1504 can also change color presented in thestatus window1112 as described in the detailed description accompanyingFIG. 11. Thetask management system200 can use contextual information to determine the current status of the second user and use that information to make a determination about whether to accept or reject anew workflow request301 for the second user. Thetask management system200 can also use contextual information to determine whether to instead forward thenew workflow request301 to the second user for a decision. Thetask management system200 can delay sending theworkflow request301, based on a rule, to avoid interrupting the second user during the performance of a task. In this instance, thetask management system200 can delay sending theworkflow request301 until the second user has updated their status to available. In an example, thetask management system200 can use information about a previous performance of a particular task in determining how long on average the second user will be busy with the current task. Then, based on that average time, a rule can be applied to determine whether to respond to theworkflow request301 for the user, or wait for the second user to make the decision whether or not to accept theworkflow request301.
In another example, if the second user just accepted a workflow request that is of a time sensitive or urgent nature, for example if the second user is a hospital professional responding to a code blue, then thetask management system200 can apply a rule to reject or accept new incoming workflow requests301 without interrupting the second user. An example rule can be to accept, or delay sending, a server-generatedworkflow request304 for a daily operation that is not time sensitive, and that is normally accepted by the second user, when the second user is currently busy responding to aworkflow request301 having animportance508 of very important or an urgency that indicates immediate action is required. For example, if the second user is responding to a codeblue workflow request301, then theworkflow server210 can either accept the server-generatedworkflow request304 or delay sending the server-generatedworkflow request304. In another example, if aworkflow request301 that is time sensitive is received by theworkflow server210 and addressed to the same second user in the previous example, theworkflow server210 can apply a rule to reject theworkflow request301 on behalf of the second user when the contextual information available to the task management system indicates that the second user will have insufficient time to perform the task by the desired time.
Theworkflow server210 can also use one or more business policies to determine whether to accept, reject, or reassign workflow requests301. For example, if the second user has aworkflow queue1102 having unperformed tasks above a configurable threshold, theworkflow server210 can apply a business rule and send areject response304 for the second user. Also, theworkflow server210 can perform operations to distribute workflow requests equally between members of a group. For example, if the second user is a member of a group that can share assignments, then upon receivingworkflow requests301 addressed to the second user, theworkflow server210 can check the workflow queues of the members of that group and change the recipient of theworkflow request301, if necessary, to distribute work more evenly between members of the group.
Thetask management system200 can use contextual information to improve the user experience of users of themobile communication devices206,208 in multiple ways. In an example similar to the one presented above, thetask management system200 can apply a rule and respond toworkflow requests301 for users when appropriate. This not only reduces the number of key presses or selections that the users would otherwise have to make, but it also speeds up the process of the assignment of, and ultimately the performance of, workflow requests301. When a first user sends aworkflow request301 to a second user who is busy or unavailable, permitting theworkflow server210 to make a rule-based response with a decline notification quickly alerts the first user that the second user is busy or unavailable. This information about the status of the second user permits the first user to immediately send theworkflow request301 to a different user. Without the response provided by theworkflow server210, the first user could have to wait for a period of time for aresponse303 from the second user further delaying the possibility of another user performing the task in theworkflow request301 for the first user.
Continuing to refer toFIG. 3, in afourth example operation340 the first user of the firstmobile computing device206 can inquire about the status of aworkflow request301. At point F in the timeline, the first user creates aninquiry306 similar to aworkflow request301. Theinquiry306 can reference aprevious workflow request301. Referring also now toFIG. 22, ascreenshot2200 of an inquiry is presented. Theinquiry306 can include aselectable response action2202, for example to call the first user using a preferred medium for communication, in this case a voice call to thephone number2208 of first user. Theresponse action2202 can include aresponse type icon2206 identifying the type of action and preferred medium. Theinquiry306 can include amessage2204, for example a text message. Themessage2204 can help to later identify the purpose of theresponse action2202 in thelog1208. If theresponse action2202 is a call, and if the contents of the call are not recorded by thetask management system200, then themessage2204 can be a good way of providing information for identifying the purpose of the call at a later point in time. Themessage2204 also provides the second user with an indication of the kind of information the first user expects to receive by way of theresponse action2202, thereby allowing the second user to prepare or retrieve the necessary information.
The second user receives theinquiry306 in similar fashion to aworkflow request301 as described above. The second user is presented withacknowledgement options2302 appropriate for sending aresponse307 to theinquiry306. Referring now toFIG. 23, ascreenshot2300 ofselectable acknowledgement options2302 is presented. Theacknowledgement options2302 can include, for example, adecline selection2304, a deferaction selection2306, and aperform action selection2308. Thetask management system200 can use theresponse action2202 of theinquiry306 inFIG. 22 to change the text of the deferaction selection2306 and theperform action selection2308. These context-based changes to the deferaction selection2306 and theperform action selection2308 present the second user with a more user friendly and informative display. Aback selection2310 permits the second user to return to the screen displaying theinquiry306 shown inscreenshot2200. A back selection on thetop bar2312 returns the second user to the display of the user'stask queue1102.
Continuing to refer toFIG. 3, in afifth example operation350, at point H in the timeline, one of the users can open acommunication session308 with another user, for example to discuss a task prior to commencing performance of the task, during performance of the task, or after performance of the task. Thecommunication session308 can be in response to theinquiry306 presented inFIGS. 22 and 23 and the accompanying detailed description. Thecommunication session308 can be in addition to aninquiry306, or thecommunication session308 can be in place of theinquiry306. Thecommunication session308 can be similar to thecommunication session302. For purposes of illustration only, thecommunication session302 is displayed as one or more messages, for example text messages, that pass through theworkflow server210; thecommunication session308 is displayed as a voice call between the firstmobile computing device206 and the secondmobile computing device208 that does not traverse or pass through theworkflow server210.Communication sessions302,308 are illustrated this way for purposes of illustration only. In various configurations, either or bothcommunication sessions302,308 can be message-based such as text-based messaging, or voice-based such as POTS (Plain Old Telephone Service), cellular, WiFI, or VoIP-based (Voice over Internet Protocol), or combinations thereof. In various configurations, thecommunication sessions302,308 can be point-to-point or traverse theworkflow server210, independent of whether they are text-based or voice-based communications.
Referring now toFIG. 24, ascreenshot2400 of apopup list2402 for opening acommunication session308 is presented. In this example, the second user selects aworkflow request301 and then selects the initiatecommunications icon2404 for thatworkflow request301. Thetask management system200 uses contextual information to populate thepopup list2402 with selectable options for opening thecommunication session308. In this case, thepopup list2402 includes options for opening acommunication session308 to discuss the task in theworkflow request301 based on the communication mediums supported by both the first user and second user. The second user can select the discusstask selection2406 using messaging, or the discusstask selection2408 using a voice call. Each of the discusstasks selections2406,2408 include acommunication type icon2410 that indicates the type of medium used in the displayed discusstasks selections2406,2408. The second user can select theback selection2412 to avoid opening acommunication session308.
In a configuration, thepopup list2402 can exclude display task selections for particular communication mediums using rules based on business policies or regulatory rules. Thepopup list2402 can further exclude communication mediums based on the availability of the first user using a particular communication medium. For example, if the first user is currently on a voice call, the discusstasks selection2408 using a voice call can be disabled nor not displayed. In a configuration, an icon or other identifier such as color or symbol can be used to identify the status of a communication medium for the first user, but allow a second user to call the first user even when the first user is currently on another call.
Continuing to refer toFIG. 3, in asixth example operation360, at point I in the timeline, the second user can send astatus message309 to the first user. Anexample status message309 is a message that indicates that the second user has commenced performance of a task associated with aworkflow request301. Referring now toFIG. 25, ascreenshot2500 of a task is presented. The second user can select astatus update selection2502. Thetask management system200 can display contextually relevant options for thestatus update selection2502. For example, if performance of a task has not been commenced, then thestatus update selection2502 can be “starting task” or “starting process” as illustrated. The text displayed can be based on the type ofworkflow request301. Other types of status updates are also possible.
Astatus message309 can provide an indication that a single task of a multi-task workflow request or microflow is complete. Asingle workflow request301 can comprise multiple individual steps, tasks, or operations. The steps, tasks, or operations can involve other users. The steps or operations can create new tasks or new workflow requests301 for the second user or other users. The steps or operations can be cascaded, where the completion of one task spawns anothernew workflow request301. The steps or operations can be nested, where during the performance of a task anew workflow request301 is generated and completed before performance is completed for thecurrent workflow request301. At each step or operation, the available contextually relevant options that are displayed for the second user can change based, for example, on the previously performed tasks, complete workflows, or messages to other users.
Continuing to refer toFIGS. 3 and 25, in aseventh example operation370, at point J in the timeline, the second user can send acompletion status message311 to the first user. An examplecompletion status message311 is a message that indicates that the second user has completed performance of a task or the tasks associated with aworkflow request301. Another examplecompletion status message311 is a message that indicates that the second user has not completed performance of the task associated with theworkflow request301. For example, the second user may not have had time to complete the task, the task may be impossible to complete or no longer necessary to complete, the task may have been assigned or delegated to another user, for example if a shift change occurred, or can be another suitablecompletion status message311.
Referring again toFIG. 25, the second user can selectcompletion update selection2504 to display a list ofcompletion option selections2602. Referring also now toFIG. 26, ascreenshot2600 of a list ofcompletion option selections2602 is presented. The selectablecompletion option selections2602 can include a doneselection2606 to indicate that the task associated with theworkflow request301 has been performed and completed successfully, and a cannot assistselection2604 to indicate that the second user can no longer assist in performance of the task associated with theworkflow request301. Aback selection2610 permits the second user to return to the task screen without selecting acompletion option selection2602. Anoptional note box2608 permits the second user to explain the reasons for not completing the task or to provide additional information to the first user. Referring also now toFIG. 27, ascreenshot2700 of a list ofpredetermined completion phrases2702 is presented. Thepredetermined completion phrases2702 permits the second user to select commonly used explanations that are inserted into theoptional note box2608. Thepredetermined completion phrases2702 can be edited once they are in theoptional note box2608. The second user can save the current text in theoptional note box2608 as a new predetermined completion phrase.
Referring again toFIG. 3, at point K in the timeline of theseventh example operation370, theworkflow server210 can send one ormore completion messages312 to the first user and the second user. Thecompletion messages312 can, for example, remove theworkflow request301 from the user'stask queue1102 among other suitable operations. Thecompletion messages312 can also place log information in thelog1208 of each of themobile computing devices206,208. Thecompletion messages312 can also request copies of messages and other log information from each of themobile computing devices206,208.
Theworkflow server210 can send one ormore completion messages312 based on contextual information available to theworkflow server210. For example, if aworkflow request301 was created to reset a malfunctioning air exchanger, and theworkflow server210 receives information from a sensor that the air exchanger is back online, then theworkflow server210 can determine that the task associated with theworkflow request301 has been completed and send one ormore completion messages312 to the appropriate user. Theworkflow server210 can also request a confirmation from the technician, for example by sending aninquiry306 as described forfourth example operation340, prior to marking the task as completed and sending thecompletion message312. By using this available contextual information, the task management system can reduce the number of unnecessary escalations where the user has simply failed to report that the task associated with theworkflow request301 has been completed.
Referring now toFIG. 28, ascreenshot2800 of an exemplary tasktemplate editing module2802 is presented. The tasktemplate editing module2802 permits a system administrator at theadministrative computing device214 to create thepreconfigured workflow requests408 illustrated inFIG. 4 and described in the accompanying detailed description. The system administrator can determine which fields are usereditable fields2804 and preconfigure the default semantics, text, and icons that are to be displayed with theworkflow request301 and tasks. The system administrator can publish the preconfiguredworkflow requests408 to specific groups. Thetask management system200 can update the preconfiguredworkflow requests408 available to each contact based on whether they are a member of the specific groups.
The system administrator can use the preconfiguredworkflow requests408 to control the amount of input the users have in creating workflow requests301. For example, the system administrator can create highly structuredworkflow requests408 that facilitate entry of information by the users. An example is a preconfiguredworkflow request408 for cleaning a room in a hospital setting. Thepreconfigured workflow requests408 can have aworkflow name502 of clean patient room, and have adefault importance508 of normal. The system administrator can require an information element such as the room number and the cleaning type, along with selectable entries that include the list of room numbers at the hospital or section of the hospital, and cleaning types such as standard clean, disinfection, disinfections with fluorescent marking test, and so forth. These lists of entries can be used to both limit entry of information by the users and also to facilitate easy quick selection of commonly used selections. The preconfiguredworkflow request408 can include optional information elements such as amessage510 box that allows the user to enter comments about the task.
Themessage510 box can use embedded data elements that can be populated using contextual information to facilitate user selections, such as the room number, type of clean, etc. For example, a field in themessage510 can be: [room number]. This makes it possible for the user to double tap the field to select it and overwrite with the real data, for example the list of rooms associated with the field [room number]. More structured message creation process are also possible where the message is selected from a list of options and then any parameters are collected enabling the message field to be auto assembled
The system administrator can set the available responses for acknowledgments or responses, such as acknowledged, accept, defer acceptance, accept with action, and cannot comply among other suitable responses. The defer acceptance selection permits the users to asynchronously negotiate a response time for accepting or rejecting theworkflow request301. For example, the first user would receive a message that the second user has received and reviewed theworkflow request301 but not responded with an accept or reject selection. The system administrator can configure thepreconfigured workflow requests408 so that the second user can respond with theirown response303. Once a user has accepted theworkflow request301, the user can be presented with two new response options, for example “task started” and “cannot complete”. After the user has started the task, the user can be presented with two completion options, “task completed” and “cannot complete”. The text options can be configured by the system administrator to tailor thetask management system200 to their organization's requirements.
The responses can include implicit actions, such as an accept response to aworkflow request301 to join a conference call can place the user into the conference call and mark the user's status as busy for the duration of the call. When the user exits the conference call, theworkflow request301 can be completed and acompletion status message311 can be sent to theworkflow server210 and the first user that sent theworkflow request301.
The system administrator can also provide general, unstructured preconfigured workflow requests408. Unstructured messages can include free form text and digits of fixed or dynamic length, with similar structured elements to the structured preconfigured workflow requests. The system administrator can embed unstructured messages as a component of a task associated with the workflow request, for example to facilitate coordination ofcommunication sessions302,308 and permit the users to open thecommunication sessions302,308. The system administrator can also configure what kind of information is logged for the preconfigured workflow requests408, for example logging exact copies of text messages communicated between the users, logging voice call times and the parties involved in thecommunication session302,308, and so forth.
Preconfigured workflow requests408 can be distributed to users based on groups, permitting the system administrator to, for example, allow supervisors to use both structured and unstructured preconfigured workflow requests408, while allowing regular users to use only the structured preconfigured workflow requests408. The group feature allows an organization's tasks to be filtered so that users only see tasks of interest rather than having a long list of tasks and having to search for relevant ones.
Referring now toFIG. 29, ascreenshot2900 of aworkflow analysis module2902 is presented. Theworkflow analysis module2902 permits a system administrator at theadministrative computing device214 to review current workflows being performed, and workflows that have been completed, as well as the status of workflow requests301. The system administrator can perform actions such as escalation ofworkflow requests301, reassignment ofworkflow requests301, and so forth.
By logging and reporting information about tasks, workflows, and communications, the system administrator can be presented with detailed information about the various tasks being performed by users and use that information to improve processes and efficiency. The logs can include summary information about each of the alerts, events, communication sessions between parties, voice calls, text messages, workflow requests301, acknowledgements, tasks, delegated tasks, and escalated tasks, among other information. The logs can include information captured from communication sessions, such as the text content of text messages. The log3100 can be an XML-based log. An example log is presented in Table1.
| TABLE 1 |
|
| <?xml version=“1.0” encoding=“UTF-8”?> |
| -<TaskHistory> |
| <TaskId>2651</TaskId> |
| <Title>msgSubject</Title> |
| <TaskType>MultiChoice_01</TaskType> |
| <TaskTemplatedId>25672570883F8CE92042E17D34E94728F4632FAE</TaskT |
| emplatedId> |
| <CompletionStatus>NOT_SET</CompletionStatus> |
| <TaskOverdue>FALSE</TaskOverdue> |
| <RequesterId>Connexall</RequesterId> |
| <ResponderId>samira</ResponderId> |
| <DueBy>2012-02-02 04:58:16</DueBy> |
| <Importance>0</Importance> |
| <Message>testNotif</Message> |
| <CallDestination>sip://1234567</CallDestination> |
| <StartTime>2012-02-01 23:57:16.718</StartTime> |
| <TerminatedOn>2012-02-01 20:02:50.524</TerminatedOn> |
| <TaskId>2744</TaskId> |
| <Title>msgSubject</Title> |
| <TaskType>PhoneTask_01</TaskType> |
| <TaskTemplatedId>25672570883F8CE92042E17D34E94728F4632FAE</TaskT |
| emplatedId> <CompletionStatus>COMPLETED_FAILURE</CompletionStatus> |
| <TaskOverdue>TRUE</TaskOverdue> |
| <RequesterId>Connexall</RequesterId> |
| <ResponderId>samira</ResponderId> |
| <DueBy>2012-02-02 06:29:15</DueBy> |
| <Importance>0</Importance> |
| <Message>testNotif</Message> |
| <CallDestination>sip://1234567</CallDestination> |
| <StartTime>2012-02-02 01:28:15.687</StartTime> |
| <EndTime>2012-02-02 09:50:14.342</EndTime> |
| <TerminatedOn>2012-02-02 09:50:14.342</TerminatedOn> |
| -<ActionLogs> |
| <timestamp>2012-02-02 01:28:24.281</timestamp> |
| <message>READ</message> |
| <originator>P</originator> |
The system administrator can search and sort log information using thesearch filter2904 function. A display ofsearch results2906 can display the log information. The results can be exported using theexport selection2908, for example to a comma delimited file. The system administrator can perform analysis of selected tasks and workflows. The system administrator can evaluate information from logs captured by theworkflow server210 and themobile computing devices206,208. Each of themobile computing device206,208 and theworkflow server210, or any other suitable element of thetask management system200 can capture a log of events as they occur. Events can include, among other things, each workflow request, acceptance, rejection, deferred acceptance, inquiry, text message, notification, alert, escalation, and delegation of a task, collectively messages, and can include time stamps. The events can also include information regarding the status of performance, such as the commencement of performance, or the completion of a task, collectively the performance of the task. Information regarding the performance of the task can be based on information received from the second user, or can be information received from an external device, such as a sensor or another computing system, and can include a time stamp. Generally, as each event occurs, a time stamp associated with each of the events can be captured. Thetask management system200 can log all events associated with each task, workflows, and communications with time stamps for later review.
Referring now toFIG. 30, a method of analyzing workflows is presented. Processing starts atstart block3000. Processing continues to processblock3002. Atprocess block3002, logs of events, data such as message contents, and timestamps are collected. Processing continues to processblock3004. Atprocess block3004, the system administrator selects the workflow or microflow to be analyzed. The system administrator can select for example, an individual task associated with a microflow, all events of a microflow, or ranges of workflows. For example, the system administrator can select events based on the type of task, a user, a period of time, or a combination of parameters. Processing continues to processblock3006. Inprocess block3004, the system administrator can further choose a characteristic to be measured. For example, the characteristic can be tasks that have not been completed, among other characteristics. Processing continues toprocessing block3008.
Inprocess block3008, the system administrator can perform analysis of the selected data, for example by computing metrics of the characteristics, comparing those metrics with other metrics, and comparing metrics to data. Analytic tools can be applied to analyze the information and develop metrics about the performance of tasks, aspects of communications and collaboration, and individual's performances. The analysis and metrics can be used to analyze business processes and create improvements. For example, the comparison can be compared a metric related to tasks that have not been completed for a particular type of task, with the same metric for all types of tasks to see if the selected task is, on average, less frequently completed than other types of tasks. The analysis can include both real-time analysis (e.g., for creating alerts or performing workload management) and post-processing aspects (e.g., for evaluations or compliance).
Processing continues to processblock3010. Inprocess block3010, the results can be displayed on a display screen to the system administrator, or exported to a file or report. Processing then ends atend block3012. Visualization tools can be applied to display the information, logs, and metrics. For example, the results can be displayed as text information, or graphical presentations such as charts, histograms, and other graphical presentations can be used. Views of the logs, metrics, and analyzed data can be sorted by task, by type ofworkflow request301, by user, and by metric among other views. The system administrator can use views of the logs to highlight and identify areas of issues, for example tasks that are past due, users with too many tasks or outstanding workflow requests, users who have acceptedworkflow requests301 and then abandoned the tasks, types of tasks that are typically performed later than requested, users that are not completing tasks on time, and so forth. The system administrator can view the logs in real time or substantially real time.
The system administrator can process the log information to ensure compliance with personnel, corporate, or regulatory objectives. For example, personnel compliance can include workload management and performance evaluations. Corporate compliance can include business efficiency evaluations or compliance with internal procedures. At a system level, the system administrator can process the log information to see the amount of collaboration between and within departments and analyze the degree of organizational communication. The system administrator can check to see if confidentiality screens are being complied with or if inter disciplinary consultations on large projects are being performed as intended. Regulatory compliance can include evaluation performance of workflows to ensure that federal, state, and local regulations are being met. The logs can be used as evidence during certification or for insurance purposes.
The system administrator can also analyze the patterns of communication between parties to determine social networking patterns, for example to analyze interdepartmental and intradepartmental collaboration and individual roles within groups. For example, the system administrator can develop metrics that show the type of communications used and the frequency of communications to determine whether the types of messages in preconfigured workflow requests are sufficient or whether users typically need to fall back to person-to-person voice calls. The system administrator can also develop metrics that show supervisor-to-subordinate communications, for example to show that proper channels are being used for delegating tasks. The system administrator can also develop metrics based on peer-to-peer communications, and communications within groups, for example to show communication patterns typical for certain tasks or users.
The system administrator can analyze the patterns of communications at the level of the microflow, between workflows, or within an aggregation of workflows. This can be used to develop metrics for analyzing an individual's participation level and status, leadership ability, or recognized subject matter expertise or skill level. The system administrator can create a view of a users' work-related social networks by analyzing users' statically defined user group memberships, dynamic roles, and associated group memberships combined with their history of communications, favorites (e.g., other users), and task/message interactions. The analysis can include the type, frequency, and characteristics of the interactions to develop metrics concerning how often a user communicates with other users, which users commonly interact with one another, correlations of individuals to their group membership, and so forth. The analysis can be an aggregated social network view, a view based on workflow type or task type, a view based on an individual, or another suitable kind of view. The system administrator can analyze the metrics over a period of time, for example to perform trend analysis to view how metrics or data are changing over time. The metrics and data can be combined or correlated with other business data.
Example analyses and metrics include, but are not limited to, analysis and metrics relating to subject matter expertise, task distribution, task completion rates, staffing issues, and usefulness of preconfigured tasks. With regards to subject matter expertise, the analysis can enable the system administrator to determine which users are contacted the most often by other users during the performance of tasks or in general. For example, the analysis can provide information about which users have skill expertise recognized by other users, and which users are the kinds of users that are relied on for information versus which users are identified as dependable performers of tasks. The analysis of both kinds of users can provide the administrator with information for determining the proper combination of users to meet their organization's staffing requirements. The analysis can also identify those users that perform key mentorship roles within an organization, have strong leadership skills, or frequently provide assistance to other users. With regards to task distribution and staffing issues, the metrics and data can determine the distribution of tasks completed by users in a particular time period, and provide information about the mean, median, high, low, or other statistically useful variable. This can help the system administrator understand individual strengths or weaknesses, or identify particularly good teams. The system administrator can use the metrics and data to identify potential staffing issues or other inefficiencies that cause performance to fall outside target criteria or thresholds. With regards to task completion rates, the metrics and data can identify tasks that are not completed on time, and allow the system administrator to review communication details to understand potential causes and reasons for unsuccessful completions. The system administrator can also identify tasks that are abandoned or uncompleted to determine the root causation. For example the system administrator can correlate activities with individuals, busy times, shift changes, types of tasks, and so forth to discover problems. The system administrator can use this information to change procedures to improve completion rates.
The system administrator can review and analyze microflows to determine the usefulness of preconfigured workflow requests408,predetermined phrases1702, andpredetermined completion phrases2702 among other aspects of the task management system. For example, the system administrator can review communication sessions and messages to determine those tasks where users resort to fallback communications outside of those provided by the preconfigured workflow requests408,predetermined phrases1702, andpredetermined completion phrases2702. This can provide the system administrator with information about how to make modifications to increase efficiency, for example by adding newpredetermined phrases1702. This allows the system administrator to customize the context-specific aspects of thetask management system200 to increase user efficiency and provide a more useful interface to the users of thetask management system200.
The above descriptions of various components and methods are intended to illustrate specific examples and describe certain ways of implementing atask management system200 as disclosed and described here. These descriptions are neither intended to be nor should be taken as an exhaustive list of the possible ways in which these systems and modules can be made and used. A number of modifications, including substitutions of systems and modules between or among examples and variations among combinations can be made. Those modifications and variations should be apparent to those of ordinary skill in this area after having read this document.