Have something to say?

Tell us how we could make the product more useful to you.

Staff-facing default text option for Opt-in/Consent form

Use case: I use the Opt-in Page as a staff-entry tool, not a customer self-serve form. My clients' staff enter the customer's name and number themselves (after verbally asking permission), rather than the customer filling in their own details. The issue: The default welcome message and consent checkbox wording are written as if the customer is filling the form in themselves (e.g. "Enter your details below to receive...", "I agree to receive text messages..."). I've edited the welcome message to be staff-facing ("Enter the customer's details below..."), but the GDPR consent checkbox label is fixed and can't be edited — it still reads as if the person submitting the form (staff) is the one agreeing to receive texts, rather than confirming the customer agreed. Suggested fix: An option to toggle between "Customer self-serve" wording and "Staff-entry" wording for the consent checkbox — e.g. staff-facing version could read something like: "I confirm the customer has agreed to receive review request texts." This would remove the mismatch for anyone using the form the way I am, without affecting the self-serve use case for those who use it that way.

Dewayne Black 2 days ago

💡 Feature Request

Sales Agent Monthly Tracking _Revised

Please provide a way to adjust the monthly goals for sales agents. The ability to change the goal would allow us to have consistency across the board when it comes to our Sales Agents This request was submitted and completed prior to this. However, I realize now that I could have better articulated my specific requirements regarding goal settings. While the ability to adjust team goals on a global level is a great feature, I am looking for a way to set individual goals for each agent. This would allow us to assign loftier targets to certain team members based on their specific experience and job titles. Additionally, regarding SI reports, it would be beneficial if the system could automatically disable the ability to run new reports once a set limit has been reached. Implementing this restriction would be a significant help in managing our operational costs.

Review Pulse 360 2 days ago

💡 Feature Request

Restrict Sending Limits if too many errors triggered

Recently, I encountered with a user (premium plan) who uploaded a random downloaded list of emails to send requests. Due to that my Brevo account is temporarily restricted from sending transactional emails. This affected all my users. At EMR we also monitor error logs. So this could be a possible solution. The idea is: Restrict user accounts from sending emails, if too many errors occur linked to their account. Show a warning message/banner “Your account is temporarily restricted from sending Email requests. Contact support to reactivate your account. We can lift the restriction and reactivate from the customer management page. Make hourly sending limits as default setting for every customer, or with a modification option in the customer management page setting.

Arun Saini 2 days ago

💡 Feature Request

Before / After — UI dashboard exploration for Embed My Reviews

Exploring an alternative design direction This document presents a UI exploration intended to spark discussion and gather feedback. EMR already delivers a comprehensive set of features. This idea simply explores whether a different visual hierarchy, information architecture and visual language could make the experience feel calmer, easier to scan and more distinctive. Current experience The current dashboard surfaces a rich amount of information and gives visibility to many aspects of review management from the first screen. This exploration looks at an alternative way of presenting that information by adjusting visual hierarchy and reducing the number of elements competing for the user's attention at any given moment. Proposed direction The concept is organized around a single primary focal point—the overall rating—followed by three sections that reflect a salon owner's natural workflow: Where I stand — overall rating and milestone progress. How I'm collecting reviews — conversion funnel, review pace and AI insights. How I'm performing on Google — listing performance, trends and search visibility. Rather than introducing additional components, the proposal focuses on clarifying hierarchy and making it easier to understand what deserves attention first. The existing gamification experience is still present but expressed through a quieter circular progress indicator, allowing it to support the experience without becoming the dominant visual element. Why explore warm neutral tones? One aspect of this exploration is the use of a warm taupe/off-white background instead of a pure white canvas. I don't know if you've noticed : For exemple Granola (AI Note taker)

Jean-Gabriel 3 days ago

📥 Feedback

Subscription progress bar retains old plan quota after Stripe plan change

Summary On the agency dashboard, the Subscription progress bar continues to show the original plan's quota after a customer is moved from Free to a paid plan (Solo/Pro) via the native Stripe integration. The bar does not pick up the new plan's limits, while the "Available" figure displays correctly. Workflow context (how affected accounts are created) Demo accounts are created on the Free plan (50 SMS / 200 email credits) to avoid limits during demos. No freemium is offered. On signing, the client is switched to Solo (150 SMS/month) or Pro (250 SMS/month) through the native Stripe integration in EMR. Affected clients all followed this Free → paid path. Expected behavior After a Stripe plan change, the Subscription bar should reflect the new plan's quota (e.g. 150 or 250 SMS). Actual behavior The Subscription bar keeps the original plan's quota (Free = 50, or a previously higher quota), shown in red as "maxed out", even though credits remain available. The "Available" tooltip confirms it includes subscription credits + top-ups, and customer-level limits are correct (Solo/Pro limits apply, sending works). The issue appears purely on the agency-side display. Likely root cause (hypothesis) The Subscription progress bar's denominator is cached/persisted from the original plan and is not refreshed when the Stripe subscription transitions to a new plan. Related question Could this be linked to accounts simultaneously showing "Trial Expired" and "Active Subscription"? This combination appears on some of the same clients (e.g. Le W / William Rubinstein), which may share the same plan-transition state. Impact No functional impact — sending is unaffected. The inconsistency makes credit monitoring confusing on the agency side.

Jean-Gabriel 4 days ago

🐛 Bug Reports

Feedback From "contact us directly" toggle off

The Problem: Currently, the “Contact us directly” (private feedback) section is always visible in the Review Sites funnel. While this works for some setups, it creates significant UX and legal challenges for agencies: 𝗖𝗼𝗻𝘃𝗲𝗿𝘀𝗶𝗼𝗻 & 𝗨𝗫 𝗙𝗿𝗶𝗰𝘁𝗶𝗼𝗻:: When review gating is turned off, this button is often unnecessary and visually too dominant. It draws valuable customer attention away from public review platforms (Google, Trustpilot, etc.), which are usually the primary action we want customers to take. 𝗦𝘁𝗿𝗶𝗰𝘁 𝗟𝗲𝗴𝗮𝗹 & 𝗚𝗗𝗣𝗥 𝗖𝗼𝗺𝗽𝗹𝗶𝗮𝗻𝗰𝗲 (𝗘𝗻𝘁𝗲𝗿𝗽𝗿𝗶𝘀𝗲/𝗘𝗨): For larger clients, enterprise chains, and EU-based companies, their internal legal teams strictly enforce GDPR. Because private feedback data is stored on the platform's/agency's backend, the platform is viewed(by them) as an un-audited third party. Many legal departments strictly forbid any private user data from being captured or stored here unless the platform passes a their security audit. 𝘾𝙎𝙎 𝙒𝙤𝙧𝙠𝙖𝙧𝙤𝙪𝙣𝙙𝙨 𝙖𝙧𝙚 𝙐𝙣𝙧𝙚𝙡𝙞𝙖𝙗𝙡𝙚: While the button can be hidden using custom CSS, it is nor a scalable or reliable solution. Non-technical DIY clients cannot do this, and agencies managing multiple templates find that users frequently forget to copy the CSS over, accidentally exposing the private feedback form and triggering legal/compliance risks. 𝗦𝘂𝗴𝗴𝗲𝘀𝘁𝗲𝗱 𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻: Add a possibility for the agencey to toggle of using this button option from a client, which would hide this feature completly from the client. When the button is show, the client could toggle it on / off is they want. Expected Behavior when Toggled "OFF": Hide the “Your experience was not great?” text. Hide the “Contact us directly” button completely. Automatically collapse the layout to remove empty spacing so the design remains clean. 𝗞𝗲𝘆 𝗕𝗲𝗻𝗲𝗳𝗶𝘁𝘀: 𝗟͟𝗲͟𝗴͟𝗮͟𝗹͟ ͟𝗖͟𝗼͟𝗺͟𝗽͟𝗹͟𝗶͟𝗮͟𝗻͟𝗰͟𝗲͟:͟ Allows agencies to instantly onboard larger clients and corporate chains with strict legal/GDPR requirements without undergoing lengthy, non-negotiable technical security audits with agency (->EMR). Improved Conversion: Focuses 100% of the user's attention on public review platforms when private feedback is not desired. Agency Scalability: Removes the friction of relying on custom CSS, ensuring consistency across Feedback Form templates and preventing accidental template breaks by non-technical users. Flexibility: Keeps small businesses happy (who may want the option) while protecting agencies serving larger (enterprises, chain businesses) compliance-heavy/savvy clients.

S.M 16 days ago

3

💡 Feature Request

Global Disable Option for Trustpilot Review Display (Agency Level)

1. Objective Implement a new feature within the agency-level administration panel to globally disable the display of Trustpilot reviews in all reputation widgets. This change must be strictly surgical: the ability to request/collect Trustpilot reviews (via automated email or SMS workflows) must remain fully active, but their visual rendering within widgets embedded on client websites must be blocked. 2. Technical Description and System Behavior UI Location: Agency Settings Panel Visual Component: A logical toggle switch labeled: "Allow Trustpilot reviews to be displayed in widgets". System Behavior: Enabled State (Default): Current software behavior is maintained. Trustpilot reviews are fetched and displayed in the widgets of all sub-accounts. Disabled State: The system immediately stops rendering any reviews originating from Trustpilot across all widgets generated by the software for any agency client. Previously stored Trustpilot reviews in the database must be retroactively hidden from widgets. The automation workflow for sending collection links (review requests directing the end-consumer to the company's Trustpilot page) continues to function normally. 3. Justification and Legal Implications (Critical Risk Mitigation) Displaying Trustpilot data through third-party widgets poses a severe and immediate legal risk to the agencies. Trustpilot aggressively protects its business model based on intellectual property and database rights (Sui Generis Right). The platform explicitly prohibits the display of reviews, TrustScores, or stars outside of their official widgets (TrustBoxes). Real-World Market Precedents and Legal Actions: The Reputon Precedent (Forced Removal): The reputation management brand Reputon was targeted with legal measures and Cease and Desist notices by Trustpilot's lawyers due to its application "Trustpilot Reviews by Reputon". As a direct consequence of this legal pressure, the display app was entirely removed from the Shopify App Store. The Elfsight Precedent (Lawsuit): Trustpilot has successfully pursued formal legal action against other major widget software providers (such as Elfsight) for creating unauthorized display extensions, resulting in restrictive court injunctions and brand damage payouts. The London Intellectual Property Court Case: Trustpilot states that it successfully sued a well-known fake widget provider in the Intellectual Property Enterprise Court in London in 2022 and obtained an order preventing unauthorized display of Trustpilot stars. Active "Whistleblower" System: Trustpilot has implemented a dedicated global reporting channel for "Fake TrustBoxes." Through this system, competitors or users can anonymously report any website displaying reviews outside the official ecosystem, accelerating automated legal action. 3.1. Why the Target is "Display" (Frontend) and not "Scraping/Fetching" (Backend) Market analysis and developer consensus show that Trustpilot rarely initiates litigation over data fetching or scraping itself, but strikes with maximum force against visual widgets. This strategic enforcement is driven by four factors: The Burden of Proof (Invisible vs. Public): Scraping happens silently on the backend (server-to-server) and can be easily masked using proxies and rotating user-agents, making it technically difficult for Trustpilot to legally link the scraping activity to a specific compan

Leandro Teixeira about 1 month ago

3

💡 Feature Request