Kristine Risberg

Enhancing Email Activity Statuses for Improved Collaboration in Customer Service

Background: 

In our use of both Customer Service and Omnichannel for Customer Service, we have identified a key limitation in the email activity handling, specifically related to the status reasons available for inbound emails. Currently, when an inbound email is received, the status is limited to “Received,” whether or not the email has been replied to. This limitation creates inefficiencies and challenges for teams collaborating in the Customer Service Inbox, as it becomes difficult to distinguish between emails that have been handled and those still requiring action.

Current Challenge:

• Inbound emails only display the status “Received,” even after an agent has responded to the email.
• The lack of visibility into whether an email has been responded to, and when it was responded to, makes collaboration across teams cumbersome. Agents have to manually check or rely on inefficient workarounds to determine which emails have been handled.
• This issue is particularly problematic for teams working in a shared inbox environment, as it hinders transparency and prevents effective task management. 
• Email response time is impractical to calculate based on the email activity's "Modified on" date since this parameter is affected by all types of adjustments, thus becoming unreliable in this specific context. 

Proposed Solution:

• We recommend adding an additional status reason to the inbound email activity that would update automatically when the corresponding outbound email activity (response) reaches the status of "Sent." For example, the inbound email status could be updated from "Received" to "Replied to" when the system detects that a response has been successfully sent. The replied to date should be saved and visualized on the activity record. 

Key Benefits:

• Improved Collaboration: This feature would give agents and teams immediate visibility into which emails have been handled, improving transparency and reducing the likelihood of missed or duplicated responses.
• Enhanced Workflow Efficiency: Teams can quickly filter and organize emails in the Inbox based on whether they have been responded to, which is not possible in today's setup. 
• Accurate Email Status Tracking: Adding more granular status reasons and visualization of when the email was responded to ensures more accurate tracking of each email's lifecycle, from reception to resolution.
• Streamlined Filtering and Reporting: This change would enhance the ability to set up filters and reports to track email responses and response times, thus improving overall service management.

How it Would Work:

• When an inbound email is received, it retains the status “Received.”
• Once an outbound email is sent (with a matching thread ID), the system automatically updates the inbound email’s status to “Replied to" and saves the date of when the reply was made. 
• This status update is triggered when the corresponding outbound activity reaches the "Sent" status.

Conclusion:

By introducing additional status reasons for inbound email activities, particularly a "Replied to" status, Microsoft can enhance collaboration, transparency, and efficiency for users of the Inbox. This improvement would help teams work more seamlessly, ensuring better customer service outcomes.

Suggestion: Channel-Specific Customization of Automated Messages in Secondary Languages for Omnichannel for Customer Service

Overview:

In Omnichannel for Customer Service, automated voice channel messages can currently be customized on a channel-by-channel basis, in the channel's primary language. However, this flexibility does not extend to automated messages in secondary languages, where changes must be made at a generic message level. This limitation forces uniformity across all channels using the same secondary language, creating difficulties for departments that need to convey specific information to their customers.

Impact:

This limitation hinders the ability of teams to deliver personalized experiences in secondary languages. For example, in a multinational organization where different teams serve different regions or services, the inability to customize automated messages per channel in secondary languages can result in:

- Confusing or irrelevant messaging for customers.

- Reduced efficiency in customer communication.

- Difficulty in complying with local regulations or providing culturally appropriate information.

Proposed Enhancement:

Enable customization of automated messages in secondary languages on a per-channel basis, similar to how it is currently possible with primary language messages. This would allow each department, team, or channel to:

- Provide relevant and specific information to their customers in the appropriate language.

- Ensure that messages are tailored to the customer’s region, service, or inquiry type.

- Maintain consistency and clarity in communication across multiple languages while preserving flexibility at the channel level.

Benefits:

- Enhanced customer experience through more accurate, relevant communication.

- Improved operational efficiency by aligning messaging with department-specific needs.

- Increased flexibility in managing multilingual support channels, allowing organizations to deliver better service to global customers.

Currently, when managing KB articles, agents must manually translate content from a parent article to its linked version. This process is time-consuming and prone to inconsistencies. With the increasing capabilities of AI and automation tools, there is an opportunity to enhance this process by utilizing Copilot in CS to automatically translate KB articles and generate draft translations for linked versions, significantly improving efficiency and consistency in multilingual support.

The current manual process poses several challenges:

- Agents spend considerable time translating content, which could be better utilized on higher-value tasks.

- Variations in translation quality and style can lead to inconsistent customer experiences across languages.

- The need for manual updates to multiple language versions of KB articles increases the risk of errors and delays when parent articles are updated.

Proposed Enhancement:

Enable Microsoft Copilot within Customer Service to automate the translation of KB articles when working with version handling. This enhancement would allow Copilot to generate a draft translation for a linked KB article based on the content of the parent article, thus providing agents with a solid starting point for review and fine-tuning, improving both speed and accuracy.

Automating the translation process would save agents considerable time and help ensure consistency in terminology and style across all versions of KB articles, leading to a more cohesive customer experience in different languages.

Currently, Copilot in Customer Service allows agents to generate conversation summaries either on demand during an active session or automatically at the end of a conversation. However, once a conversation is closed, agents can no longer generate a summary. This limitation can hinder agents who need to revisit the contents of older conversations to create new cases or update existing ones.

The lack of conversation summarization for closed sessions leads to several challenges such as users having to manually review entire conversation transcripts to gather key information leading to potential delays in case resolution, adding to the overall workload.

Expanding the conversation summarization capabilities to closed conversations would greatly enhance efficiency and accuracy in case handling. This feature would allow agents to generate a summary of closed conversations on demand, provide flexibility in retrieving relevant information from historical interactions without needing to manually sift through entire chat logs and thus being able to create or update cases more efficiently by getting a swift overview of prior conversations.

By enabling conversation summarization for closed conversations, Copilot in CS will provide agents with a powerful tool to revisit and utilize past interactions more efficiently.

Improvement Suggestion for Case Origin Logic in Quick Create Case Form

When creating a new case from an active conversation using the +New Case button, I am directed to the Quick Create Case form. In this form, certain fields such as the related Customer, Case Owner, Case Priority, and Case Origin are pre-populated with values derived from the active conversation. However, the Case Origin field is automatically set to "Web" regardless of the channel used for the conversation (e.g., live chat, voice call, SMS).

 If no default value is set in Entity Meta Data for Case Type Incident when getting data from Channel Integration Framework, the system assigns the value of 'caseorigincode' attribute as Web. This is set irrespective of channel type on the live work item. This requires manual, an unnecessary, adjustment by the agent every time a case is created from a conversation.

Suggested Solution:

A permanent and reliable solution would be to ensure that the Case Origin field dynamically reflects the channel type at the time of case creation, rather than defaulting to "Web." While the current workaround (e.g., using a post-operation plugin on the Retrieve or RetrieveMultiple messages to modify the returned entity) can address this issue, a built-in solution that automatically matches the Case Origin to the channel type would significantly improve the user experience and eliminate the need for custom development.

Benefit:

This improvement would ensure better consistency between the communication channel and the case metadata, reducing the need for manual adjustments and offering a more seamless case creation process.

Currently, Dynamics 365 Customer Service allows administrators to set file size limits for attachments through a global system setting. This setting was originally designed for the email channel, where large attachments such as documents, reports, and PDFs are often required. However, with the expansion of Omnichannel for Customer Service, multiple new communication channels (including SMS and chat) now rely on the same file size configuration. This results in an inefficiency where large attachment size limits necessary for email are unnecessarily applied to SMS, which typically supports much smaller file sizes.

Proposed enhancement: Introduce a per-channel file size limit option. A channel-specific file size limit setting for attachments where administrators can define different maximum file sizes per communication channel (e.g., SMS separately from emails). Specifically for SMS, where file transmission capabilities are significantly limited by mobile carrier restrictions, the ability to configure an appropriate lower file size threshold would prevent system inefficiencies and improve the customer experience.

Key use cases:

• Organizations may allow large attachments (e.g., 10-20MB) via email for reports and documents.
• However, for SMS, the same file size limit is unnecessary, as most carriers impose strict limits (e.g., 600KB - 1MB) on attachments.
• Without channel-specific settings, SMS attempts to send files that are too large, leading to delivery failures or excessive mobile data usage.
• A configurable setting per channel would allow businesses to control and optimize file transmission based on the capabilities and best practices of each channel.

Benefits

✅ Improved Reliability – Prevent failed SMS deliveries due to oversized attachments.

✅ Better Compliance & Cost Efficiency – Avoid unnecessary mobile data consumption when sending attachments via SMS.

✅ Enhanced Admin Control – Gives organizations more granular control over their Omnichannel settings, improving operational flexibility.

✅ Seamless Customer Experience – Ensures customers receive attachments suited for each channel, avoiding frustration caused by delivery errors.

This enhancement would provide greater flexibility, prevent unnecessary errors, and align attachment handling with industry standards for each communication channel. By making file size limitations configurable per channel, D365 Customer Service will better serve organizations managing multi-channel digital interactions efficiently.

In Copilot for Service, there’s currently a disconnect between the different knowledge-grounding experiences used in the 'ask a question' and 'draft an email' features:

• When using internal knowledge base articles (from Dynamics 365), these are available in both features.
• When adding a trusted website via the Copilot Service admin center, this is only accessible when drafting emails – not when using 'ask a question'
• Conversely, if I configure a Copilot Studio model with that website as a knowledge source in the Knowledge Hub, then the website becomes accessible in 'ask a question' — but no longer works for generating replies via the email composer.

This creates two separate knowledge source configurations for two different Copilot experiences (although in the same Copilot model) in the same application, which is confusing for end-users and inefficient for administrators.

Please unify the knowledge grounding mechanism between the 'ask a question' and 'draft an email' features so that KB articles and trusted websites can be used across both features. This would drastically improve usability and reduce redundant content maintenance across two tools.