Support Feature Plan

Support Feature Plan

This document defines a plan for a new Support module in AppiFire AI Chat.

The module combines:

• customer support/contact options,
• public feature requests,
• voting on requested features,
• roadmap visibility,
• admin moderation and roadmap management.

The product idea is inspired by tools like Features.Vote, where users can submit ideas, vote on what matters, view roadmap progress, and receive updates when features ship.

---

1) Goal

Create a single Support page/module where merchants and users can:

• ask for support,
• submit feature requests,
• vote for existing feature requests,
• view roadmap status,
• see changelog/release updates later.

Admin user zainalam1001@gmail.com gets extra management controls:

• approve/reject submitted feature requests,
• edit feature titles/descriptions,
• update feature status,
• manage roadmap items,
• pin/feature important requests,
• moderate spam/duplicates.

---

2) Module placement

Add a new app nav item:

• Support

Route example:

• /app/support

The page should use tabs:

• Support
• Feature requests
• Roadmap
• Changelog (optional later)
• Admin (visible only to zainalam1001@gmail.com)

---

2.1) Design and UI guidelines

The Support module must follow the same design guidelines and styling system used by the rest of the AppiFire admin pages.

Reference:

• docs/src/content/docs/04 Admin and Storefront/Design-Guidelines-and-Styling-System.md
• Existing implemented pages such as Settings, Billing, Promo Codes, Promo Send, Chat Logs, and Knowledge screens.

Required UI rules:

• Use existing Polaris layout patterns already used in the app (Page, Card, BlockStack, InlineStack, Text, Button, TextField, Select, Modal, Banner, DataTable where appropriate).
• Use existing app CSS utility classes and button wrappers:
  • app-page-shell
  • app-card-body
  • app-form
  • app-actions-row
  • app-btn
  • app-btn-primary
  • app-btn-secondary
  • app-btn-danger
  • app-btn-md
  • app-btn-lg
• Primary actions should use the same styled primary button pattern used on other screens.
• Secondary actions should use the same secondary button style.
• Destructive actions should use the danger style and should require confirmation where appropriate.
• Use popup modals for create/edit flows when consistent with existing pages (for example, promo code create/edit modals).
• Show success/error feedback using Polaris Banner or existing toast patterns.
• Empty states must be designed, not left blank.
• Loading and disabled states must be handled for all fetcher/form actions.
• Tables/lists should match existing spacing, card, and action grouping patterns.
• Admin-only controls must be hidden in UI and protected server-side.
• Do not introduce a new visual system unless required; reuse the current app style.

---

3) Tab 1 — Support

Purpose:

• Give merchants a simple way to contact AppiFire support.
• Show configured support channels.
• Link to documentation or common help topics.

Content:

• Support WhatsApp number, if configured.
• Support email, if configured.
• Admin/store fallback email.
• Short help text:
  • “Need help with setup, billing, chat behavior, or product sync? Contact us using one of the options below.”

Possible actions:

• Open WhatsApp link.
• Send email.
• View docs.
• Submit support message form (later).

MVP:

• Display support contact options only.

Later:

• Add support ticket form with status tracking.

---

4) Tab 2 — Feature Requests

Purpose:

• Let users submit ideas and vote on requested features.
• Help prioritize what to build next based on real demand.

User capabilities:

• View approved feature requests.
• Search/filter feature requests.
• Submit a new feature request.
• Vote for a feature.
• Remove their own vote.
• Add optional comments (later).

Feature request fields:

• Title
• Description
• Category
• Status
• Vote count
• Submitted by name/email/shop
• Created date
• Updated date

Statuses:

• pending_review
• approved
• planned
• in_progress
• shipped
• rejected
• duplicate

Default flow:

1. User submits feature request.
2. Feature is saved as pending_review.
3. Admin reviews it.
4. If approved, it appears publicly in Feature Requests tab.
5. Other users can vote.

Voting rules:

• One vote per user/shop/email per feature.
• Vote count is calculated from vote rows.
• Prevent duplicate votes.

---

5) Tab 3 — Roadmap

Purpose:

• Show what AppiFire is planning, building, and has shipped.
• Build trust by giving users visibility into product direction.

Roadmap columns:

• Planned
• In Progress
• Done/Shipped

Roadmap item fields:

• Title
• Description
• Status
• Expected timeframe (optional)
• Linked feature request (optional)
• Vote count
• Published/hidden flag

Admin capabilities:

• Move approved feature requests to roadmap.
• Update status from planned → in progress → shipped.
• Set expected release window.
• Hide/show roadmap items.

Public/user capabilities:

• View roadmap items.
• Vote on linked feature requests.
• See shipped items.

---

6) Tab 4 — Changelog (optional later)

Purpose:

• Announce shipped features and improvements.
• Close the feedback loop with voters/users.

Changelog item fields:

• Title
• Description
• Release date
• Linked roadmap item
• Linked feature request
• Published flag

Later behavior:

• When a feature is marked shipped, admin can create a changelog post.
• Voters can optionally receive email notification.

This is not required for MVP but should be considered for Version 2.

---

7) Admin tab — Admin-only management

Visible only to:

• zainalam1001@gmail.com

Admin route can be either:

• a tab inside /app/support, or
• separate route /app/support/admin.

Admin features:

• View all feature requests, including pending/rejected/duplicate.
• Approve feature requests.
• Reject feature requests.
• Mark duplicate and link to original request.
• Edit title, description, category.
• Update status.
• Delete spam only if needed, otherwise prefer archive/reject.
• Convert feature request into roadmap item.
• Manage roadmap ordering and columns.
• Publish/unpublish roadmap items.
• Create changelog item for shipped feature.

Admin filters:

• Status
• Category
• Vote count
• Submitted shop
• Date submitted

Admin actions should be server-side guarded, not only hidden in UI.

---

8) Access control

Public merchant users:

• Can view approved feature requests.
• Can vote.
• Can submit new feature requests.
• Can view published roadmap.

Admin user:

• Email: zainalam1001@gmail.com
• Can manage all tabs and statuses.
• Can approve and publish user-submitted features.

Access check:

• Reuse existing hardcoded-email pattern used for promo admin.
• Normalize email by trim + lowercase.
• Check session/user email and fallback shop email if needed.

---

9) Data model proposal

SupportFeatureRequest

Fields:

• id
• title
• description
• category
• status
• submittedByName
• submittedByEmail
• submittedByShopDomain
• submittedByShopId
• adminNotes
• duplicateOfId
• approvedAt
• approvedByEmail
• createdAt
• updatedAt

Indexes:

• status
• category
• createdAt
• submittedByShopId

SupportFeatureVote

Fields:

• id
• featureRequestId
• shopId
• shopDomain
• voterEmail
• voterName
• createdAt

Constraints:

• unique (featureRequestId, shopId) or (featureRequestId, voterEmail) depending on final identity rule.

Recommended:

• Use (featureRequestId, shopId) for merchant/admin app context.
• Add voterEmail for display/audit.

SupportRoadmapItem

Fields:

• id
• featureRequestId
• title
• description
• status (planned, in_progress, shipped)
• timeframe
• sortOrder
• published
• createdAt
• updatedAt

SupportChangelogItem (later)

Fields:

• id
• roadmapItemId
• featureRequestId
• title
• description
• published
• publishedAt
• createdAt
• updatedAt

---

10) UX behavior

Feature submission

1. User opens Support → Feature Requests.
2. Clicks “Request a feature”.
3. Modal opens with:
   • title
   • description
   • category
4. Submit creates pending_review.
5. Show success:
   • “Thanks. Your request is pending review.”

Voting

1. User sees approved feature list.
2. Clicks “Vote”.
3. Vote row is created.
4. Vote count updates.
5. If already voted, button changes to “Voted”.

Admin approval

1. Admin opens Admin tab.
2. Reviews pending feature.
3. Chooses:
   • approve
   • reject
   • mark duplicate
4. Approved feature becomes visible in public Feature Requests tab.

Roadmap management

1. Admin selects approved feature.
2. Clicks “Add to roadmap”.
3. Sets status and optional timeframe.
4. Roadmap tab displays the item.

---

11) MVP scope

Build first:

• Support page route with tabs.
• Support contact tab.
• Feature requests tab.
• Submit feature request modal.
• Vote/unvote feature request.
• Admin-only management tab.
• Admin approve/reject/status update.
• Roadmap tab with planned/in-progress/shipped columns.

Skip for MVP:

• Changelog email notifications.
• Comments under feature requests.
• Public embeddable board.
• Team roles.
• Advanced analytics.
• Custom domain.

---

12) Version 2 scope

Add later:

• Changelog tab.
• Email notifications to voters when shipped.
• Comments/discussion on feature requests.
• Duplicate detection suggestions.
• Analytics:
  • top voted features
  • votes by paid/free shops
  • voter spend/plan
• Public/embedded feedback board.
• Roadmap sharing page.
• Slack/email notifications for new feature submissions.

---

13) File-level implementation map

Proposed files:

• prisma/schema.prisma
  • add feature request, vote, roadmap, changelog models.
• app/routes/app.support.jsx
  • main Support page with tabs.
• app/routes/app.support.admin.jsx (optional)
  • admin-only management route if not using tabs.
• app/lib/support-feature.server.js
  • admin access checks, CRUD helpers, vote helpers.
• app/routes/api.support-feature-vote.jsx (optional)
  • vote/unvote endpoint if using fetchers.
• app/routes/app.jsx
  • add Support nav link.

---

14) Open questions

• Should all merchants see the same global feature board, or should requests be per shop?
  • Recommended: global board for AppiFire product feedback.
• Should voting be tied to shop or individual staff user?
  • Recommended MVP: one vote per shop per feature.
• Should rejected requests be hard deleted?
  • Recommended: no. Keep as rejected/archive for audit.
• Should users receive email when their feature ships?
  • Recommended: Version 2.

---

15) Success criteria

• Users can submit feature requests from Support module.
• Users can vote on approved features.
• Admin can approve/reject requests.
• Admin can move features through roadmap statuses.
• Roadmap clearly shows planned, in-progress, and shipped work.
• Support module becomes the central place for help + feedback + product direction.