Team Leaders are colleagues who are in charge of teams and work areas. Enate Users set as Team Leaders can can see the work item sitting with the people in their Team (the people who report to them) and in work Queues that they are set as a manager of. They can set the permissions levels for their team members and (in the same way that team members are able) can create work items and manually assign work . They can also see their bot farms and which bots are busy, what they’re working on, which bots are idle and which bots are currently offline.
Team Members are colleagues who report to a Team Leader. On their home page they can see work assigned to them and, if set to do so, work items sitting with their peers (people who report to the same Team Leader as they do) and in the Queues that they work out of .
Tickets are used for modelling isolated, ad-hoc queries. Tickets are standalone and are not part of a business process.
Work Items Cases used for modelling a process. Cases are made up of a series of related Actions that are configured into a flow. Cases are most often broken out into multiple high-level 'Steps', each of which contain a flow of Actions.
Actions are the constituent parts of a Case, i.e. a Case is made up of a flow of Actions. Actions are the individual work items within a case flow which can be managed independently. They contains a set of instructions, often a checklist of activities to track progress within the Action. Actions can be manual (can be carried out by humans and bots) or automatic, e.g. auto sending an email. Most often Actions are grouped into a series of high-level 'Steps' within a case flow.
There are three types of Work Item in Enate : Tickets, Cases & Actions. Work items are created from various possible inputs, such as customers mailing in queries, schedules in Enate automatically starting activities, APIs creating externally.
Enate automatically allocates work items into Work Queues depending on how the allocation rules of the Case / Ticket / Action have been defined. Team Leaders set themselves as managers of Queues in order to view the work items contained within, and team members are set to work out of Queues (when they select 'get more work' they are assigned a work item from the Queues they are linked to). Queues are often created to represent skill sets within a specific business area.
The Inbox view on a user's Home page in Work Manager shows you which work items are currently assigned to you (and only to you). If a work item is in your Inbox it is because there is an outstanding activity on you to complete. If the work goes on a pause while waiting for e.g. a client to get back to you, Enate moves the item into your 'Owned Work' view until it's sitting back with you on the outstanding item. This keeps your inbox focussed on items which can and should be completed.
The Owned Work view displays work items for which you are the Owner but not the assignee - in real terms these are items which are your ultimately responsability, but the current activity to be completed isn't with you (it may be sitting on a pause waiting for client to send back information, or waiting for a follow up date). You can still access and work on items found in your Owned Work of you need to.
This shows you all the work items which are currently assigned to your Team.
This shows you all work items that are owned by your Team i.e. Cases started by them, and Cases in states such as Wait for more information, Schedule for follow up, etc.
Work Items are placed into different states as part of dealing with them (e.g. pause, in progress, resolved etc.).
Service Agent dealing with delivering service to your clients, often using Work Manager to do this.
Contacts / Service Recipient
The employees of your client companies, who your company delivers service to via Enate. The details for which people are related to a Ticket, Case or Action are stored in the 'Contacts' card of the work item in Work Manager.
The client end user who is the main point of contact when dealing with a Ticket / Case or Action. Outgoing emails wil default to sending to the primary contact unless otherwise specified.
Person who sent in the original request which case resulted in a Case or Ticket. Not necessarily the ongoing primary contact or Subject.
The person who a work item is about. This is not necessarily the primary contact or the requester if it has been raised on behalf of someone else.
Quickfind allows you to search for People (service recipients r other agents), Work Items (Tickets, Cases & Actions) and Communications (e.g. emails and notes on Work Items).
Enate feature in Work Manager where you can create Cases and Tickets in bulk via the uploading of data from Excel spreadsheets.
The timeline section of a work item shows a chronological view (more recent first) of the activities which have taken place for it, and related items. These can be activities such as emails, internal notes, allocations, status & queue changes etc. You can filter which types of activities you wish to view, and set whether actvity from related items displays or not. There's also a dedicated 'Comms' view of the timeline which displays only incoming/outgoing emails plus any internal notes.
There are two types of notifications which you can receive (described as different 'Groups'). One type is a Packet Activity, which are generated when a work item is assigned to a user (system notifies that user). The second type are Process Messages - these are generated as part of process, e.g. when a peer review Action fails or when an Action is unable to complete.
Brief explanation about each type of them
Its importance on dud date calculations
Normal production environment of Work Manager. Once you set a Case / Ticket process live, it is accessable by Agents running in Live Mode.
Test mode allows you to create and run test work items through test versions of processes to verify them before setting live, all without affecting live production data.
Detailed level to-do list which can be configured for a specific Action, ensuring agents cannot complete the action before having filled in all checks. Checklist items are made from a mixture of standard agreed check ('Global checks') and any locally applied additional checks which may be required for this specific action instance.
Configured for individual actions within a flow in Buider, the General Settings help determine a number of different attributes for the action e.g. standard instructions & operating procedures, how we expect it to take, whether it can be done by RPA (robot) resources, and the underlying skills required for the action.