Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
As part of the upgrades to Unhandles Emails (previously 'Unprocessed Emails'), there's a new icon on the Work Manager homepage that will display if you've any unhandled mails to be dealt with.
This will show the total number of currently unhandled emails and, if you click the link will also show a popup showing how many of these have arrived in the past 24 hours, plus a link to take you straight to the Unhandled emails section of your Email Inbox page.
A brand new feature we've introduced is the ability for Work Manager agent users to create email routing rules as part of dealing with Unhandled (previously 'Unprocessed') emails, and to do this directly within Work Manager - previously this could only be carried out by Admins via Builder. Creating these rules helps stop equivalent future emails from landing as Unhandled emails, ensuring that a Ticket or Case gets created for them. This reduces future Unhandled email volumes and makes sure work can start on these items more quickly. To provide an element of control, the ability of Work Manager users to create new email routes is an option which can be turned off/on in via User Roles in Builder.
Once these rules are created in Work Manager they're instantly live and working, however Admin users in Builder are notified of any new routing rules created in this way, and these remain marked for their attention until the Admin acknowledges them. Admins still have the ability to adjust or even turn off such rules after assessing them.
Feature Access to be able to create new Email Routes in Work Manager is controlled via Enate's User Role system, with a new option being added to the Email View Options section.
Note: This 'Create Email Routes' access will be set to ON for the Standard Team Member role
While dealing with an unhandled email in the Unhandled emails section of the Email Inbox page, if you choose to have the email processed into a Ticket / Case (by clicking 'New Work Item' option), you'll be met with the following popup:
You can search by email route (which will auto-populate the Customer/Contract/Service/Process fields based on suggestions for the mailbox address selected), or can manually select. Clicking Create at this point will create the specific Ticket or Case from the email, as normal.
However, if you also wish to have the same thing happen automatically ongoing, you can click on the 'Apply to other emails' link at the foot of the popup before you hit 'Create'. If you've selected this option, when you hit 'Create' two things will happen:
A small confirmation message shows confirming that a new work item has been created.
A further popup screen to 'Create New Email Routing Rule' is then shown where you can fill in the remaining routing rule details before confirming its creation.
You can decide if the route is going to be a 'To' or 'From' type of route, i.e.
'treat all emails FROM this address in the same way', OR
'Treat all email TO this address in the same way'
and then which email address is to be used in conjunction with this. Enate will automatically fill the email address with the relevant email address associated with the unprocessed email you were working on.
Within the 'Tips' section of this pop-up, there is a link that will take users to the Unhandled Emails page of the Enate online help, should users require any more information.
In addition to setting a rule which will deal with all future emails that match this pattern, you can also choose to have the rule run against all/some of the existing Unhandled emails which match this rule. If you wish this to happen, select the 'Auto-apply' toggle and this foot of this popup.
The system will show you how many of the current backlog of Unhandled emails match this rule, i.e. how many would be reprocessed.
Selecting this option will bring up a time filter allowing you to select a subset of these existing emails to run the rule for (if, for example, you only want to run this for emails up to a week/month old etc.
You can use the slider to set different date ranges, including setting specific dates. As you change this setting, the system will update to reflect how many emails this would run the rule for.
When you're happy with your selection, you can hit Create - the rule will be re-run and emails will start to be re-processed into the type of Case or Ticket you specified.
Important Note: Once you create a new email routing rule in this way via Work manager, it will instantly go live and start to run against any subsequent incoming emails.
If any new email routes have been created in Unhandled Emails in Work Manager, Admin users will be made aware of this in Builder by a red dot on the Email icon section.
Throughout any subsequent navigation sections and screens as they drill down to the Email Routes page, there will be continued signposting down the new Routing rules that they should be aware of.
Once on the Routes page, users will see a banner notifying them of new email routes to be aware of, as well as how many there are. A link will allow them to filter the routes down to just those new ones that they need to be aware of.
Within the routes table itself, users will be alerted to these new routes to be aware of.
Admin users are encouraged to review these new routing rules (and speak to the agent who created them*) to make sure they're happy with how they are running in conjunction with the various other rules. They can choose to unset them from live, make any adjustments and even delete them if they feel necessary.
If they're hapy with the rule they shoud unmark the 'be adjusted, They can use the 'Clear review filter' link in the header to return to the normal view.
*You can view who created an email routing rule from the 'Show Activity' icon in the top of the rule details popup.
Clicking on this will show the audit trail of who created and updated this rule.
In Enate version 24.1, you can now view the unhandled incoming emails which were deleted by you / your team as part of dealing with them. This helps with an auditing how incoming emails which were unhandled have been dealt with.
This view is accessed from the Email Inbox page in Work Manager - once there, expand the email sidebar, and click to expand the 'Unhandled Emails' section. This will display the 'Deletion Audit' folder link.
Clicking on this 'Deletion Audit' link will bring up a view of all deleted unhandled emails within your area of the business. These are incoming unhandled emails where the decision was made to delete these mails rather than create a new Case or Ticket from them.
All filters and paging options are available as for the other email views in this page, but the emails themselves are shown in read-only mode..
Clicking on a deleted unhandled email will display the email in detail in the main section of the screen, with any attachments that it may have had.
Additionally, the header bar above the mail shows who deleted the email and when.
Note: You cannot 'undelete' emails which have been deleted, however if you wish to copy body text information from them you can do this by simply selecting the desired text and copying / Ctrl-C.
In this preview release of Enate v2024.1, we've been hard at work creating some brand new features while also improving on existing ones, so let's take a quick look at what we've been up to…
With the release of Enate AI's latest offering - AI Analyst, wer'e taking a significant step forward to let you seamlessly integrate AI-driven activities throughout your business process.
We're partnering with Microsoft on this to use the power of their very latest OpenAI technology right at the heart of things. So if you can ask OpenAI to perform a task, with EnateAI Analyst you can embed that to run automatically as part of your business process flow.
You can add AI Analyst Actions throughout your cases and ask it to analyse documents which you supply it. You can massively reduce the time spent having to wade through huge data files performing intricate analysis, freeing up time for more valuable work.
The possibilities here are almost endless, and the power you've got at your fingertips is matched only by how simple it is to set up. There's no coding and you don't have to change a thing - just tell the system what the business rules are to run an analysis task and it will get on with it.
An Important point to note regarding AI Analyst is that, for now, it's being released in BETA. As such, you should not use it yet in full production situations. However, you definitely should start to test it out with your real-world scenarios to see just how powerful it is.
Outside of this big AI story, we've been focusing on enhancements to help you better deal with client emails in Work Manager...
We've made a raft of of enhancements to give you more tools to deal with Unprocessed Emails, which we're now going to refer to as 'Unhandled Emails'.
Agent users can now create email routing rules direct in Work Manager, from unhandled emails - letting you fix the issue at source so THAT kind of mail never lands in the unhandled email pile again.
These email routing rules can be run retrospectively to help clear out backlogs of Unhandled emails.
A Bulk Delete option for Unhandled Emails allows you to clear up large volumes of historic emails which are not going to be converted into work items.
New Deletion Audit view lets you see the emails which have been deleted as part of dealing with Unhandled Emails.
New Unhandled Emails Header Icon to give a more prominent awareness of when there are Unhandled Emails to deal with.
Improved Handling of Incoming Reply emails, where someone cc'd on an original mail responds.
New feature to let you create work items direct from existing emails which shouldn't be attached to an existing work item as they're really about a new request.
And one last email item: if your Enate system is running with 'Plus Addressing Only' enabled, your customers will now see a new line of text in the emails you send out, recommending to them the best way for them to respond. Note: If your system isn't running with 'Plus Addressing Only' enabled, this change doesn't impact you.
You can now display custom fields on Users, Customers, Contracts, Services and Service Lines to capture bespoke data via the Extension Properties feature.
Depending on where you have chosen to add your fields, they will show accordingly when a user creates or edits a User, Customer, Contract, Service or a Service Line.
We have added a new feature that enables Work Manager users to provide more accurate estimated efforts for work items, enabling you to plan resource requirements more effectively.
In the long term, this data can be collated and fed back to admin users to adjust estimated effort timers and to provide more accurate forecasting for future work volumes.
As part of this feature, we have also made some enhancements to configuring effort estimates in Builder and to record count
We've created a new Sentiment Analysis Report. With this report you can drilldown into trends on emails arriving into the system and on submitted Feedback - looking at patterns for negative, neutral and positive tone detected in emails sent to you.
We've added a new option to display a link to your company's privacy policy on the login page.
We've added some new optional fields on users, customers and contracts.
We've added a new option in Builder to chose to display Process groups in Work Manager.
You can also check out a detailed list of all these changes and bug fixes in the Release Notes section.
Additional filters have been added to help when when viewing unhandled (unprocessed) emails in Work Manager. Previously users were only able to filter unprocessed emails by Mailbox Name or Mailbox Address. Now Users can combine a date filter with the Mailbox Name or Address in order to provide them with more focused results.
A slider can be used to choose from pre-set date range options, or you can set specific dates from the calendar.
Enate version 2024.1 sees a raft of new features and improvements to Unhandled emails, which have previously been referred to as 'Unprocessed emails'. Part of the reason for the name change is to try to make this clearer that these mails need manual intervention from the Agents in order to progress, rather than there being some technical issue which isn't for them to solve.
Here are some details on the various enhancements which have been made.
A new in your header bar to tell you when you've got unhandled emauls.
Agents are now able to , so future emails don't get held up and instead create the right kind of work items automatically. This can also be made to act retrospectively on existing unhandled mails which match the rule.
A option lets agents more easily deal with large backlogs of Unhandled emails that aren't going to be made ino work items.
A new view lets you see a list of these , for example for auditing purposes
lets agents search based on data ranges in this area.
We have made two enhancements to the way incoming emails are processed:
We've made a change to improve the handling of incoming reply emails, specifically where someone CC'd on a mail sent into enate replies to that email. Previously, that new email would create its own brand new work item in Enate, when really it should auto-attached to the work item already created existing in the system by the initial email. Now, Enate recognizes the situation and will instead attach that mail to the original work item.
The technical specifics of this are as follows: Improved 'InReplyTo' logic has been added for processing incoming mails. We now validate if the 'InReplyTo' field of the incoming email aligns with the Message-ID of a prior email. When matched, the email/communication is appended to the relevant work item, however this is conditional on the email following the same email route. In short: if we can tell that a mail has been sent in reply to a mail we already know about, we direct that new mail to the previous mail's work item.
Additional Note:
If your system is using Traditional/Mixed mode, we verify if the 'InReplyTo' field corresponds to the Message-ID of ANY previously received email, irrespective of being incoming or outgoing.
If your system is running in Exclusive (i.e. Plus Addressing ONLY Mode), we verify if the 'InReplyTo' field corresponds to the Message-ID of previous INCOMING received emails only (not outgoing mails).
Previously, when a user sent an email to a closed child split ticket, the mail would be attached to the parent ticket or to other child work items. This behaviour has now been modified and the system instead creates a new work item for such emails.
With the release of Enate AI's latest offering - AI Analyst, wer'e taking a significant step forward to let you seamlessly integrate AI-driven activities throughout your business process. The initial releases of EnateAI tackled the grind of email management — sorting, classifying, data extraction, and sentiment, then similarly for Documents. With AI Analyst, we're expanding our AI capabilities to navigate through complex service workflows like invoice matching, change of directors, and payment reconciliation. These areas, traditionally bogged down by extensive manual effort, are getting a major efficiency superboost from Analyst, handling a significant portion of the workload with minimal human intervention.
We're partnering with Microsoft on this to use the power of their very latest OpenAI technology right at the heart of things. So if you can ask OpenAI to perform a task, with EnateAI Analyst you can embed that to run automatically as part of your business process flow.
You can add AI Analyst Actions throughout your cases and ask it to analyse documents which you supply it. You can massivley reduce the time spent having to wade through huge data files performing intricate analysis, freing up time for more valuable work.
The possibilities here are almost endless, and the power you've got at your fingertips is matched only by how simple it is to set up. There's no coding and you don't have to change a thing - just tell the system what the business rules are to run an analysis task and it will get on with it.
An important thing to note here: For the moment, this feature is being released in BETA only. As such, it should not be used yet for full production purposes just yet. You can however, start to test it out with real scenarios.
Here's how you can get started setting up AI Analyst to help streamline your activities..
Adding AI Analyst into your business processes is very simple to set up. Once you've switched on the 'AI Analyst' integration in Builder's Marketplace section, any time you want to create a new AI Analyst action to perform a specialist analysis activity, the steps are as follows:
Create a new AI Policy in the AI Analyst Configuration section of System Settings in Builder
Test this policy with sample data until you're happy with the output, then Set Live.
Add 'AI Analyst' actions into your case process, linking this to your new AI Policy. (Note: You will need to add a manual action directly after the AI Analyst action)
Creating a new AI Policy is simple - no code is required, you can simply write out the business rules / logic / policy for the activity in normal business language and the AI will understand it. You can easily get started by simply porting across the details of your business policy direct into an Enate AI Policy.
Take a look at some sample policy prompts to see what a policy might look like..
Go to the Marketplace section of Builder and filter down to 'AI Analyst'. Activate the EnateAI - AI Analyst Integration
Go to the 'AI Analyst Configuration' section of System Settings, and click to 'Create a Policy'. This will display an AI Policy for you to start to fill in with details of the analysis activity you want AI to undertake for you. Remember, you can just write this in normal business terms (see the prompts section for examples of this).
Here is the information you can define when setting up a new AI Policy:
Name - give your Policy a sensible name so it can easily be identified from a list of other Policies, e.g. 'Invoice / Credit Note Reconciliation.
Input File Tags - At runtime your AI will analyse one or more documents as its input. You can test with sample ones while you build, but at runtime you need to tell the system which files to grab. Setting the file Tags here tells the AI 'at runtime, grab the files in the Action which have these tags, and use them as your source for analysing. Examples might be: 'Bank File', 'HR Update', 'State Tax Rules'.
Output File Tag - If your policy instructions ask for output to be provided in a file, you may want to tag that output file too, for easier use by other systems downstream. Example 'AI Reconciled'
AI Persona - For best results when creating a policy with instructions prompts, it's good to give the AI as much context as you can - one important way to do this is to say what kind of person they should act as, e.g. 'Do this analysis activity as if you were a Bank clerk', or an HR executive, or an Accounts Payable expert. You should either define a new person here for your policy, or pick from the existing list if the relevant persona has already been defined.
Instructions for AI - This is where the details of your instructions to the AI will go. This can simply be a copy/paste of your company policy for carrying out the activity, the rules and regulations for what to do, and how you'd like to receive the output.
AI Creativity Level - This will produce subtly different output depending on the setting. you can choose to have a play around wither depending on what type of analysis you're asking for here. It defaults to a 'balanced' setting, but there's options to make the responses more creative or more precision-focused.
A well-defined persona for your AI Analyst activity helps the AI do a better job when analysing and returning data to you. If the persona you're looking for isn't in the list to choose from, you should define one for this policy. At runtime, the AI will use this as input along with the more detailed instructions when determining what to do.
Here's whether the main part of the input instructions to the AI get defined. Remember you don't need to be writing this as code, in fact it works much more effectively if you don't. If you've got existing rules and regulations which define that task, paste them in here and test your output.
When you're writing instructions that involve heavy reference of e.g. Excel sheet columns, you'll obviously have to write something adequately detailed and precise which refers to them accurately, a good guide is still to write it in a way that you would be explaining it to someone you wanted to carry out the activity (example as below shows detailed column references but then a more human "it won't be a perfect match but it should appear in there somewhere".
Be clear about exactly what you want the AI to do, and how you'd like to receive your output. For examples and notes on how to write good AI prompts for activities such as this, check out this section.
While there are no fixed rules on how you format your instructions, if you want to make explicit reference to any of your Input documents, you can do so using a {{FileTag:NAME}} format. For example if you're created a tag called 'Bank', you can refer to this document in your instructions as {{FileTag:Bank}}
For more information and samples on how to write instructions, check out the link below:
Once you're happy with all your policy input settings, the next step is to test it.
You'll be asked to upload a sample document for each input filetag you've specified. Once you've uploaded these you can run your test. Depending on the size of files or complexity of the prompt you've written, this could take a few minutes before you get one, but once you do, you can analyse the results.
If you've requested the output in a certain file format you should see that file as part of your output, otherwise you'll see text response from the AI. If the results show that some tweaking might be needed, you can go back to your policy settings, make some adjustments and test again. Once you're happy though, you can set the policy Live.
Once you've set your new AI policy Live, all you need to do now is add an AI Analyst action into your case flow.
As part of the configuration, set your new AI Policy as the one which this action should use.
Additional Requirement: When adding an AI Analyst Action into a Case flow, you MUST also add a further action immediately after it in your flow which would allow an Agent to review the output of the AI Action. This can be an action of type 'Manual', 'Manual with Peer Review' or 'Approval'. If you do not add an action like this immediately downstream of the AI Action, you will see a validation message when saving the Case process.
While the AI Analyst feature is released in Beta only, it should not be used for full production purposes, although can obviously be used to test the fuctionality. For now, the current feature can be used with the following known limitations, which will reduce over time as the underlying AI technology beds in:
Multiple output files cannot currently be generated
If functions timeout in Azure, the AI Analyst action's status will remain set as 'In Progress', due to abruptly terminating Azure function (this should not be a problem in production environment)
AI reads a maximum of 100 rows currently, and is dependent on server availability (files of more than 100 rows of data are currently not allowed)
In case if AI fails to make a decision or a tasks defined in policy it will provide an error file (only if you defined that in AI policy prompt)
The following file formats are currently supported: ['c', 'cpp', 'csv', 'docx', 'html', 'java', 'json', 'md', 'pdf', 'php', 'pptx', 'py', 'rb', 'tex', 'txt', 'css', 'jpeg', 'jpg', 'js', 'gif', 'png', 'tar', 'ts', 'xlsx', 'xml', 'zip']
You can now display custom fields on Users, Customers, Contracts, Services and Service Lines to capture bespoke data via the Extension Properties feature.
Depending on where you have chosen to add your fields, they will show accordingly when a user creates or edits a User, Customer, Contract, Service or a Service Line.
To display custom fields on Users, Customers, Contracts Services or Service Lines, go to the Custom Cards section of Builder and then select ‘Extension Properties’ from the drop-down menu.
Note that only users with the 'Setting Settings' option set as part of their user role will be able to create, edit or delete Extension Properties.
In the 'Extension Properties' page, you'll see the list of Objects you can add Extension properties to (i.e. Users, Service Lines, Customer, Contracts and Services) and how many custom data fields have been added to each one.
To add or edit a custom data field for any of the Data Objects, click on the row of the Object you want to update. The row will expand to show all the fields that have already been added to that Object, alongside a list of all the custom data fields in the system.
To add a custom data field to your selected Object, click on a field from the 'Available Fields' section on the right-hand side which shows a list. This will add the field to the 'Added Fields' section on the left.
If the custom data field you need hasn't been created yet, you can easily create it without leaving the Extension Properties screen - simply click the 'add' icon above the list of system fields and fill in the required information in the resulting popup.
After adding the desired custom data fields to your selected Object, drag and drop the fields to modify the order in which you want your custom data fields them to display. You can also choose if you want to make the field mandatory to fill in or not.
You can also remove fields from your selected Object by clicking on the 'X' in the 'Available Fields' section.
If you are adding Extension Properties to a 'User' Object you'll also need to select the user type you want the field to appear on. The options are:
All (Contacts, Service Agents, Self Service Users, Robots)
All People (Contacts, Service Agents, Self Service Users)
Service Agents Only
Robots Only
Note that if you are adding a field of Type 'Enate Reference' to a User, you will only be able to select a User Type of 'Service Agents Only' or 'Robots Only'.
Once you have finished making your changes, make sure to click Save at the bottom of the grid.
Once the changes have been saved, the custom data fields will appear in the relevant areas of Enate.
Extension properties added to the User Object will show in the following places, depending on the User Type Setting selected.
If any of the 'All (Contacts, Service Agents, Self Service Users, Robots)', 'All People (Contacts, Service Agents, Self Service Users)' or 'Service Agents Only' User Type options have been selected, Extension Property fields will appear in the 'General' tab when you create or edit a Service Agent in Builder.
If any of the 'All (Contacts, Service Agents, Self Service Users, Robots)' or 'All People (Contacts, Service Agents, Self Service Users)' User Type options have been selected, Extension Property fields will appear in the 'Create/Edit Contact' pop-up when you create or edit a contact in Work Manager.
Extension properties added to the Service Line Object will be added to the Service Lines screen in Builder. They will not show anywhere in Work Manager.
Extension properties added to the Customer Object will be added to the Customer pop-up, accessible from the Service Matrix in Builder. They will not show anywhere in Work Manager.
Extension properties added to the Contract Object will be added to the Contract pop-up, accessible from the Service Matrix in Builder. They will not show anywhere in Work Manager.
Extension properties added to the Service Object will be added to the Services pop-up, accessible from the Service Matrix in Builder. They will not show anywhere in Work Manager.
We've simplified record count configuration for Cases and Tickets in Builder to accompany the new Forecasting feature. If you are using the 'Effort Estimation' feature, record count will be used as part of calculating the estimated effort of a work item so it is important that it is filled in correctly.
We have changed how you configure record for Cases and Tickets in Builder. Previously, record count was configured in the 'Case info' tab of a Case or in the Ticket category within a Ticket version. Now, record count is now configured at a process type level in Builder, i.e. when configuring Case types and Ticket Category types from the Service Lines screen.
This change means that changes can be made in significantly fewer places without needing to re-version the whole Case/Ticket configuration.
You can now also add description text to a record count to describe to your Service Agents how they should use record count for in that particular process, e.g. Payslip Count. The description will show next to the record count setting in Work Manager at runtime.
Record Count can now also be added to work items as part of creating them via Bulk Create.
Migration impact
Note that upon upgrade to version 2024.1, record count will be 'switched off' for all processes.
User role impact:
The change in record count location slightly affects which Builder users are able to configure record counts.
Record count configuration is now controlled by the 'Case Types' or 'Ticket Categories' option.
Standard user role impact: ‘Local Builders' will no longer be able to edit record count as it has moved to the Case/Ticket category type screen where only ‘Master Builders’ or ‘System Admins’ have access.
Custom user role impact: any users with the 'Case Types' or 'Ticket Categories' option will be able to configure record count.
Please note that record counts can no longer be persisted, i.e. if it is filled in for one process, it will no longer be populated with the same value when a new process is triggered.
Additionally, if switched on, record count will be displayed on all the components of a Case, e.g. on all of its Actions.
To enable record count for a Case, go to the Service Line screen in Builder, select the Case type you want the Record Count to show for and switch the new 'Enable Record Count' option on. Work Manager users will now be able to enter a record count for processes of that Case type.
To enable record count for a Ticket, go to the Service Line screen in Builder, select the Ticket Category type you want the Record Count to show for and switch the new 'Enable Record Count' option on.
Work Manager users will now be able to enter a record count for Tickets in that category.
If you switch 'Enable Record Count' on, you'll also be able to add a Record Count description to explain to your Service Agents what you want them to use record count for in that particular process, e.g. Payslip Count.
If record count has been enabled for a Case or Ticket, it will appear for Work Managers on the system card of their Case or Ticket screen. They will be able to view the description written by the Builder user and add to the record count itself.
It should be noted that when a record count is updated on an Action in Work Manager, it will update the record count on the Case which will automatically update the next Action that starts in the Case. However, the record count for the current Action and previous Actions will not be changed automatically.
We've added new optional fields to help capture more information on your Contacts, Service Agents, Customers and Contracts.
Contacts can now be associated with a Location and Department and Service Agents can now be associated with a Location, Cost Center, Service Line, Department and Start Date.
Customers and Contracts can now be associated with a Location.
The Locations, Departments and Cost Centers that can be selected are configured in Builder.
We are also removing some existing fields.
The new fields have been added to the following places. All new fields are optional.
Location - you can select the location of a contact from the list of locations in the system.
Department - you can select the department of a contact from the list of department in the system.
These can be found in the Create/Edit Contacts pop-up in Work Manager and in the 'About' section of the Contact Activity page.
Service line - you can select the service line of a service agent from the list of service lines in the system.
Location - you can select the location of a service agent from the list of locations in the system.
Cost Center - you can select the cost center of a service agent from the list of cost centers in the system.
Department - you can select the department of a service agent from the list of department in the system.
Employment Type - you can select the employment type of a service agent, i.e. Permanent, Contractor, Fixed Term, Intern or Unknown.
Start Date - you can select the start date of a service agent
These fields can be found in the 'Details' tab when creating/editing a Service Agent in Builder.
Location - you can select the location of a customer from the list of locations in the system.
This can be found in the 'Customer' tab from the Service Matrix in Builder.
Location - you can select the location of a contract from the list of locations in the system.
This can be found in the 'Contract' tab from the Service Matrix in Builder.
New departments, locations and cost centres can all be added and updated from the System Settings section of Builder by users who have the 'System Settings’ option set as part of their user role.
To add a new department, go to the General Settings section of Builder and then select 'Departments' from the menu.
Here you'll see a list of departments that have already been added to the system.
To add a new one, click on the '+', fill in the name (and description if you want) of your new option and then click 'Create'.
The new department will be added to the list.
You can also edit a department by clicking on it and then editing the name or description and clicking 'Update'.
To add a new location, go to the General Settings section of Builder and then select 'Locations' from the menu.
Here you'll see a list of locations that have already been added to the system.
To add a new one, click on the '+', fill in the name (and description and address if you want) of your new option and then click 'Create'.
The new location will be added to the list.
You can also edit a location by clicking on it and then editing the name or description or address and clicking 'Update'.
To add a new cost center, go to the General Settings section of Builder and then select 'Cost centers' from the menu.
Here you'll see a list of cost centers that have already been added to the system.
To add a new one, click on the '+', fill in the name, code (and description if you want) of your new cost center and then click 'Create'.
The new cost center will be added to the list.
You can also edit a cost center by clicking on it and then editing the name or code description and clicking 'Update'.
Locations, Cost Centre, Departments and Service Lines can all be localized in the Localization page of Builder.
Along with adding these new fields, we are also deleting some existing ones.
The following data fields are either being deleted if they are 100% unpopulated or migrated into Extension Properties if there is any population.
Telephone Number
Mobile Number
Date Of Birth
Address
Office Location
This means that:
If the fields are 100% unpopulated, they will be removed from the UI, i.e. they should be removed from the Contacts page as columns and they should be removed as column options that a user can select in the 'Select Columns' pop-up. They can always be added back in the future as Extension Properties.
If the fields are populated at all, they will be migrated across as an Extension Property.
Please note that this is done per field, i.e. if you are using Address but not Date of Birth, then when you upgrade to 2024.1 you will have 'Address' as an Extension Property but 'Date of Birth' will be deleted.
Note: for a list of recent changes to Enate Marketplace integrations, see this section.
This is a Hotfix release for version 2024.1 of Enate. It contains two enhancements and number of bug fixes, which can be found below.
This is a Hotfix release for version 2024.1 of Enate. It contains one enhancement and a number of bug fixes, which can be found below.
This is a Hotfix release for version 2024.1 of Enate. It contains one bug fix, which can be found below.
This is a Hotfix release for version 2024.1 of Enate. It contains a number of bug fixes and one enhancement, which can be found below.
Enhancements
This is a Hotfix release for version 2024.1 of Enate. It contains two bug fixes which can be found below.
This is a Hotfix release for version 2024.1 of Enate. It contains two bug fixes which can be found below.
This is a Hotfix release for version 2024.1 of Enate. It contains one bug fix which can be found below.
Enhancements
This is a Hotfix release for version 2024.1 of Enate. It contains one new enhancement which can be found below.
This is a Hotfix release for version 2024.1 of Enate. It contains two bug fixes which can be found below.
This is a Hotfix release for version 2024.1 of Enate. It contains two bug fixes which can be found below.
This is a Hotfix release for version 2024.1 of Enate. It contains two bug fixes which can be found below.
This is a Hotfix release for version 2024.1 of Enate. It contains two bug fixes which can be found below.
This is a Hotfix for version 2024.1 of Enate. It contains a few bug fixes and enhancements which can be found below.
Enhancements
This is a downloadable copy of the enhancements and deprecations in this version of Enate.
This is a downloadable copy of the bug fixes in this version of Enate. It also contains all the other bug fixes for the 2024.1 releases of Enate.
This is a Hotfix release for version 2024.1 of Enate. It contains one bug fix which can be found below.
This is a downloadable copy of the bug fixes in this version of Enate. It also contains all the other bug fixes for the 2024.1 releases of Enate.
This is the production release for version 2024.1 of Enate. It contains a number of new features, enhancements and bug fixes.
The change log contains a detailed list of the new features, enhancements, bug fixes and known issues in this version of Enate. A downloadable copy of the New Features & Enhancements Change Log, the Bug Fixes Change Log and the Known Issues Change Log are available below.
New Features & Enhancements
This is a downloadable copy of the new features, enhancements and deprecations in this version of Enate.
Bug Fixes
This is a downloadable copy of the bug fixes in this version of Enate.
This is a downloadable copy of the known issues in this version of Enate.
Specific known issue for Microsoft 365 Graph API
This is a downloadable copy of the API changes in Enate's 2024.1 release. It contains information about the API changes that have occurred between versions 2023.5 and 2024.1 of Enate.
This is a downloadable copy of the warehouse database data dictionary for all 2024.1 versions of Enate.
Below is a copy of the breaking changes document for version 2024.1.0 of Enate. It contains information about all the breaking changes within the Data Warehouse and Enate's APIs, and includes the validation codes for version 2024.1.0.
2024.1.0.0 is the preview release for version 2024.1 of Enate. It contains a number of new features, enhancements and bug fixes.
The change log contains a detailed list of the new features, enhancements, bug fixes and known issues in version 2024.1.0.0 of Enate. A downloadable copy of the New Features & Enhancements Change Log, the Bug Fixes Change Log and the Known Issues Change Log are available below.
New Features & Enhancements
This is a downloadable copy of the new features and enhancements in this version of Enate.
Bug Fixes
This is a downloadable copy of the bug fixes in this version of Enate.
This is a downloadable copy of the known issues in this version of Enate.
Specific known issue for Microsoft 365 Graph API
This is a downloadable copy of the API changes in Enate's 2024.1 release. It contains information about the API changes that have occurred between versions 2023.5 and 2024.1 of Enate.
This is a downloadable copy of the warehouse database data dictionary for all 2024.1 versions of Enate.
Below is a copy of the breaking changes document for this version of Enate. It contains information about all the breaking changes within the Data Warehouse and Enate's APIs, and includes the validation codes for this version.
From v2024.1, you have the option to display a link to your company's Privacy Policy on the Enate login page. Note that this requires you to have a web-available location for your company's Privacy Policy. The setting for this is accessible in Builder: When a value is set for this, a link called 'Privacy Policy' will appear on the login page below the link for forgotten passwords (no such link will display if a value is not supplied for this in Builder).
Clicking on the privacy policy link will open up a new browser tab showing the link provided (i.e. your own Privacy Policy page).
Please Note: Enate does not record whether a user accepts or declines the privacy policy.
To configure a privacy policy link, go to Enate Builder and open up the 'Settings' page. Scrolling to the bottom of the 'General Settings' section, Builder users will find the Privacy Policy Link section. Here, users can insert the http/s link to their company's privacy policy. Once inserted, this link will open when a user clicks on the privacy policy link on the Enate login page.
With Enate version 2024.1, you've got an additional feature to help deal with unhandled (unprocessed) emails if there are large volumes to dal with: bulk delete of unhandled emails.
Once you're in the Unhandled emails section, hovering over an email will bring up a tickbox to select the email (or to select all displayed emails by clicking the header box).
Click on one or more boxes and a delete button will appear next to the filter, along with the number of emails selected.
When you click to delete, a confirmation pop-up will appear stating how many emails are going to be deleted, and ask for final confirmation to delete.
Please note: Once an email has been deleted, it cannot be undeleted, though it will remain accessible in the system to view.
Once you confirm, an 'in-progress' popup will display the deletion progress. When all emails have been successfully deleted, a message will appear on-screen confirming this.
If you don't want to proceed with deleting emails (and have not yet hit the delete button) simply deselect the emails or click on the cross next to the delete button.
As of Enate version 2024.1, when your Enate system is set to use 'Plus Addressing Only' mode for how it processes and routes emails, your end clients will now see an additional line auto-inserted into the emails they receive. This line contains guidance on how to best respond to the email, based upon their intention to either start a new business request or continue corresponding on the same item. This is the new line they will see.
The content of the additional line can be modified from the Email Templates section of Builder. The default text is available in all supported languages.
This new text will append itself to outgoing emails as follows:
to the top of system generated emails.
at the bottom just above the signature, above the feedback footer for manually composed emails.
By default, the content will read as follows:
'##- For responses related directly to this request, please send a reply email. Please do not adjust any email addresses in this mail. For NEW requests, please create a brand new email instead. -##'
The intention here is to avoid erroneously creating brand new tickets from incoming emails where the client really intended just to continue correspondence. The note regarding email addresses is to encourage client users to leave Plus Addressing-style email addresses as-is rather than removing or adjusting them when they send a response back in.
As part of this new feature, a new 'Reply Instructions' Email template is available within the Email Templates of Builder. This will allow users with the required feature access to specify alternative content that you wish to show to your client users instead of the default.
If the reply instructions are on a manually written email, the reply instructions will appear just above the Enate user's signature.
If the email is one which has been automatically generated by the system, these reply instructions will appear directly at the top of the email body text.
The 'Reply Instructions' template will only be available to be used when the 'Plus Addressing Only' option is toggled on in the 'General Settings' of Builder. When this option is enabled, users will see a notification message saying that the 'Reply Instructions' template is enabled as well as a link to allow the user to view/ modify it.
Builder users can reach the template by either clicking on the link that appears in general settings or by finding it from the template list in the same manner they can find all other Email templates. If users have the ability to edit templates turned on then they can select to edit the template, otherwise users can only view it. If a user clicks to edit the template they will see that the purpose of the template is already set to 'Reply Instructions'. This cannot be changed, however the name of the template can be modified.
Users will be presented with default description text and default instruction text in the body of the email. Both of these default texts can be edited.
It should be noted that only one 'Reply Instructions' template can exist in the system and therefore users will not be able to chose reply Instructions as an option in the Purpose drop down when creating other templates.
For users to be able to edit the 'Reply Instructions' template they must have the option to edit templates enabled in User Roles. By default, users with 'System Administrators' Builder Role will be able to edit the 'Reply Instructions' default email. Add 'Edit Email Content' to the Builder User Role of other people you wish to have this access.
Enate version 24.1 sees a brand new report type coming to Work Manager. The Sentiment Analysis report displays information relating to email sentiment analysis allowing users to quickly and clearly see developing trends regarding incoming emails and take action where necessary.
In order for the Sentiment Analysis report to be availabe, the EnateAI Sentiment Analysis integration must be enabled (this can be done in Enate's Marketplace in Builder). When this integration runs it generates the data needed for the report. Once this integration has been activated, information will automatically begin to be sent into and displayed in the report.
Here are some of the type of information which can be found within the report
View the overall share and count of incoming emails analysed as having a positive, neutral or negative sentiment.
Track the fluctuation of email sentiment over time. Look out for any significant changes and address them accordingly.
Compare email sentiment across your companies, regions, services and processes. Take action accordingly.
Identify top senders based on email volume and sentiments to address customer concerns effectively and efficiently.
View the agents that receive the highest volume of positive or negative emails, highlighting areas for improvement or recognition.
View how the number of agents a work item is assigned to affects client sentiment. Take action accordingly.
View how the length of time a work item is open for affects client sentiment. Take action accordingly.
View how meeting and not meeting the SLA on a work item affects client sentiment. Take action accordingly.
View how reopening work items affects client sentiment. Take action accordingly.
View how raising defects on work items affects client sentiment. Take action accordingly.
Access to and the ability to edit the sentiment report is controlled by permissions in user roles, in the same way as all other reports within Enate. If users do not have the right permissions enabled, they will not be able to access the report.
See below for a complete list of all the available data fields that can be used within the Sentiment Analysis report:
A new attribute has been made available for use on your Companies in Builder: External Reference ID:
This is an optional field which you can use for adding in any external reference numbers your organisation may use for identifying customers & suppliers which you have added into Enate.
This can primarily be used for your Reporting and API / webhook purposes. It is a 256 character alphanumeric field which is empty by default.
Note: This External Reference ID value is not displayed anywhere in Work Manager.
We have added the ability to reference an Enate property in a custom data field as part of the new Extension Properties feature.
When you are selecting which custom data fields you want to a appear for a user, you can select to reference This is particularly useful for Extension Properties as it allows an Enate property, e.g. a User, to be associated with another Enate property, e.g. a Service.
To create an Enate Object type of custom data field, select the new 'Enate Reference' option when creating the custom data field. You can then add the field as an Extension Property to Users in the 'Extension Properties' page.
Please note that currently the only Enate Object available to choose is 'Service'. We will be expanding this in the future and look forward to receiving feedback about desired requests. Additionally, fields with the 'Enate Reference' type can only be used as part of Extension Properties and not in Custom Cards, Email Templates ot Case conditions in this release. Also, Extension Properties of type 'Enate Reference' can only be added to 'Users' in this release - and only to Service Agents or Robots in this release.
We are making some improvements to Process Group functionality in 2024.1.
You can sort your processes into Process Groups in Builder to help make it easier to find the right process. Previously, this functionality was limited to Builder only, but we are now showing process group information in Work Manager too to help make it easier for Service Agents to find the right process to start.
When a Service Agent is creating work from the 'Create New Work Item' dropdown in Work Manager, they will now be able to see which Process Group a process belongs to. In the example below, the Process Group is called 'Internal'.
They'll also be able to filter processes down by process group to more easily find the process they want to start.
Service agents will also be able to filter Cases by process group when they are converting a Ticket into a Case.
We've also introduced a new General Setting that lets you decide if you want to show or hide process group information in both Builder and Work Manager.
If the setting is off, all process group labels and fields will be hidden.
Note that if a user tries to switch off the option after having added process group information, they will not be able to switch it off.
Migration notes:
If process group is 100% blank for a customer, upon upgrade the new 'Show Process Group Information' setting will be switched off.
If process group is populated even just once, upon upgrade the new 'Show Process Group Information' setting will be switched on. Any processes blank process group name will be automatically given the process group name of '(Default)'
The check will be for both Cases and Tickets - if either is non-null then it is ON.
You still set Process Groups from the Case Type or Ticket Type screens from the Service Lines page (if the Process Group setting is switched on).
Process Groups will continue to be displayed on the Service Matrix page as they are currently when the Process Group setting is toggled on.
With 2024.1 Enate is bringing some new search enhancements to the Email Connector and Routes page. These enchantments will allow users to conduct a quicker, more refined and accurate search than before.
The Connectors page in Builder now allows filtering by Connector Name, Username, Primary Email Address, Direction, and Enabled.
Note: Clicking on the column headers which contain freetext search boxes will also change the ordering on that column.
Now on the Email Routes page, when users choose to expand the section for a specific route, they will be presented with three text search boxes in the expanded section header for email, process and ticket category.
Users can also access these same three search boxes on still-collapsed sectionsby clicking on the search icon.
We've adjusted the text of the filters on the Schedules page Builder to make them more intuitive. They will now read as follows:
While the filter options for expiring schedules showed the user the schedules expiring within the date stated in the text / dates selected selected, they also showed any already expired schedules along with them, however this may not have been clear from the previous labels. The adjustment is there to make it clear that it's a combination of schedules due to expire AND any that already have which get displayed. These now read:
Already Expired
Expired / Expiring within next 7 days
Expired / Expiring within next 30 days
Expired / Expiring withing next 90 days
Select Date
You can now export schedule data in an excel file via the export button.
We've introduced a small UI improvement to the Email pages in Work Manager. Previously, the quick look box on the left had side of the screen operated on a dynamic 'load while scrolling' basis. Now this section will be paginated.
Users will be able to set how many emails appear per page, choosing between 50 or 100.
Additionally, users will be able to click through the pages using the back and forward arrows, and quickly return to first page with double arrows.
There are certain circumstances when clients may send in an email that should really be used to start a new work item but, because they've sent it as a response to an existing mail chain, it ends up being attached to an existing work item. A prime example of this is when a client responds to an email with the intention of starting a new ticket but it gets added to the work item of the email chain that they were replying to. In V2024.1, Enate is introducing a new feature that allows incoming emails that get added to an existing work item like this to now be used to create a new work item.
If a user is working on a work item and realizes that an email that has been attached to it should actually be used to start a new work item, they can use a link now available to them when hovering over that mail in the Comms or Timeline view.
Clicking this link and then the following confirmation popup will result in the email being effectively sent back into Enate, but with an additional rule that it should not append itself to an existing work item. Once the email has successfully created a new work item, a confirmation message will appear.
Once the new work item has been created, a note will show at the top of that mail with a link to that new work item, and that original mail entry in the first work item will effectively be set to 'read only' (since it should no longer be used to process the request within that mail).
Links between the original work item and the new work item will also be displayed on each of their respective 'Linked Items' tabs.
It should be noted that this option will never appear on the initial email which creates a work item, only on subsequent incoming emails which could be inappropriately appending.
In 2024.1 we've simplified how estimated effort for your work items are configured to accompany the new Forecasting feature.
We have changed how you enter and update initial estimated efforts for Actions and Tickets in Builder. Previously, estimated effort was configured in the General Settings of an Action or in the Ticket category within a Ticket version. Now, initial estimated effort is configured at a process-type level in Builder, i.e. when configuring Action types and Ticket Categories from the Service Lines screen. See below for more information about how to configure estimated effort for a Ticket or Action. Providing an initial estimated effort value helps Work Manager users keep to their SLA’s and provide a timely service.
This change means that changes can be made in significantly fewer places without needing to re-version the whole Case/Ticket configuration - changes will take effect for the next Case/Ticket that is created.
We've also added the ability to enter an initial estimated effort value for Cases in Builder too - previously it was only available for Tickets and Actions. See below for more information about how to configure estimated effort for a Case.
We are also showing the average time it took to complete Cases, Action and Tickets on the relevant Case Type, Action Type and Ticket Category screens to help suggest an appropriate value. See below for more information.
Estimated Effort can now also be added to work items as part of creating them via Bulk Create.
Migration impact:
Tickets - upon upgrade to version 2024.1, any non-null data in the estimated effort field of a Ticket will be migrated to the new 'Ticket Category Type' location. If there are multiple estimation values within a Ticket category, the lowest non-null value will be the value that gets migrated.
Actions - upon upgrade to version 2024.1, any non-null data in the estimated effort field of an Action's general settings will be migrated to the new 'Action Type' location. If there are multiple estimation values within an Action type, the lowest non-null value will be the value that gets migrated. This applies for both ''Manual' Estimated Effort' and 'Robot Estimated Effort'.
If multiple estimates are needed for the same Action Type/Ticket Category, you should re-version the relevant processes, create a Action Type/Ticket Category with identical settings, enter your new estimated effort value and add a new Action of that Action type in the relevant place in your process.
User role impact:
The change in 'Estimated Effort' location slightly affects which Builder users are able to configure estimated effort.
Estimated Effort is now controlled by the 'Case Types' or 'Ticket Categories' setting in User Roles.
Standard user role impact - ‘Local Builders' will no longer be able to edit record count as it has moved to the Case/Ticket category type screen where only ‘Master Builders’ or ‘System Admins’ have access.
Custom user role impact - any users with the 'Case Types' or 'Ticket Categories' option will be able to configure estimated effort.
To enter an initial estimated effort for a Ticket, you can:
Go to the Service Lines screen, select a Service Line, click to update the third-level Ticket Category and then enter your 'Initial Estimated Effort Per Record' in the resulting pop-up in the following format: dd:hh:mm
Go to the Ticket screen, click to add or edit a new Ticket category, click to enter update the third-level Ticket Category and then enter your 'Initial Estimated Effort Per Record' in the resulting pop-up in the following format: dd:hh:mm
To enter an initial estimated effort for an Action, you can:
Go to the Service Lines screen, select a Service Line, select an Action Type and then enter your 'Initial Estimated Effort Per Record' and/or your 'Robot's Initial Estimated Effort Per Record' in the resulting pop-up in the following format: dd:hh:mm
Go to the Case screen, click to create a new Action Type, or edit a new Ticket category then enter your 'Initial Estimated Effort Per Record' and/or your 'Robot's Initial Estimated Effort Per Record' in the resulting pop-up in the following format: dd:hh:mm
We've also added the ability to enter an initial estimated effort value for Cases in Builder too - previously you could only do this for Tickets and Actions.
To enter an initial estimated effort for a Case, go to the Service Lines screen, select a Service Line, select a Case Type and then enter your 'Initial Estimated Effort Per Record' in the resulting pop-up in the following format: dd:hh:mm
If an initial estimated effort value has been provided for a Case type, it will show in the Time Tracker card in Work Manager as 'Benchmark' for all Case of that Case type if the 'Display Expected Time in Time Tracker' option from Builder System Settings is enabled.
It is important to note that the estimated time for a Case only applies to the time a Work manager user spends on the Case screen. Time spent on an Action within the Case does not count towards the estimated finish time of the Case as Actions have their own individual estimated times.
We are now showing the average time it took to complete Cases, Action and Tickets on the relevant Case Type, Action Type and Ticket Category screens.
This help suggest an appropriate value for the 'Initial Estimated Duration per Record Count' value.
We have added a new feature that enables Work Manager users to provide more accurate estimated efforts for work items, enabling you to plan resource requirements more effectively.
In the long term, this data can be collated and fed back to admin users to adjust estimated effort timers and to provide more accurate forecasting for future work volumes.
To switch on the new 'Forecasting' feature, go to the System Settings page of Builder and switch on ‘Show Estimated Effort’. Noted that ‘Show Estimated Effort’ setting can only be switched on if the ‘Show Time Tracker’ setting has also been switched on.
Once the 'Forecasting' feature has been switched on, a new ‘Effort Estimation’ tab will appear in Cases in Work Manager.
Here you'll see a summary of the estimated effort for the whole Case, a breakdown of the estimated effort for Actions or Sub Cases that make up the Case, and a breakdown of the estimated effort for Actions or Sub Cases that have not been created yet.
The 'Case Effort Summary' section is where a user can change the estimated time for the Case. It also provides other useful metrics for the Case.
'Total Case Estimated Effort' effort shows the total estimated time that the Case is estimated to take. This can be updated by a user with a more accurate estimate.
It is the sum of the ‘Estimated’ effort of all the created work and the Actions (and Sub Case Actions) that make up the Case and the and the 'Effort for Work Not Yet Created' value
The field will will initially show the manual ‘Initial Estimated Effort Per Record’ value from Builder (if there is one) multiplied by the record count
If the ‘Record Count’ gets updated, the ‘Estimated Effort’ for the Case that has not been updated by a Work Manager user will be updated to reflect the change in record count.
Once the Case is in a state of Resolved or Closed, its estimated effort can no longer be changed.
Note that increasing this value will increase the ‘Effort for Work Not Yet Created’ estimate and vice versa.
‘Total Case Actual Effort’ effort shows the amount of time that has been spent working on the Case Effort for Work Not Yet Created.
It is the sum of the 'Actual' effort for all the created Actions and Sub Cases that make up the Case, taken from their respective Time Trackers.
‘Total Case Remaining Effort’ shows the amount of time estimated to be left on the Case.
It is the sum of the 'Estimated Remaining' effort for all the created Actions and Sub Cases that make up the Case AND the estimated remaining time for work that has yet to be created (therefore it might not always equal the 'Case Estimated' effort minus the 'Case Actual' effort).
Changing the 'Estimated' effort value for a Case has the following effects:
Automatic update to the 'Effort for Work Not Yet Created' estimated value. This is because the ‘Estimated Effort’ for the Case is a calculated value made up of the sum of the ‘Estimated’ effort of all the created work and the Actions (and Sub Case Actions) that make up the Case and the and the 'Effort for Work Not Yet Created' value.
Increasing the 'Estimated' effort for a Case increases the 'Effort for Work Not Yet Created' value by the same amount
Decreasing the 'Estimated' effort for a Case decreases the 'Effort for Work Not Yet Created' value by the same amount
The 'Effort Breakdown for Created Work' section is where a user can change the estimated time for the individual created Actions (and Sub Cases) that make up the Case. It also shows other useful metrics for each of the created Actions (and Sub Cases) that make up the Case.
Note that once an Action is in a state of Resolved or Closed, its estimated effort can no longer be changed.
As Actions (and Sub Cases) get created, the estimated effort for them will be taken from the Estimated effort value from the Work Not Yet Created section below.
For each Action, you'll see:
A link to each Action
'Estimated' effort that shows the total estimated time that the Action is estimated to take. This can be updated by a user with a more accurate estimate.
The field will will initially show the manual ‘Initial Estimated Effort Per Record’ value from Builder multiplied by the record count
If the ‘Record Count’ gets updated, the ‘Estimated Effort’ for any running Actions that have not been updated by a Work Manager user will be updated to reflect the change in record count.
Increasing this value will decrease the ‘Work Not Yet Created’ estimate and vice versa and therefore might affect the total 'Case Estimated' effort
Note that once an Action is in a state of Resolved or Closed, its estimated effort can no longer be changed.
‘Actual’ effort shows the amount of time that has so far been spent working on that Action
The value is taken from the Time Tracker of the Action.
‘Estimated Remaining’ shows the amount of time estimated to be left on the Action.
It is calculated by subtracting the 'Actual' effort for the Action from the 'Estimated' effort.
The due date of the Action
You'll also see a 'Start By' value if the 'Actual' effort is currently zero. This value show when is the absolute latest that the Action can be started by in order to meet its due date.
The status of the Action
Changing the 'Estimated' effort value for an Action has the following effects:
Automatic update to the 'Effort for Work Not Yet Created' estimated value for the Case.
Possible automatic update to the 'Estimated' effort for the whole Case
Details:
Decreasing the 'Estimated' effort for an Action increases the 'Effort for Work Not Yet Created' value for the Case by the same amount (leaving the 'Estimated' effort for the whole Case the same).
Increasing the 'Estimated' effort for an Action decreases the 'Effort for Work Not Yet Created' value for the Case by the same amount. This may or may not affect the 'Estimated' effort for the overall Case.
If the updated ‘Estimated Effort’ on an Action doesn't increase by enough to cause the ‘Effort for Work Not Yet Created’ value for the Case to go below 0, the 'Estimated' effort for the Case will not be affected
Example: let's say that the 'Estimated' effort for Action 1 is 2 hours, the estimated 'Effort for Work Not Yet Created' is 1 hour and the 'Estimated Effort' for the Case is 3. A user decides that Action 1 is going to take 1 hour more and so updated the 'Estimated' effort for Action 1 from 2 to 3 hours. 'Effort for Work Not Yet Created' will decrease from 1 hour to 0 and the 'Estimated' effort for the Case will not change - it will stay at 3 hours.
If the updated ‘Estimated Effort’ on an Action increases enough to cause the ‘Effort for Work Not Yet Created’ value for the Case to go below 0, the difference should be added to the ‘Estimated Effort’ of the overall Case.
Example: let's say that a Case only has one Action created for it called Action 1. The 'Estimated' effort for Action 1 is 2 hours, the estimated 'Effort for Work Not Yet Created' is 0 and therefore the 'Estimated Effort' for the whole Case is 2 hours. A user decides that Action 1 is going to take 1 hour more and so updates the 'Estimated' effort for Action 1 from 2 to 3 hours. Because 'Effort for Work Not Yet Created' is 0, the 'Estimated' effort for the overall Case is therefore going to increase by 1 hour from 2 to 3 hours.
Example 2: let's say that a Case only has one Action created for it called Action 1. The 'Estimated' effort for Action 1 is 2 hours, the estimated 'Effort for Work Not Yet Created' is 1 hour and therefore the 'Estimated Effort' for the whole Case is 3 hours. A user decides that Action 1 is going to take 2 more hours and so updates the 'Estimated' effort for Action 1 from 2 to 4 hours, causing the 'Effort for Work Not Yet Created' to decrease by 1 hour from 1 to 0 (decreasing as far as it can). The "remaining" 1 hour will effectively be added to the total 'Estimated' effort of the Case that will increase by 1 hour to from 3 to 4 hours.
If a Sub Case gets created, you'll see
A link to the Sub Case if you have permission to access it (otherwise you'll just see the name and reference number of the Sub Case with no link)
A Sub Case "total" row with the following:
'Estimated' effort shows the total estimated time that the Sub Case is estimated to take. This can be updated by a user with a more accurate estimate.
It is the sum of the ‘Estimated’ effort of all the created and yet-to-be created Actions that make up the Sub Case.
The field will will initially show the manual ‘Initial Estimated Effort Per Record’ value from Builder multiplied by the record count
If the ‘Record Count’ gets updated, the ‘Estimated Effort’ for the Sub Case that has not been updated by a Work Manager user will be updated to reflect the change in record count.
Once a Sub Case is in a state of Resolved or Closed, its estimated effort can no longer be changed.
Note that increasing this value will increase the ‘Work Not Yet Created’ estimate for the Sub Case and vice versa.
‘Actual’ effort shows the amount of time that has so far been spent working on the Sub Case.
It is the sum of the 'Actual' effort for all the created Actions that make up the Sub Case, taken from their respective Time Trackers.
‘Estimated Remaining’ shows the amount of time estimated to be left on the Sub Case.
It is the sum of the 'Estimated Remaining' effort for all the created Actions that make up the Sub Case AND the estimated remaining time for work that has yet to be created for that Sub Case (therefore it might not always equal the 'Sub Case Estimated' effort minus the 'Sub Case Actual' effort)
The due date of the Sub Case
The status of the Sub Case
A row for each Sub Case Action with the following:
'Estimated' effort shows the total estimated time that the Sub Case Action is estimated to take. This can be updated by a user with a more accurate estimate.
The field will will initially show the manual ‘Initial Estimated Effort Per Record’ value from Builder multiplied by the record count
If the ‘Record Count’ gets updated, the ‘Estimated Effort’ for any running Sub Case Actions that have not been updated by a Work Manager user will be updated to reflect the change in record count.
Increasing this value will decrease the ‘Work Not Yet Created’ Sub Case estimate and vice versa and therefore might affect the total 'Sub Case Estimated' effort
Once an Action is in a state of Resolved or Closed, its estimated effort can no longer be changed.
‘Actual’ effort shows the amount of time that has so far been spent working on that Sub Case Action
The value is taken from the Time Tracker of the Sub Case Action.
‘Estimated Remaining’ shows the amount of time estimated to be left on the Sub Case Action.
It is calculated by subtracting the 'Actual' effort for the Sub Case Action from the 'Estimated' effort.
The due date of the Sub Case Action
You'll also see a 'Start By' value if the 'Actual' effort is currently zero. This value show when is the absolute latest that the Sub Case Action can be started by in order to meet its due date.
The status of the Sub Case Action
A row for 'Sub Case Work Note Yet Created' with the following:
'Estimated' effort shows how much effort is estimated to be needed to complete the Sub Case Actions that have not yet been created for that Sub Case. This can be updated by a user with a more accurate estimate.
Changing this estimate will affect the total 'Sub Case Estimated' effort and might affect the effort estimate for the overall Case
Changing the 'Estimated' effort value for a Sub Case Action has the following effects:
Automatic update to the 'Effort for Work Not Yet Created' estimated value for the Sub Case.
Possible automatic update to the 'Estimated' effort for the whole Sub Case
Possible automatic update to the 'Estimated' effort for the whole parent Case.
Details:
Decreasing the 'Estimated' effort for a Sub Case Action increases the 'Effort for Work Not Yet Created' value for the Sub Case by the same amount (leaving the 'Estimated' effort for the whole Sub Case the same and therefore having no impact on the 'Estimated' effort for the whole parent Case).
Increasing the 'Estimated' effort for a Sub Case Action decreases the 'Effort for Work Not Yet Created' value for the Sub Case by the same amount. This may or may not affect the 'Estimated' effort for the overall Case.
If the updated ‘Estimated Effort’ on a Sub Case Action doesn't increase by enough to cause the ‘Effort for Work Not Yet Created’ value for the Sub Case to go below 0, the 'Estimated' effort for the Sub Case will not be affected (and therefore the 'Estimated' effort for the whole parent Case will not be affected).
Example: let's say that a Sub Case only has one Action created for it called Sub Case Action 1. The 'Estimated' effort for Sub Case Action 1 is 2 hours and the estimated 'Effort for Work Not Yet Created' for the Sub Case is 1 hour, therefore the 'Estimated Effort' for the Sub Case is 3 hours. A user decides that Sub Case Action 1 is going to take 1 hour more and so updates the 'Estimated' effort for Sub Case Action 1 from 2 to 3 hours, causing the 'Effort for Work Not Yet Created' for the Sub Case to decrease from 1 hour to 0. The 'Estimated' effort for the Sub Case will not change - it will stay at 3 hours (and therefore the 'Estimated' effort for the whole parent Case will not be affected).
If the updated ‘Estimated Effort’ on a Sub Case Action increases enough to cause the ‘Effort for Work Not Yet Created’ value for the Sub Case to go below 0, the difference should be added to the ‘Estimated Effort’ of the overall Sub Case,
Example: let's say that a Sub Case only has one Action created for it called Sub Case Action 1. The 'Estimated' effort for Sub Case Action 1 is 2 hours and the estimated 'Effort for Work Not Yet Created' for the Sub Case is 0, therefore the 'Estimated' effort for the overall Sub Case is 2 hours. A user decides that Sub Case Action 1 is going to take 1 more hour and so updates the 'Estimated' effort for Sub Case Action 1 from 2 to 3 hours. Because 'Effort for Work Not Yet Created' for the Sub Case is 0, the 'Estimated' effort for the Sub Case is going to increase by 1 hour from 2 to 3 hours.
If there is enough time in the 'Effort for Work Not Yet Created' of the parent Case, this 1 hour increase might be taken from there, therefore there will be no impact on the 'Estimated' effort for the whole parent Case.
If there is isn't enough time in the 'Effort for Work Not Yet Created' of the parent Case, this 1 hour increase will result in an increase in the the 'Estimated' effort for the whole parent Case.
Example 2: let's say that a Sub Case only has one Action created for it called Sub Case Action 1. The 'Estimated' effort for Sub Case Action 1 is 2 hours and the estimated 'Effort for Work Not Yet Created' for the Sub Case is 1 hour, therefore the 'Estimated' effort for the overall Sub Case is 3 hours. A user decides that Sub Case Action 1 is going to take 2 more hours and so updated the 'Estimated' effort for Sub Case Action 1 from 2 to 4 hours, causing the 'Effort for Work Not Yet Created' for the Sub Case to decrease as much as it can - here it will decrease by 1 hour to from 1 to 0. The "remaining" 1 hour will effectively be added to the total 'Estimated' effort of the Sub Case that will increase by 1 hour from 3 to 4 hours.
If there is enough time in the 'Effort for Work Not Yet Created' of the parent Case, this 1 hour increase might be taken from there, therefore there will be no impact on the 'Estimated' effort for the whole parent Case.
If there is isn't enough time in the 'Effort for Work Not Yet Created' of the parent Case, this 1 hour increase will result in an increase in the the 'Estimated' effort for the whole parent Case.
The 'Effort for Work Not Yet Created' section shows how much effort is estimated to be needed to complete Actions (and Sub Cases Actions) that have not yet been created for this Case.
It is calculated by subtracting the sum of the 'Estimated' effort for created work from the 'Estimated' effort for the Case. Therefore, increasing the 'Effort for Work Not Yet Created' will increase the effort estimate for the overall Case and vice versa.
As Actions (and Sub Cases) get created, the estimated effort for them will be taken from the 'Estimated Effort for Work Not Yet Created' value.
Once the Case is in a state of Resolved or Closed, the 'Effort for Work Not Yet Created' can no longer be changed.
Overtime, as more work gets completed, these estimates can be compared against the actual time it took to complete the work to determine their accuracy, helping to to adjust benchmark estimated efforts set in Builder.
When configuring the 'Initial Estimated Effort per Record' in Builder, you'll also see the average duration of completed Cases, Action and Tickets to help adjust these benchmark estimated efforts.
In the long term, this all contributes to providing more accurate forecasting for future work volumes.
Table | Fields | Description |
---|---|---|
Context
Contract
Name of the Contract
Context
Customer
Name of the Customer
Context
Service
Name of the Service
Context
Supplier
Name of the Supplier
Date
Date
Calendar range of dates for filtering data
Date
Month
Months of the dates
Date
Year
Year of the dates
Feedback
Comments
Feedback comments given on each workitem
Feedback
Logged
Feedback logged date in date time format
Feedback
LoggedDate
Feedback logged date in date format
Feedback
Rating
Feedback rating from 1 - 5
Feedback
6M Moving Avg(Ratings)
6 months moving average over the number of ratings. To be visualised against dates.
Feedback
Avg. Rating
Average ratings given across all workitems
Feedback
Total Ratings
Total number of ratings given
Feedback Types
Feedback Type
Ratings grouped as Happy, Unhappy & Neutral
Process
Process
Name of the process each Work Item belongs to
Process
Process Group
Process group given for Cases / Tickets
Process
Work Item Type
Type of the Work Item (Ticket, Action or Case)
Sentiment Scores
Logged
Email logged date in date time format
Sentiment Scores
LoggedDate
Email logged date in date format
Sentiment Scores
Sender
Email sender's full name or email address (depending on whichever is availible)
Sentiment Scores
Sentiment Confidence
Confidence level of the email classification (or sentiment score) in percentage (0 - 100%)
Sentiment Scores
6M Moving Avg
6 months moving average over the number of emails that have sentiment scores. To be visualised against dates.
Sentiment Scores
Email Count
Total number of emails that sentiment score
Sentiment Scores
Work Item Count
Total number of workitems with emails that have sentiment score
Sentiment Types
Sentiment Type
Types of sentiment (Positve, Negative or Neutral)
Ticket Categories
Ticket Category1
Ticket Category level 1
Ticket Categories
Ticket Category2
Ticket Category level 2
Ticket Categories
Ticket Category3
Ticket Category level 3
Users
User Name
Full name of the user responsible for the work item
Users
Email Address
Email address of the user responsible for the work item
Users
Team Manager
Full name of the manager of the users responsible for the work item
Work Items
Assigned User Count Groups
Grouping of Assigned User Count into different buckets (e.g., 0, 1-3, 3-5, 5-7 etc.). Assigned User Count is the unique number of users assigned to the work item througout it's lifecycle (from start to end).
Work Items
Customer Duration(Hrs)
Total time (in working hours) taken to complete the work item as per the customer calendar. Value will be blank if the work item is still in progress.
Work Items
Customer Duration Groups
Grouping of Customer Durations into different buckets (e.g., 0-24, 24-48, 48-72, 5-7 etc.)
Work Items
DueDate
Work Item Due Date in date time format
Work Items
EndDate
Work Item End Date in date time format
Work Items
Has Defects
Whether the Work Item has defect or not (Yes or No)
Work Items
Is Reopened
Tickets that got opened after going to resolved status
Work Items
Reference
Reference number of each Work Item
Work Items
ResolvedDate
Work Items Resolved Date in date time format
Work Items
SLA
Service Level Agreement to indicate where Work Item is Overdue or not
Work Items
StartDate
Work Item Start Date in date time format
Work Items
Title
Title of the Work Item
Work Items
Supplier Duration(Hrs)
Total time (in working hours) taken to complete the work item as per the supplier calendar. Value will be blank if the work item is still in progress.