Verified purchaser
Promising concept, but not stable enough for production
I genuinely wanted this to work. The concept is strong, and the idea behind the product makes sense. On the surface, it looks promising.
However, after testing it in a real WordPress + Elementor environment, I ran into multiple issues that make it difficult to recommend at this stage.
First, the plugin caused frontend conflicts that took me nearly three hours to diagnose and fix. That’s not a minor inconvenience, that’s production risk. After spending that much time resolving issues introduced by the plugin, I’m not interested in reinstalling and testing again.
Second, the chatbot panel is not properly responsive. On mobile view, the layout breaks and the UI doesn’t adapt correctly. I provided screenshots showing this behavior. A chatbot in 2026 must be mobile-safe by default.
The bigger technical issue is how the script initializes.
The chatbot script initializes unconditionally and assumes a standard frontend DOM. When injected into a WordPress page builder template (e.g., Elementor), it also executes inside the editor iframe. The DOM structure and scroll context inside Elementor’s editor are different from the live frontend.
The script:
• Calls APIs like getComputedStyle
• Attaches global listeners
• Assumes elements exist without validation
• Does not detect environment context
As a result, it triggers runtime errors and interferes with layout rendering inside the builder.
There is no environment detection (frontend-only initialization) and no defensive DOM checks to prevent execution inside builders, admin views, or iframe contexts. That’s basic plugin hygiene for WordPress.
Additionally:
• Customer support response time has been slow
• No native human takeover functionality
• Requires third-party tools (e.g., Zapier) for human escalation
• Over-reliance on external integrations for core features
For a chatbot tool, native human handoff should not require external automation middleware.
I’m giving this 3 tacos because the core idea has potential. But in its current state, it feels early-stage and not production-hardened.
If the team improves environment detection, adds defensive scripting, fixes responsiveness, speeds up support, and builds native human takeover, this could become a strong tool.
Right now, it requires too much troubleshooting to feel reliable.
Daniel_NoemAI
Apr 10, 2026Hello,
Thank you for the detailed feedback. This is genuinely useful for our team. I am on the engineering support side and I want to address your technical points directly.
1. Elementor Editor and Script Initialization
Our WordPress plugin registers scripts via the wp_enqueue_scripts hook. This fires only on frontend page renders. Because Elementor’s "Live Preview" renders your page inside an iframe as a genuine frontend document, the script initializes there to show you what visitors will see.
Current Workaround: You can add "wp-admin" or "elementor" to the Blacklist Paths setting in your Noem.ai dashboard (Deploy tab) to hide the bot in those views immediately.
2. DOM Assumptions and Listeners
getComputedStyle: This is called within resize handlers only after the UI is rendered. It does not run at initial script load.
Listeners: Our postMessage listener validates the data type before acting to avoid interfering with other frame communications.
DOM Access: We only access document.body after the API configuration and domain authorization are confirmed.
We agree that adding a window.self !== window.top guard would be a helpful defensive improvement for these contexts.
3. Mobile Responsiveness
We would appreciate seeing the screenshots you mentioned. Our CSS uses fixed positioning and viewport-relative units, but Elementor’s custom breakpoints can occasionally conflict with these styles. Seeing your specific settings will help us reproduce and fix the layout regression.
4. Frontend Conflicts
Since our script is self-contained and does not use jQuery, conflicts are usually related to CSS specificity or script execution order from other plugins. We suggest using safe-mode from the design tab in noem.ai.
5. Human Takeover
You are right that native in-app human handoff is not a built-in feature. We do support Escalations to humans via email ot integrations.
6. Response Time
We apologize for the slow response. We are a small team try our best though that isn't an excuse and is not typical.
We want to make this right. If you are willing to give it another look, please email [email protected] with your staging URL and those screenshots. We will treat your case as a high-priority bug report.
Thank you for taking the time to help us improve.