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.