## User Feedback Analysis — 2026-02-21

### 1) Pain Point Categorization (Top recurring 5–7)

**Dataset note (quantification basis):** ~18 distinct user-reported concerns/questions across Discord (Feb 18–20) + GitHub issues (Feb). Percentages below are approximate share of distinct concerns.

#### A. UX/UI (≈17–22% of concerns; high severity for Cloud usability)
- **Broken scrolling in ElizaCloud dashboard (especially API Explorer)**: mousepad scrolling fails; users must drag a barely-visible scrollbar. (Reported by **DorianD**)
- **Low discoverability of critical UI controls**: “hard-to-see scrollbar” implies poor contrast/affordance and blocks basic navigation.

#### B. Technical Functionality (≈28–33%; high severity due to “it doesn’t work” failures)
- **API Explorer “Send request” fails with `api key is required` even when key appears present** (ElizaCloud). (Reported by **DorianD**)
- **Duplicate LLM calls when message contains a URL (webapp)** causing duplicated output and ~2x cost. (GitHub issue **#6486** by **thewoweffect**, still open)
- **Media handling regressions in Cloud chat pipeline** (image content stripped) — fixed/closed, but indicates fragility in message conversion layers. (GitHub issue **#6494**, closed)

#### C. Documentation (≈28–33%; medium-to-high severity because it blocks onboarding + increases support load)
- **BYOK ambiguity (“use a different key”)**: users can’t tell if this supports OpenAI/OpenRouter-style bring-your-own-key. (Asked by **DorianD**, unanswered)
- **Pricing transparency gaps**: request for **per-model price breakdown in-dashboard** to understand costs. (Requested by **DorianD**)
- **Token/chain clarity requests**: users repeatedly asked whether **Milady on BNB vs Solana** are both valid. (Asked twice by **alex_wukar**, unanswered)
- **Contract address discoverability**: repeated requests for ElizaOS contract address suggest information is not surfaced well. (Feb 19 thread)

#### D. Community / Support Process (≈17–22%; high severity for trust + retention)
- **No clear support/ticket path for high-stakes issues (migration/coins)**: user fears losing coins during migration and doesn’t know where to go; guidance was “post publicly,” not a resolution workflow. (Raised by **shepa777**; response by **Kenk**)
- **No formal “collab proposal” intake**: users ask where to open a proposal ticket; told “no ticket system.” (Q by **YoungOldman**, A by **Kenk**)

#### E. Communication (≈22–28%; high severity due to reputational impact)
- **Fragmented leadership updates**: Shaw posts AI/dev updates on Twitter and crypto updates on Farcaster; users must monitor both to stay informed. (Explained by **Odilitime**)
- **Partner communications called out as weak** causing “unnecessary negative sentiment” among influential partner groups. (🥇-partners channel)
- **Expectation mismatch post-incidents (Autofun/Twitter)**: users explicitly ask what happened to promised marketing/lawsuit and broader follow-through. (Feb 20 general discussion)

#### F. Integration (≈11–17%; medium severity, high leverage for adoption)
- **Custom OpenAI endpoint not supported** (blocks OpenAI-compatible providers like SiliconFlow). (GitHub issue **#6490**, open)
- **BYOK expectations** in Cloud UI align with broader ecosystem patterns (OpenRouter), but behavior is unclear and possibly unsupported.

#### G. Performance / Cost Control (≈11–17%; high severity when it doubles cost)
- **URL-triggered duplicate calls** directly increases LLM spend and degrades UX. (Issue **#6486**)
- Repeated cost sensitivity signals: dashboard pricing breakdown request + duplication bug + scenario “Cost Evaluator” work in repo history indicate users are actively managing spend.

---

### 2) Usage Pattern Analysis (Actual vs intended use)

**Observed “actual usage” patterns**
- **ElizaCloud as an API-first experimentation surface**: users treat the Cloud dashboard/API Explorer like Postman/Swagger for quick validation (e.g., “Send request” testing), and failures here are “hard blockers.”
- **Plugin ecosystem as the primary extension mechanism**: repeated guidance to “build a plugin” for service integrations; developers actively discuss plugin compatibility and workflow automation (milady assistant, n8n workflows).
- **Agents used for crypto/security and on-chain workflows**: rugpull detection live testing (Solana), chain/token validation questions, and on-chain identity work (SAID) show strong Web3-first adoption.
- **Community expects “live agents” to demonstrate capabilities**: users ask if there is still a live Eliza agent that can answer questions about the latest codebase—suggesting demos/support agents are a major discovery/onboarding channel.

**Emerging / unexpected use cases**
- **Real-time risk detection systems** (Vlt9’s rugpull detector) as a flagship “agent utility” narrative: detection “~2 hours before crashes” is the kind of concrete win users can rally around and replicate.
- **Agentic workflow orchestration**: discussions around “Agentic AI-to-workflow integration” and n8n plugin fixes indicate users want robust automation, not just chat.

**Feature requests aligned with observed patterns**
- **BYOK + custom endpoints**: matches how builders assemble stacks across multiple providers.
- **Cost transparency**: per-model prices in UI + cost evaluator tooling aligns with experimentation and budget control.
- **Multi-agent coordination / cross-instance communication**: matches power-user needs for orchestrated systems (mentioned in dev progress discussions).

---

### 3) Implementation Opportunities (Concrete solutions per major pain point)

#### 1) ElizaCloud dashboard scrolling + UI affordance issues (UX/UI)
**Solutions**
1. **Fix scroll container + event handling (high impact / low-to-medium effort)**  
   - Audit CSS overflow containers and pointer/trackpad wheel listeners on `/dashboard/api-explorer`.  
   - Add automated UI regression tests for scroll (Playwright/Cypress: wheel, trackpad emulation).
2. **Make scrollbar visible and accessible (high impact / low effort)**  
   - Increase contrast, width on hover, and ensure OS-level scrollbars are respected.  
   - Add “Scroll to section” anchors or sticky navigation in API Explorer.
3. **Add an in-app “Report a UI bug” capture (medium impact / low effort)**  
   - Attach page URL, browser, viewport, and a screenshot prompt.

**Comparable approaches**
- Many API consoles (e.g., Swagger UI / Redoc deployments) avoid nested scrolling regions; they keep a single main scroll container to prevent trackpad capture bugs.

#### 2) “Send request” returning `api key is required` despite key present (Technical Functionality)
**Solutions**
1. **Instrument request building + display the effective auth state (high impact / medium effort)**  
   - Show “Auth: using key ending in …1234” and which header is sent (e.g., `Authorization: Bearer` vs `x-api-key`).  
   - Log a client-side diagnostic event when request is blocked/401.
2. **Add a “Test authentication” endpoint + UI check (high impact / low effort)**  
   - One-click: validates current key, returns account/org + permissions.  
3. **Add contract tests between UI and gateway (medium impact / medium effort)**  
   - Prevent UI showing a key “present” while backend expects a different storage location/field.

**Comparable approaches**
- Postman/Insomnia-style consoles surface “Auth mode” explicitly and warn when a variable is unset.

#### 3) BYOK ambiguity + custom endpoint requests (Documentation + Integration)
**Solutions**
1. **Document BYOK behavior directly in the UI (high impact / low effort)**  
   - Tooltip next to “use a different key”: what providers are supported, how keys are stored, security model, and what features change (billing, rate limits, logging).
2. **Implement provider config: `baseURL` for OpenAI-compatible endpoints (high impact / medium effort)**  
   - Address GitHub **#6490** with a standard “OpenAI-compatible” mode (`OPENAI_BASE_URL`).  
3. **Align Cloud UI wording with actual capability (high impact / low effort)**  
   - If BYOK isn’t supported yet, rename control to avoid OpenRouter-like expectation (e.g., “Switch ElizaCloud key” vs “Use your own key”).

**Comparable approaches**
- OpenRouter and many OSS clients (e.g., OpenAI-compatible SDK wrappers) standardize on `baseURL`/`apiBase` configs.

#### 4) Pricing transparency gaps (Documentation / UX)
**Solutions**
1. **Add per-model pricing table in dashboard (high impact / low effort)**  
   - Include input/output token rates, last updated timestamp, and billing source of truth.
2. **Add an estimated-cost preview in API Explorer (medium impact / medium effort)**  
   - Show “estimated tokens/cost” after response (ties into cost sensitivity signals).
3. **Expose pricing via a versioned endpoint (medium impact / low effort)**  
   - Enables community tools and reduces repeated questions.

**Comparable approaches**
- Cloud platforms (e.g., Vercel, Render) reduce billing confusion by showing unit pricing next to usage graphs and API calls.

#### 5) Migration + token confusion + “lost coins” fear (Community + Documentation)
**Solutions**
1. **Create a single “Migration & Token Canonical Info” page (high impact / low effort)**  
   - What token is what, contract addresses, deadlines, post-deadline options, and common scams.  
2. **Add a dedicated support intake for migration issues (high impact / medium effort)**  
   - Simple form → generates a tracking ID; publish SLA expectations.  
3. **Pinned Discord message + bot command (high impact / low effort)**  
   - `/contract`, `/migration`, `/milady-chain` commands reduce repeat Qs.

**Comparable approaches**
- Many crypto projects reduce support chaos with a pinned “official contracts + migration steps” message plus an automated bot command and a single canonical webpage.

#### 6) Communication fragmentation (Communication)
**Solutions**
1. **Weekly “single source of truth” changelog in Discord + website (high impact / low effort)**  
   - Auto-aggregate Twitter/Farcaster updates into one post (even if originals remain separate).
2. **Partner update cadence + point-of-contact map (high impact / medium effort)**  
   - A lightweight “partner newsletter” and a clear escalation path prevents negative sentiment spirals.
3. **Roadmap reality check: explicitly label what’s shipped vs planned (medium impact / low effort)**  
   - Reduces “promised marketing/lawsuit” confusion by separating speculation from commitments.

**Comparable approaches**
- OSS projects often run “weekly ship notes” (Kubernetes-style summaries) and keep one canonical roadmap page.

---

### 4) Communication Gaps (Expectations vs reality)

- **BYOK expectation vs unclear implementation**: users interpret “use a different key” as OpenRouter-style BYOK; lack of answer suggests mismatch or missing docs.
- **Where updates happen**: having to monitor both Twitter and Farcaster is a repeated friction point; users miss updates and assume “no updates.”
- **Support expectations**: users with migration fear expect a private/support workflow; being told to “post publicly” increases anxiety and reduces trust.
- **“Live agent” expectation**: users look for an always-available agent that answers questions about the latest codebase; absence (or unclear presence) becomes an onboarding gap.

**Targeted documentation/onboarding improvements**
- Add a **“Start here” support map**: Bugs (GitHub), Cloud issues (form/Linear/Jira), migration/token (dedicated page + intake), partnerships (named channel + POC).
- Add a **Cloud API Explorer help panel**: auth modes, BYOK explanation, pricing link, and “known issues” banner.

---

### 5) Community Engagement Insights

**Power users / high-signal contributors and their needs**
- **DorianD**: performs exploratory QA on ElizaCloud; needs a clear bug reporting path, faster acknowledgment loops, and visibility into fixes.
- **Odilitime**: acting as primary community responder; needs tooling (macros, bot commands, pinned canon) to reduce repetitive support.
- **Vlt9**: shipping real-world agent utility (rugpull detection) and documentation; needs a distribution path (case study, repo template, integration guide) to turn it into an ecosystem reference.
- **Kenk**: provides process guidance (plugins, posting publicly); would benefit from a formalized “how to collaborate” doc to point users to.

**Common newcomer questions indicating onboarding friction**
- Contract addresses / token identity confusion ($ai6z vs $elizaos)
- Migration deadline and recovery options
- “Where do I contact Shaw / where are updates?”
- “Is there a ticket system for collabs/support?”

**Converting passive users into contributors**
- Create a **“Cloud QA program”**: lightweight template + recognition for reproducible bug reports (DorianD-like behavior).
- Publish **plugin bounties** (small, well-scoped) and label GitHub issues “good first plugin.”
- Host a short weekly **office hours** session focused on (1) Cloud issues triage, (2) plugin help, (3) migration support.

---

### 6) Feedback Collection Improvements

**Current channel effectiveness**
- **Discord** is generating many high-value signals, but issues get **left unanswered** (BYOK, Milady chain validity, live agent availability).
- **GitHub issues** capture technical bugs/feature requests well (duplicate calls, custom endpoint), but many user-facing Cloud issues are reported only in Discord.

**Improvements for more structured, actionable feedback**
1. **Add an ElizaCloud in-app feedback widget** (page + screenshot + category + severity).  
2. **Create Discord-to-issue bridging**: a bot command that converts a message into a GitHub issue with a template.  
3. **Standardize templates**:
   - Cloud bug report template (browser, OS, repro, expected/actual)
   - Migration support template (wallet, chain, tx hash, deadline context)

**Underrepresented segments**
- Non-Web3 builders (SaaS/enterprise) are largely absent in this snapshot; their needs (SSO, audit logs, compliance, stability SLAs) may be under-collected.
- Less-technical users: confusion suggests many are not comfortable self-triaging; current channels assume high context.

---

## Prioritized High-Impact Actions (Next 2–4 weeks)

1. **Fix ElizaCloud API Explorer blockers**: scrolling + `api key is required` send-test bug (highest impact, stops adoption immediately).  
2. **Publish canonical “Cloud Auth & BYOK” + “Pricing per model” in-dashboard** (cuts repeated questions and aligns expectations).  
3. **Create a migration/token single source of truth + support intake** (reduces fear, prevents reputational damage, lowers Discord load).  
4. **Unify communications into a weekly digest posted in Discord + website** (reduces “no updates” perception; helps partners).  
5. **Ship OpenAI-compatible `baseURL` support (GitHub #6490) and prioritize the URL-duplicate-call bug (#6486)** (high leverage for builders and cost control).