# User Feedback Analysis — 2026-02-13 (based on 2026-02-10 to 2026-02-12 community + GitHub signals) ## 1) Pain Point Categorization (Top recurring friction areas) ### A. Documentation (High frequency, high severity) **Recurring problems** - **Hidden/implicit build steps**: `plugin-n8n-workflow` fails to build locally unless users run a `crawl` script to generate JSON files (`defaultNodes.json`, `schemaIndex.json`, `triggerSchemaIndex.json`) that are intentionally not committed. This surfaced as TypeScript “missing JSON module declarations” errors and blocked onboarding to the plugin. - **Roadmap discoverability**: users repeatedly asked where the roadmap is and noted it is hard to find via “standard research”/Google, even though it exists on GitHub (`elizaos/roadmap`). - **Unclear “what is production-ready vs WIP”**: users suggested labeling ElizaCloud as beta due to UX/payment bugs; expectations appear mis-set for non-coders evaluating the product. **Example(s)** - Stan ⚡ explained the crawl-generated JSON/CI behavior after Odilitime hit build errors. - yojo reported roadmap discoverability issues during investor-style research. --- ### B. UX/UI (High frequency, high severity for ElizaCloud adoption) **Recurring problems (ElizaCloud.ai)** - **Billing/recharge confusion and failures**: recharging while on VPN fails for some users; “how to add USD” is unclear in the UI. - **Account creation bug**: double account creation for a single email, triggering the $5 welcome bonus issue. - **Plugin discovery is poor**: users struggle to identify “reliable plugins” and want guided recommendations / “App Store-like” marketplace experience. - **Onboarding friction in Discord**: at least one user thought the server was “dead” because they couldn’t see messages until verification. **Example(s)** - yojo’s market research with **5 potential non-coding investors** found multiple blockers (billing, plugin discovery, audience confusion). While exact per-issue incidence wasn’t quantified, **100% (5/5)** encountered enough friction to report negative usability signals. - Kenk had to tell a user to verify to see messages. --- ### C. Technical Functionality (Medium frequency, high severity when hit) **Recurring problems** - **Token migration support latency**: users who missed the AI16z → ElizaOS migration window opened tickets (e.g., ticket-0550) and reported waiting **> 1 week** for response. - **Message handling defects impacting cost/UX** (GitHub): open bug report that sending a URL triggers **duplicate LLM calls** (processed as both text and attachment), doubling cost and duplicating output. - **Provider flexibility gaps** (GitHub): feature request to support **custom OpenAI-compatible endpoint URLs** (e.g., SiliconFlow) rather than hardcoding official OpenAI endpoints. **Example(s)** - kwi_viet waiting on ticket-0550; Sim also missed the migration window. - GitHub issues: duplicate URL processing (#6486), custom endpoint request (#6490). --- ### D. Integration (Medium frequency, high severity for competitive positioning) **Recurring problems** - **Competitive onboarding gap vs OpenClaw**: requests for a “4-minute wizard” setup experience and integrations like **WhatsApp/Telegram**. Users explicitly compared ElizaOS unfavorably on ease-of-setup and integrations. - **Workflow automation fragmentation**: duplicated n8n plugin repos (`plugin-n8n` vs `plugin-n8n-workflow`) created confusion about “which one is real,” plus extra maintenance cost. **Example(s)** - DorianD compared OpenClaw’s wizard + WhatsApp/Telegram to ElizaOS. - Core-devs decided consolidation is needed; Stan ⚡ argued `plugin-n8n-workflow` is the better canonical choice. --- ### E. Community (High frequency, medium severity; becomes high severity when it drives FUD) **Recurring problems** - **Irregular updates → FUD susceptibility**: multiple users complained that month-long communication gaps create vulnerability to social-media FUD and uncertainty about project viability/utility. - **Support safety/scam risk**: users were warned not to follow random DMs for migration support; this keeps recurring in token communities. **Example(s)** - Debate on weekly scheduled updates vs milestone-only communication (yojo vs Kenk positioning). - Hanzla Mateen warned Sim about scam redirection. --- ### F. Performance / Cost (Medium frequency, high severity for cloud economics) **Recurring problems** - **Unnecessary LLM spend**: duplicate calls on URL messages (GitHub #6486) directly doubles token costs. - **Users increasingly ask “how do we stop the bleeding?”**: price talk is not purely market sentiment—users connect it to lacking “measurable product metrics” and perceived weak value capture. **Example(s)** - “How do we stop the bleeding?” (Rainman) and repeated concern that other AI tokens are ATH while Eliza is down. --- ### G. Expectation Management (Cross-category, high frequency, high severity) **Recurring problems** - **Babylon timeline confusion**: users asked for Babylon airdrop timing; Odilitime had to clarify **no token exists yet** and ICO is **at least a couple months away**, and that **non-chain launch ≠ token launch**. - **Babylon vs Eliza token value linkage**: users expected Babylon success to lift Eliza token; community members clarified that may not be true. - **NFT utility uncertainty**: multiple unanswered questions about the future of the Eliza NFT collection(s) and naming/royalty structure after ai16z transfer. **Example(s)** - DannyNOR’s airdrop assumption; Odilitime’s correction. - Adaptati0n’s unanswered NFT collection questions. --- ## 2) Usage Pattern Analysis (actual vs intended use) ### What users are doing in practice - **ElizaCloud.ai is being evaluated by non-coders/investors**, not just builders: yojo’s “5 non-coding investors” test suggests ElizaCloud’s first impression matters for capital + ecosystem growth, even if the “intended” audience is developers. - **Agents are being used for real integrations and ops automation**: - n8n workflow generation and redeployment is emerging as a “core automation lane.” - Twitter plugin is being adopted by external agent stacks (OpenClaw) because it is perceived as safer/higher quality. - **Users want wallets as a first-class agent primitive**: discussions center on agent wallet provisioning and security boundaries (Privy OAuth app approach vs HD wallets). ### Emerging / unexpected use cases - **“Proof-of-agent” / task-based registration**: DorianD’s idea of agents completing coding tasks to earn access keys suggests a future pattern: automated capability checks for access provisioning. - **Gaming/consumer agents**: Babylon as a game catalyst, plus “computer takeover/system commands” assistant demos—users are looking at ElizaOS for consumer-grade agents, not only dev frameworks. ### Feature requests aligned with observed usage - **Guided plugin selection / marketplace UI** aligns with non-coder evaluation + “I just want it to work” users. - **OpenAI-compatible endpoint configuration** aligns with developers optimizing cost/performance by shopping inference providers. - **Wizard-based onboarding + WhatsApp/Telegram** aligns with the “ship an agent quickly” workflow users are benchmarking against. --- ## 3) Implementation Opportunities (solutions per major pain point) ### 1) ElizaCloud billing + onboarding friction (UX/UI) **Proposed solutions (prioritized)** 1. **High impact / Medium difficulty**: Add a single “Add funds” flow with explicit steps + inline validation - Show: balance → payment method → amount → confirmation → expected settlement time. - Detect VPN/payment failures and show actionable errors (not silent failure). - Similar pattern: Stripe-hosted checkout + clear post-payment state; Vercel billing UI clarity. 2. **High impact / Low difficulty**: Add “Beta” labeling + known-issues banner + status page link - Reduces expectation mismatch and support churn. - Similar pattern: Linear/Notion early access messaging; OpenAI status communications. 3. **Medium impact / Medium difficulty**: Fix duplicate account creation / welcome bonus issuance with idempotency keys - Ensure email-based signup is idempotent; enforce uniqueness at DB + API layer. --- ### 2) Plugin discovery + “which plugin is canonical?” (Integration + UX) **Proposed solutions** 1. **High impact / Low difficulty**: Officially designate canonical repos (e.g., `plugin-n8n-workflow`) and archive/redirect duplicates - README banners: “This repo is deprecated → go here.” - Similar pattern: Kubernetes SIG repo deprecations; Homebrew formula taps redirects. 2. **High impact / Medium difficulty**: Add a curated “Recommended plugins by use case” page inside ElizaCloud dashboard - “Social agent,” “Trading agent,” “Workflow automation,” etc. - Similar pattern: Supabase “Integrations” gallery; VS Code recommended extensions. 3. **Medium impact / Higher difficulty**: Build an “App Store-like” plugin marketplace with trust signals - Signals: maintainer verified, CI passing, last release date, install count, “works with v1/v2”. - Similar pattern: Grafana plugin catalog; Home Assistant integrations directory. --- ### 3) Build/documentation footguns (Documentation) **Proposed solutions** 1. **High impact / Low difficulty**: Preflight script + clearer failure mode - On `bun install` or `pnpm dev`, detect missing JSON and print: “Run `bun run crawl` (why + link).” 2. **Medium impact / Medium difficulty**: Add a “local dev quickstart” that mirrors CI steps exactly - A `make dev`/`task dev` that runs crawl and sets env defaults. 3. **Medium impact / Higher difficulty**: Publish generated artifacts as a versioned package - e.g., `@elizaos/n8n-schema-index` so local dev doesn’t require crawling unless updating schema. --- ### 4) Token migration support backlog (Community + Technical Functionality) **Proposed solutions** 1. **High impact / Low difficulty**: Public SLA + queue visibility for migration tickets - Even “72 hours” guidance reduces repeated pings. 2. **High impact / Medium difficulty**: Self-serve migration verification tool - User enters tx hash/wallet; system validates eligibility and auto-queues. - Similar pattern: Arbitrum airdrop eligibility checkers; bridge claim verifiers. 3. **Medium impact / Medium difficulty**: Add an in-dashboard support widget for ElizaCloud + token support - Helps non-Discord users; reduces scam exposure. --- ### 5) Agent wallet architecture decision (Technical Functionality) **Proposed solutions** 1. **High impact / Medium difficulty**: Adopt **HD wallet** strategy as default with well-defined derivation paths per agent/subagent - Clear threat model + rotation guidance. - Similar pattern: BIP-32/44 standard derivation; Coinbase Wallet SDK patterns. 2. **Medium impact / Medium difficulty**: Optional “Privy-managed” mode for teams needing OAuth flows - Keep HD as baseline; Privy for enterprise convenience. 3. **Medium impact / Low difficulty**: Publish a reference implementation + cookbook - “Subagent signup,” “user wallets,” “treasury separation,” “spending limits.” --- ### 6) Communication cadence + expectation mismatch (Community) **Proposed solutions** 1. **High impact / Low difficulty**: Weekly “What shipped / what’s next / known issues” post (even if short) - Include Babylon timeline clarifications, migration status counts, and top PRs. - Similar pattern: Rust “This Week in Rust”; Base ecosystem weekly recaps (community referenced this explicitly). 2. **Medium impact / Medium difficulty**: Automated changelog agent (yojo’s proposal) with PAR format - Generate channel-specific summaries (Discord, X, dashboard). 3. **Medium impact / Low difficulty**: Pin a “Babylon: non-chain vs chain/token” FAQ + “No token yet” banner - Reduces repetitive airdrop questions. --- ## 4) Communication Gaps (expectations vs reality) ### Where expectations don’t match reality - **Babylon airdrop/token timing**: users assumed an imminent airdrop; reality is “no token yet; ICO months out; only non-chain launch soon.” - **Babylon success → Eliza token benefit**: users expect direct value accrual; community members cautioned it may not directly benefit Eliza token holders. - **ElizaCloud target audience**: repeated confusion whether it’s for coders or non-coders; UX currently fails non-coders early (billing, plugin selection). ### Recurring questions indicating doc/onboarding gaps - “Where is the roadmap?” (asked multiple days) - “How do I recharge / add USD?” (cloud UI confusion) - “Which n8n repo should I use?” (duplication) - “How do I migrate after missing the window?” + scam-risk confusion ### Specific improvements to align expectations - Add **first-run “Choose your path” onboarding**: “Developer / Non-technical / Investor” that changes what the UI emphasizes. - Put “Beta” + “Known issues” + “Status” directly in dashboard. - Create a single canonical “Token / Migration / Babylon / NFTs” FAQ page and pin it in Discord + link from dashboard. --- ## 5) Community Engagement Insights ### Power users (and their needs) - **yojo**: strong product/UX signal source; wants measurable growth metrics, weekly comms, in-dashboard updates, plugin marketplace UX. - **Stan ⚡**: deep workflow automation contributor; needs repo consolidation clarity and smooth dev/build experience for `plugin-n8n-workflow`. - **Odilitime**: core implementer across cloud/auth/wallet decisions; needs structured intake to avoid being the bottleneck for support and roadmap questions. - **DorianD**: competitive analyst; pushes for onboarding wizard, integrations, and agent-access automation (SIWE/proof-of-agent ideas). - **azsxdc**: integrator exporting Eliza plugins into other ecosystems (OpenClaw), indicating cross-framework adoption potential. ### Newcomer questions that indicate onboarding friction - Discord verification gating (“server is dead” perception). - Token migration how-to and legitimacy verification (wallet address legitimacy concerns). - Basic “where is roadmap / where are updates.” ### Converting passive users into contributors - Create “Good first issues” specifically for: - Docs fixes (roadmap discoverability, Babylon FAQ, n8n crawl preflight messaging) - ElizaCloud UX tasks (billing copy, VPN error surfacing) - Add a lightweight contributor pathway: “Pick a lane (Docs / Cloud UX / Plugins / Integrations)” with maintainers listed and response-time expectations. --- ## 6) Feedback Collection Improvements ### Current channel effectiveness - **Discord** is effective for rapid clarification (e.g., Babylon token timing, n8n build fix), but: - Repeats the same questions due to poor discoverability/pinning. - Mixes product feedback with token price sentiment, making it harder to triage. - **GitHub issues** capture technical bugs/feature requests well (e.g., duplicate LLM calls, custom endpoint), but: - Non-coders/investors are unlikely to file issues, so key UX problems may remain anecdotal unless proactively collected. ### Recommendations for more structured, actionable feedback 1. **In-product feedback widget (ElizaCloud)**: capture “what were you trying to do?” + screenshot + category. 2. **Monthly structured survey** targeting: - Non-coders evaluating the dashboard - Builders integrating plugins (n8n, Twitter, wallets) 3. **Discord intake templates**: - `/bug` and `/support` forms that auto-create GitHub issues (or at least a triage log) with tags. ### Underrepresented segments - **Non-Discord ElizaCloud users** (especially non-coders) — currently only visible via ad-hoc interviews (yojo’s sample of 5). - **Enterprise/teams** evaluating auth/isolation and billing — hinted by JWT/SIWE and multi-tenant discussions, but little direct feedback captured. --- ## Prioritized High-Impact Actions (next 2–4 weeks) 1. **Fix ElizaCloud “first 10 minutes” blockers**: VPN recharge failure messaging, clarify “Add USD” UX, and patch double account creation/welcome bonus idempotency. 2. **Create and pin a canonical “Babylon + Token + Migration + NFTs” FAQ** (Discord + dashboard link) to stop repetitive expectation mismatches and reduce scam exposure. 3. **Consolidate n8n plugin repos with hard redirects + add a local-dev preflight** that detects missing crawl-generated JSON and prints exact steps. 4. **Publish a weekly, lightweight update cadence** (“shipped/next/known issues”), even if milestone-based development continues—opt-in dashboard updates included. 5. **Stand up a minimal “recommended plugins by use case” catalog** (even as a static page) to address plugin reliability/discovery and align with real usage patterns.