Private Feedback Notifications: Dynamic "Reply-To" Header + Automated Status Sync + Message Content Logging

Problem Statement: Standard private feedback notifications currently use a static ESP system email (repliesESP@mySaaS.com) in the Reply-To header. This prevents support teams from replying directly to customers, forcing agents to manually copy-paste the customer's email address.

Proposed Solution: Implement a dynamic Reply-To header that uses the respondent's email address. To ensure this does not interfere with existing configurations for other Agencies/WL-SaaS, this feature could be disabled by default.

UI Configuration & Path:

The setting could be located under the form customization settings:

• Path: Feedback Forms > Content & Flow > Private Feedback

• Feature Toggle: "Advanced Direct Customer Reply by Email"

• Description: "When enabled, replying to a private feedback email notification will go directly to the customer's email address instead of the system default."

Technical Requirements:

• Default State: Disabled (Off).

• Logic: If Enabled, the SMTP Reply-To header must be populated with the value from the {Email} field submitted in the feedback form. If Disabled, it should fall back to the current system default.

Phase 2:

Automated "Replied" Status Sync

To avoid manual status updates inside EMR, can we implement an Email Proxy/Relay?

• Logic: Instead of the customer's direct email, the Reply-To would be a unique system-generated alias (e.g.,{feedback_id}@reply.revw.me).

• Action: When the server receives an email at this alias, the system should: 1. Parse the feedback_id and change the status of that entry to "Replied". 2. Forward the email content to the actual customer's email address.

This would create a seamless loop where the software tracks external email interactions automatically.

Phase 3:

Message Content Logging:

• Action: When the system receives the proxy email, it should also parse the body of the reply.

• Goal: Store the agent's response text within the EMR database so the conversation history is visible in the dashboard.

• Requirement: Implement logic to strip signatures and original notification text to log only the new content.

If needed, we can start with Phase 1 and 2 to solve the immediate workflow pain, leaving the content parsing for a later sprint.