Backlog
8Under consideration
Add daily data collection and live monitoring to Analytics Charts
Extend the existing Analytics Charts time range options to support situational analysis for a single day. Currently, users can analyze data using broader periods such as: Month Week Business users need the ability to analyze data for a specific day and use the Chart for live monitoring during that day. Required Changes Add support for selecting a specific day as the reporting period in Charts. Users should be able to: select any specific date; view data only for that selected day; use existing Chart metrics, filters, and grouping options; monitor current-day data with regular updates. Live Monitoring For the current day, the Chart will be used as a live monitoring tool. The system should therefore refresh the displayed data at a defined interval so newly received conversations/data become visible without requiring the user to rebuild the Chart. The refresh interval should be technically reasonable and consistent with the platform’s existing data processing flow. If automatic refresh is already supported by the platform, the daily Chart should use the existing mechanism. Expected Behavior When a specific date is selected, the Chart displays only data from that day. For the current day: new data should appear after the configured refresh/update interval; existing filters, grouping, and metrics should remain applied after refresh; users should be able to keep the Chart open for ongoing monitoring. Acceptance Criteria Users can select a specific day as the reporting period. The Chart displays only data from the selected day. Current-day Charts refresh data at the defined update interval. Existing Chart filters, grouping, metrics, and export continue to work with the daily period.
Add all team-level export options to the individual agent dashboard
Add the same data export options available on the Team dashboard/page to the individual agent’s personal dashboard. The main goal is to allow users to export the scores and dashboard data of a single agent directly from that agent’s page without first exporting team-level data and manually isolating the required user. Currently, some export formats are available only at the team level. For example, Excel data can be filtered manually after export, but formats such as PNG cannot be separated by agent afterward. Current Behavior Export options available on the Team page are not fully available on the individual agent dashboard. As a result, users cannot directly export one agent’s data in all supported formats. Expected Behavior The individual agent dashboard should provide the same export methods as the Team page. Each export should contain only the selected agent’s scores and relevant dashboard data. The export should respect the same period, filters, and data scope currently applied on the agent dashboard. Acceptance Criteria All export methods available on the Team page are also available on the individual agent dashboard. Exported data contains only the selected agent’s scores and relevant dashboard data. Export behavior and supported formats are consistent between the Team page and the individual agent dashboard. Applied period and filters are respected in the exported data.
Add UI validation for EnderGPT conflicts between prompt instructions and system filters
Add a validation mechanism that detects potential conflicts between the user prompt and the system filters applied to the request before it is submitted for processing. Currently, the prompt and system filters are processed independently. This allows users to create requests where the prompt defines one data scope while the selected filters restrict the data to a conflicting scope. Example: Prompt: Analyze only conversations from August 2026. Do not use data from September or the current month. Applied system filter: Time range: Current month In this case, the request becomes logically conflicting and may return no relevant data or produce an incorrect result. Required Changes Before the request is submitted, the UI should check for obvious conflicts between: date ranges mentioned in the prompt and selected time filters; explicit exclusions in the prompt and active filters; other supported prompt conditions that directly contradict selected system filters. If a conflict is detected, the conflicting elements should be visually highlighted and the user should receive a warning before running the request. Expected Behavior The warning should clearly indicate which prompt condition conflicts with which system filter. Example: Potential conflict detected: the prompt requests data from August 2026, while the active time filter is set to Current month. The user should be able to review and correct either the prompt or the filter before submitting the request. The validation should focus on clear contradictions and should not block valid requests based on uncertain interpretation. Acceptance Criteria Obvious conflicts between prompt conditions and supported system filters are detected before submission. Conflicting prompt text and/or filters are visually highlighted. The UI explains the detected conflict in a clear warning. The user can adjust the prompt or filters before running the request. Existing request flow remains unchanged when no conflict is detected.
Add Agent / Customer channel selection to Discovery search
Add the ability to search in Discovery separately by conversation channel: Agent Customer Currently, search in Discovery does not allow users to specify which side of the conversation should contain the searched value. Using tags for this purpose is inconvenient, especially for one-time searches. Required Changes Extend the existing Discovery search field with a channel selector. Users should be able to choose: Agent Customer The selected channel should define where the search is performed. The behavior can follow the existing filtering approach used for tags. Expected Behavior Examples: Search term: refund Channel: Customer Result: only conversations where the searched value is found in the customer channel. Search term: refund Channel: Agent Result: only conversations where the searched value is found in the agent channel. If no specific channel is selected, the current search behavior should remain unchanged. Acceptance Criteria Discovery search supports separate Agent and Customer channel selection. Search results only match the selected conversation channel. Existing search behavior remains available when no channel is selected.
Update score display logic in TODO
Update the logic used to display conversation scores in the TODO list. Currently, the TODO score column displays the score from the Default Team Scorecard. Instead, the system should display the available conversation evaluation according to the following priority. Score Priority AutoQA evaluation If the AutoQA evaluation was corrected or approved by a reviewer, display its reviewed/final score. Otherwise, display the original AutoQA score. Manual evaluation Display the manual score only if no AutoQA evaluation exists. No evaluation If the conversation has no evaluation, display 0%. Expected Behavior The score column should remain available in TODO. For each conversation: if AutoQA exists and was reviewed, display the reviewed AutoQA score; if AutoQA exists without reviewer changes/approval, display the current AutoQA score; if AutoQA does not exist, display the manual evaluation score if available; if no evaluation exists, display 0%. The displayed score should no longer depend only on the Default Team Scorecard. Acceptance Criteria If an AutoQA evaluation exists and was corrected by a reviewer, the corrected score is displayed. If an AutoQA evaluation exists and was approved by a reviewer, the approved AutoQA score is displayed. If an AutoQA evaluation exists without reviewer actions, the AutoQA score is displayed. If no AutoQA evaluation exists but a manual evaluation exists, the manual score is displayed. If no evaluation exists, 0% is displayed. The score column remains available in TODO. The Default Team Scorecard score does not override an available AutoQA or manual evaluation according to the priority above. Origin
Add row count as an available value in Chart formulas
Extend Chart formulas to support arithmetic operations using the number of rows/groups returned by the Chart. Currently, formulas can use existing metrics and calculated values, but there is no way to use the number of resulting rows after grouping as part of a calculation. This is required for calculating metrics where the denominator is the number of unique grouped entities. Example Use Case A Chart is grouped by unique customer phone number. For each unique number, the Chart contains the number of repeat calls. We need to calculate the average number of repeat calls per unique customer: Sum of repeat calls / Number of unique phone numbers Since grouping by phone number produces one row per unique number, the denominator should be the number of rows produced by the grouping. Example: Unique phone numbers: 100 Total repeat calls: 250 Result: 250 / 100 = 2.5 Average repeat calls per unique number = 2.5. Required Changes Add a value/function to Chart formulas that represents the number of rows in the current grouped result. For example: ROW_COUNT or another naming consistent with the existing formula syntax. This value should be available as an operand in arithmetic expressions together with existing metrics. Example formula: SUM(Repeat Calls) / ROW_COUNT Expected Behavior When a Chart is grouped by a field, row count represents the number of resulting groups. If the Chart is grouped by unique phone number, row count represents the number of unique phone numbers in the result. Row count can be used in arithmetic operations with other Chart metrics. Row count respects the filters and date range applied to the Chart. If filters change the number of resulting groups, the formula result is recalculated accordingly. Acceptance Criteria Chart formulas can use the number of resulting rows/groups as a calculation value. Row count can be combined with existing metrics using arithmetic operations. When grouping by a unique field, row count matches the number of unique grouped values. Row count respects all filters applied to the Chart. Row count respects the selected date range. Formula results are recalculated when grouping, filters, or date range are changed. The functionality can be used to calculate average values such as: Total repeat calls / Number of unique customers Origin
Add separate language filters for agent and customer messages
The platform currently allows users to filter chats by language. It also supports applying certain filters separately to the call center agent and the customer. The language filter should be extended so users can independently filter chats by: the language used by the agent; the language used by the customer. This is required for conversations where the participants may use different languages. Current Behavior The language filter is applied to the chat as a whole. It is not possible to specify whether the selected language was used by the agent or by the customer. Expected Behavior Add two separate language filters: Agent Language Customer Language Each filter should return chats where the selected language was detected for the corresponding conversation participant. Users should be able to: apply only the Agent Language filter; apply only the Customer Language filter; apply both filters simultaneously; combine these filters with other available filters. Acceptance Criteria The filter panel contains separate Agent Language and Customer Language filters. When an Agent Language is selected, the results include only chats where that language was detected for the agent. When a Customer Language is selected, the results include only chats where that language was detected for the customer. When both filters are applied, the results include only chats matching both selected conditions. The same language can be selected for both participants. Different languages can be selected for the agent and the customer. The new filters can be combined with existing chat filters. Clearing one language filter does not reset the other filter. Existing general language filtering behavior remains unchanged unless it is intentionally replaced by the new participant-specific filters. Origin - https://enderturing.freshdesk.com/a/tickets/423
Current week is not displayed when chart data is grouped by week
When chart data is grouped by day, the chart includes data for the current day even though the day is not yet complete. However, when the same data is grouped by week, the current incomplete week is excluded. As a result, users can only view data for the previous completed week. The grouping behavior should be consistent: the current week should be displayed with all available data collected from the beginning of the week up to the current moment. Current Behavior When grouping by day, the current incomplete day is displayed. When grouping by week, the current incomplete week is not displayed. The latest available period in the chart is the previous completed week. Expected Behavior When data is grouped by week, the chart should include the current calendar week, even if it has not yet ended. The current week should contain all available data from the beginning of the week up to the current date and time. Acceptance Criteria Select a date range that includes the current week. Group the chart data by week. Verify that the current week is displayed as the latest period. Verify that the current week contains all available data collected from the beginning of the week up to the current moment. The current week must not be excluded because it is incomplete. Existing filters and timezone settings must also be applied to the current week. Completed previous weeks must continue to be displayed without changes. Pic 1 - chart grouped by day Pic 2 - chart grouped by current week is not working Origin - https://enderturing.freshdesk.com/a/tickets/385
Next up
2Committed and queued
Hide “Improvement available” for Topic versions assessed on an outdated dataset
Request type Improvement / UI logic Problem The “Improvement available” option may currently be displayed for an older Topic version whose accuracy was calculated using an outdated dataset. A historical accuracy score may have been satisfactory when that version was originally assessed. However, after new conversations are added, this score no longer represents the version’s performance on the current dataset. Displaying “Improvement available” in this situation is misleading because it suggests that the old result is still relevant and can be used as the basis for further improvement. Current behavior An older Topic version may continue to display: its historical accuracy score; the “Improvement available” option; even though that version has not been reassessed using the current dataset. As a result, users may compare accuracy scores calculated on different datasets or attempt to improve a version based on outdated assessment results. Expected behavior The “Improvement available” option should be displayed only for Topic versions that have been assessed using the current dataset. If a Topic version was assessed using an older dataset version, the “Improvement available” option should not be displayed for that version. After the user reassesses the Topic version using the current dataset, the system should use the new result to determine whether “Improvement available” should be displayed. Proposed logic The system should compare the dataset used for the version’s most recent assessment with the current dataset: Assessment dataset version = Current dataset version If the dataset versions match, the system may display “Improvement available” according to the existing improvement logic. If the dataset versions do not match, the option must remain hidden. The validation should use the dataset version or dataset snapshot identifier rather than only the number of conversations. This is important because: automatically generated review sets usually increase the dataset in fixed batches; manually created review sets may contain any number of conversations selected by the user. Acceptance criteria “Improvement available” is hidden for Topic versions assessed on an outdated dataset. After reassessment on the current dataset, the option is displayed according to the existing improvement logic. The behavior works for both automatic and manually created review sets.
Add Incremental retrieval for sessions
How can we retrieve only sessions or results changed since a specified timestamp? The updated_at field is empty in the current API responses.
In Progress
2Actively being built
Generative Topic automatically replaces original description with AI-generated version
Original Customer request При створенні нової генеративної тематики, система автоматично генерує її покращений опис і відразу приймає його до виконання, що позбавляє можливості використання оригінального опису. За посиланням надаю приклад на базі новоствореної тематики «Хамство» (тематика не запускається в Ендерах, створена як приклад для наочності помилки): When creating a new Generative Topic, the system automatically generates an improved version of the Topic description and immediately applies it. As a result, the original description entered by the user is replaced, and there is no option to keep or restore the original version. The AI-generated description should be treated as a suggestion rather than being automatically accepted. Current Behavior When a new Generative Topic is created: the user enters the Topic description; the system generates an improved description; the generated version is automatically applied; the original user-entered description is no longer available for selection. Expected Behavior The original description should remain unchanged unless the user explicitly chooses to replace it with the AI-generated version. When an improved description is generated, the user should be able to: keep the original description; or accept the generated version. The AI-generated description should not be applied automatically. Acceptance Criteria The original Topic description is preserved after AI improvement is generated. The generated description is applied only after explicit user confirmation. The user can continue creating the Topic using the original description.
Extend Charts to support Topic and Ender usage analysis
Extend the existing Charts functionality to provide visibility into Topic usage and allow comparison between Enders. No separate Usage tab or Topics Overview page is required. The required analysis should be available through the existing Chart tools. Required Changes 1. Topic Usage Analysis Add the ability to create analytical Charts using Topics and related Enders as dimensions / filters. Users should be able to analyze: how often a Topic is assigned to conversations; which Enders are associated with a Topic; Topic usage within a selected date range; Topic activity together with existing Chart filters and dimensions. Topics and Enders should be available as parameters when configuring a Chart, allowing users to build the required analysis using the existing analytics functionality. 2. Ender Comparison Add the ability to compare Enders within the same Chart. Users should be able to: select multiple Enders; compare their results using the same metric; group or split analytical results by Ender; apply existing filters and date ranges to the comparison. This should make it possible to compare how different Enders perform or how frequently they assign specific Topics. Expected Behavior Topic can be used as a Chart filter and/or grouping dimension. Ender can be used as a Chart filter and/or grouping dimension. Multiple Enders can be compared within the same analytical Chart. Topic and Ender parameters can be combined in one Chart. Existing date range and analytical filters continue to work with these parameters. Existing Chart export functionality is used without introducing a separate export mechanism. Acceptance Criteria Topic is available when configuring supported analytical Charts. Ender is available when configuring supported analytical Charts. Users can analyze conversation count by Topic. Users can analyze Topic usage by Ender. Users can compare multiple Enders within the same Chart. Topic and Ender dimensions can be combined with existing filters. Results respect the selected date range. Existing Chart export functionality works with the resulting analysis. Origin
Done
8Recently shipped
Export CSAT Dynamics and Interaction Intensity Dynamics values into separate columns
Update report export for CSAT Dynamics and Interaction Intensity Dynamics. Currently, each summary is exported into a single Excel cell as a structured JSON-like value containing multiple individual metrics. For analytical purposes, each value inside these summaries should be exported into its own separate column. Current Behavior CSAT Dynamics is exported as one column containing multiple values, for example: enter_CSAT exit_CSAT peak_CSAT other available CSAT Dynamics values Interaction Intensity Dynamics is also exported as one column containing multiple values, for example: enter_intensity exit_intensity peak_intensity intensity_indicators This makes further calculations and correlation analysis in Excel significantly more difficult. Expected Behavior Each individual metric contained in CSAT Dynamics and Interaction Intensity Dynamics should be exported as a separate report column. Example structure: CSAT Dynamics CSAT Dynamics - Enter CSAT CSAT Dynamics - Exit CSAT CSAT Dynamics - Peak CSAT separate columns for other available CSAT Dynamics fields Interaction Intensity Dynamics Interaction Intensity Dynamics - Enter Intensity Interaction Intensity Dynamics - Exit Intensity Interaction Intensity Dynamics - Peak Intensity Interaction Intensity Dynamics - Intensity Indicators The values should no longer require parsing a JSON structure from a single Excel cell. Expected Result Instead of: CSAT Dynamics | Interaction Intensity Dynamics containing structured data inside individual cells, the export should provide flat analytical columns that can be immediately used for: formulas; correlation analysis; filtering; pivot tables; external reporting. Acceptance Criteria Each CSAT Dynamics metric is exported into a separate column. Each Interaction Intensity Dynamics metric is exported into a separate column. Add a dedicated column to the report export - only if data present Values correspond to the correct conversation. Numeric values are exported as numeric values where applicable. Text values, such as intensity indicators, are exported into dedicated text columns. Missing values follow the existing export behavior for empty data. Exported fields can be used directly in Excel calculations without additional JSON parsing. Existing report filters and selected date ranges continue to apply to the exported data.
Add CSI as a separate column in report export
Add CSI (Customer Satisfaction Index) as a separate field in the report export. CSI data is already provided to EnderTuring together with telephony data and should be available as an independent column in exported reports. The purpose is to allow further analysis and correlation between CSI and other EnderTuring metrics, including CSAT Dynamics and Interaction Intensity Dynamics. Current Behavior CSI is received from the telephony source but is not available as a separate column in the exported report. Expected Behavior Add a dedicated CSI column to the report export. The exported value should correspond to the CSI value received for the relevant conversation/call. Acceptance Criteria CSI is available as a separate column in report export. Add a dedicated column to the report export - only if data present The field is included consistently for all records where CSI data is available. If CSI is not available for a conversation, the field remains empty or follows the existing platform behavior for missing values. CSI can be used together with other exported metrics for further external analysis.
Add a configurable filter for the last call in a repeat-contact chain
Add a configurable filter that allows users to determine whether a call is the last call in a customer’s repeat-contact chain. The filter should also support the reverse condition, allowing users to identify calls that were followed by another call from the same customer within the configured interval. This will allow users to separately analyze: calls that completed a repeat-contact chain; calls that resulted in a subsequent repeat contact. The second group can be used for further analysis of the root causes of repeat customer contacts. Business Goal Provide users with a flexible tool for analyzing repeat customer calls and identifying the position of each call within a contact chain. The filter should help users: identify calls after which the customer did not contact the company again within the defined period; identify calls followed by another customer call; analyze potential reasons for repeated contacts; apply different chain closure intervals depending on the required methodology. Recommended Filter Structure Filter Name Call chain position Available Values Last call in chain Followed by a repeat call Additional Parameter Chain closure interval Example: Call chain position: Last call in chain Chain closure interval: 72 hours If the existing filtering framework requires a Boolean structure, the filter may be implemented as: Filter Name Last call in chain Values Yes No Where: Yes means that no subsequent eligible call occurred within the configured interval; No means that another eligible call occurred within the configured interval. The explicit values Last call in chain and Followed by a repeat call are preferred because they make the filter behavior clearer to the user. Terminology Call Chain A call chain is a chronological sequence of eligible calls associated with the same customer. Calls should be linked using the customer identifier defined by the existing repeat-contact methodology. Chain Closure Interval The chain closure interval is the maximum time allowed between two consecutive eligible calls for them to belong to the same chain. The interval must be configurable and must not be hardcoded. Users should be able to specify any supported interval, for example: 24 hours; 48 hours; 72 hours; 7 days. Last Call in Chain A call is considered the last call in its chain when no subsequent eligible call from the same customer occurs within the configured interval. The call can only be confirmed as the last call after the full closure interval has elapsed. Followed by a Repeat Call A call is considered followed by a repeat when another eligible call from the same customer occurs within the configured interval. Calculation Logic Eligible customer calls should be grouped by the customer identifier and ordered chronologically. For each call, the system should check whether another eligible call from the same customer occurred within the selected chain closure interval. Last Call in Chain A call should match Last call in chain when: no subsequent eligible call exists within the confi
Show Total LLM Usage Cost to Usage page
Add a Total cost value to the Usage page so users can see the overall amount spent without manually summing the values from the Total column. The exact placement is flexible. The value can be displayed either: as a separate Total row in the usage table; or as part of the Monthly usage summary. The main requirement is to provide users with the automatically calculated total amount for the displayed usage data. Current Behavior The Usage page displays costs per individual row, but users must manually sum the Total column to calculate the overall cost. Expected Behavior The system automatically calculates and displays the total cost for the relevant usage period/data currently shown on the page. Acceptance Criteria The Usage page displays the automatically calculated total cost. The value matches the sum of the existing Total column. The total updates according to the currently displayed usage period/data.
Analytics charts: support an optional secondary time dimension
Add support for an optional secondary time dimension in Analytics Charts. Currently, users can group chart data by one primary dimension, but there is no convenient way to build a report where one axis contains business categories and the second axis contains time periods. This creates difficulties when users need to analyze a large number of categories over time. For example, if there are more than 100 Topics, manually creating a separate row or filter for each Topic is time-consuming and increases the risk of configuration errors. Required Behavior Users should be able to create a Chart where: one dimension represents a business entity, for example Topic; the second dimension represents time, for example Month. Example structure: Rows: Topics Columns: Months or vice versa: Rows: Months Columns: Topics The time dimension should support the existing available time grouping options, such as: Day Week Month other supported time periods The secondary time dimension should be optional and should not affect existing Charts that use only one grouping dimension. Example Use Case A user wants to analyze the structure of customer requests over a long period. Expected report: Rows: Topics Columns: Months Values: Number of conversations This should allow the user to compare Topic activity month by month without manually configuring each Topic separately. Expected Behavior Users can select a primary grouping dimension. Users can optionally add a secondary time dimension. The Chart automatically generates the required time buckets. Existing filters and date range settings continue to apply. The result can be viewed using the existing Chart reporting functionality. Acceptance Criteria A secondary time dimension can be added to supported Analytics Charts. Users can combine a business dimension, such as Topic, with a time grouping, such as Month. The time dimension is generated automatically based on the selected date range. Existing Charts without a secondary dimension continue to work without changes. Existing filters and export functionality continue to work with the new grouping.
Sync PR changelog back to linked Featurebase issue
Add automatic synchronization of developer changelog information from Git back to the related Featurebase issue. Git tasks linked to Featurebase contain the original Featurebase post URL at the bottom of the issue description. Example: This issue is linked to our feedback platform. For more details and updates, please visit [this link] (https://enderturing.featurebase.app/p/add-csi-as-a-separate-column-in-report-export). This URL should be used to identify the Featurebase issue associated with the Git task. Required Flow When a PR linked to a Git task is merged: Identify the Git task related to the PR. Read the Featurebase URL from the Git task description. Take the changelog prepared by the developer for the PR. Add the changelog to the linked Featurebase post as an update/comment. Expected Behavior Expected flow: Featurebase post → Git task → PR → Changelog → Featurebase post The Featurebase URL stored in the Git task should be used as the source of truth for identifying the related Featurebase issue. Acceptance Criteria The Featurebase URL is detected from the Git task linked to the PR. After the PR is merged, its changelog is added to the linked Featurebase post. If no Featurebase URL is present in the Git task, no Featurebase update is created.
Topic auto accuracy improvement
The customer, requests a list of tasks identified for further development and estimated delivery dates for this additional functionality. Specifically, the customer is awaiting the ability to generate new topic descriptions based on existing versions and the option to manually input relevant and irrelevant conversations. The customer states they have already prepared the conversations for input.
Add a restricted default Agent role
The current default Agent role includes permissions that are not required for regular call center agents. As a result, customers often need to create a separate custom role to restrict agent access. The default Agent role currently provides access to areas such as: team dashboard / team statistics; broader analytics; team information; EnderGPT. For a regular agent, the expected access scope is usually limited to their own data and training functionality. Required Changes Add a new default Agent role with restricted permissions. New default role: Agent The role should provide access only to: the agent's own dashboard and statistics; the agent's own conversations; training functionality available to the agent. The role should not provide access to: team dashboard or team-level statistics; other agents' data; general analytics; team management / team overview; EnderGPT configuration or other administrative functionality. Existing Agent Role The current Agent role should remain available to avoid affecting existing users and role assignments. Rename it to something that clearly indicates broader permissions, for example: Agent (Extended Access) Existing users assigned to this role should keep their current permissions after the change. Expected Behavior New customers can assign a standard Agent role without creating a custom restricted role. Agents with the new role can access only their own statistics, conversations, and training. Team-level and administrative data is not available to the restricted Agent role. The existing Agent role remains available with its current permission set. Existing role assignments are not changed automatically. Acceptance Criteria A new default Agent role with restricted permissions is available. The role provides access to the agent's own dashboard/statistics. The role provides access to the agent's own conversations. The role provides access to available training functionality. The role does not provide access to team-level dashboards or analytics. The role does not provide access to other agents' data. The existing Agent role remains available with the same permissions as before. Existing users do not lose or gain permissions automatically after the new role is introduced. The existing broader role is renamed to clearly distinguish it from the restricted Agent role. Origin