17 domain design docs covering architecture, accounts, inventory, rentals, lessons, repairs, POS, payments, batch repairs, delivery, billing, accounting, deployment, licensing, installer, and backend tech architecture. Plus implementation roadmap (doc 18) and personnel management (doc 19). Key design decisions documented: - company/location model (multi-tenant + multi-location) - member entity (renamed from student to support multiple adults) - Stripe vs Global Payments billing ownership differences - User/location/terminal licensing model - Valkey 8 instead of Redis
879 lines
19 KiB
Markdown
879 lines
19 KiB
Markdown
Music Store Management Platform
|
|
|
|
Deployment, Compliance, Pricing, Updates & Support
|
|
|
|
Version 1.0 | Draft
|
|
|
|
|
|
|
|
# 1. Deployment Models
|
|
|
|
The platform supports two deployment models. Customers choose based on their infrastructure preferences, IT capability, budget, and data sovereignty requirements. The core application codebase is identical — deployment configuration differs.
|
|
|
|
|
|
|
|
|
|
|
|
SaaS (Cloud Hosted)
|
|
|
|
Self-Hosted (On-Premise)
|
|
|
|
Infrastructure
|
|
|
|
AWS — vendor managed
|
|
|
|
Customer's own hardware
|
|
|
|
Updates
|
|
|
|
Automatic — zero customer action
|
|
|
|
One-click via admin panel
|
|
|
|
Uptime responsibility
|
|
|
|
Vendor (99.9% SLA)
|
|
|
|
Customer's IT / hardware
|
|
|
|
Backup
|
|
|
|
Vendor managed — automatic
|
|
|
|
Customer managed + optional cloud backup add-on
|
|
|
|
Pricing model
|
|
|
|
Monthly subscription
|
|
|
|
One-time license + annual maintenance
|
|
|
|
Internet required
|
|
|
|
Yes — always online
|
|
|
|
Local network only — internet optional
|
|
|
|
Data location
|
|
|
|
AWS us-east-1 (default)
|
|
|
|
Customer's premises
|
|
|
|
Best for
|
|
|
|
Stores without IT staff, smaller operations
|
|
|
|
Stores with IT, internet-sensitive, AIM migrants
|
|
|
|
|
|
|
|
## 1.1 SaaS Architecture
|
|
|
|
Multi-tenant deployment on AWS EKS. Each company is a tenant — data is logically separated by company_id on all tables. Physical locations within a company are distinguished by location_id on inventory, transaction, cash drawer, and delivery tables. Infrastructure is shared but data is never commingled in queries. Separate Aurora database clusters available as a premium option for large customers requiring hard data isolation.
|
|
|
|
|
|
|
|
AWS EKS (Kubernetes) └── API pods (auto-scaling) └── Admin frontend pod └── Customer portal podAurora PostgreSQL (Multi-tenant, company_id + location_id scoped)ElastiCache Redis (session, queues)S3 (PDFs, backups, exports)CloudFront (static assets)Route53 (DNS — customer.platform.com subdomains)
|
|
|
|
|
|
|
|
## 1.2 Self-Hosted Architecture
|
|
|
|
Single-tenant Docker Compose deployment. Designed to run on a modest mini PC or small server on the store's local network. Electron desktop app and iOS app connect to the local API over LAN. Remote access optional via VPN.
|
|
|
|
|
|
|
|
Recommended hardware: Mini PC (Intel NUC or equivalent) CPU: 4-core, RAM: 16GB, Storage: 500GB SSD OS: Ubuntu 24 LTS Estimated hardware cost: $300-600Docker Compose stack: └── api (Node.js / Python API) └── postgres (PostgreSQL 16) └── redis (Redis 7) └── admin (Admin frontend — Nginx) └── portal (Customer portal — Nginx) └── nginx (Reverse proxy, SSL termination) └── updater (Update checker service) └── backup (Automated local backup service)
|
|
|
|
|
|
|
|
Installer script handles Docker installation, initial configuration, SSL certificate generation (self-signed or Let's Encrypt), and first-run database setup. Target setup time under 30 minutes for a competent IT person.
|
|
|
|
|
|
|
|
## 1.3 Offline Resilience (Both Models)
|
|
|
|
POS operations are the most critical function. Both deployment models support degraded offline operation to prevent a total outage from stopping the store.
|
|
|
|
- Desktop app caches current inventory, customer list, and open tickets locally
|
|
|
|
- Cash and card-keyed sales can be queued locally if backend unreachable
|
|
|
|
- Stripe Terminal card-present payments require internet — clear staff messaging when offline
|
|
|
|
- Sync occurs automatically when connection restored — conflict resolution logged
|
|
|
|
- Self-hosted: local network outage only affects cloud backup and update checker — core POS unaffected
|
|
|
|
|
|
|
|
# 2. Update Mechanism
|
|
|
|
## 2.1 SaaS Updates
|
|
|
|
SaaS customers receive updates automatically. No customer action required. Updates deployed using rolling deployment on EKS — zero downtime. Database migrations run as part of the deployment pipeline and are always backward compatible.
|
|
|
|
|
|
|
|
- Minor updates (bug fixes, small features) deployed continuously
|
|
|
|
- Major updates announced via in-app notification 7 days in advance
|
|
|
|
- Breaking changes (schema changes, workflow changes) communicated with migration guides
|
|
|
|
- Rollback capability maintained for 24 hours after any deployment
|
|
|
|
- Maintenance windows scheduled 2am-4am local time for database migrations if required
|
|
|
|
|
|
|
|
## 2.2 Self-Hosted Updates
|
|
|
|
Self-hosted customers receive updates via an in-app update checker built into the admin panel. The updater service polls the vendor update registry on startup and daily thereafter.
|
|
|
|
|
|
|
|
### Update Flow
|
|
|
|
- Admin panel shows current version and available version when update exists
|
|
|
|
- Changelog displayed before update — store admin can review what changed
|
|
|
|
- One-click update: pulls new Docker images, runs database migrations, restarts services
|
|
|
|
- Automatic backup taken before every update — rollback available if update fails
|
|
|
|
- Update log stored locally — full history of applied updates
|
|
|
|
|
|
|
|
### Update Registry
|
|
|
|
Vendor hosts a simple update registry API: GET https://updates.platform.com/check ?version=1.4.2&license=LICENSE_KEY Returns: { latest: '1.5.0', required: false, changelog_url: '...', download_url: '...' }required: true = security update — admin warned, update strongly advisedrequired: false = optional update — admin chooses timing
|
|
|
|
|
|
|
|
### Database Migration Safety
|
|
|
|
- All migrations are additive — new columns, new tables, new indexes
|
|
|
|
- No destructive migrations (DROP COLUMN, DROP TABLE) without explicit data export first
|
|
|
|
- Migrations tested against production-size data snapshots before release
|
|
|
|
- Each migration includes a rollback script
|
|
|
|
- Migration history table tracks applied migrations — idempotent on re-run
|
|
|
|
|
|
|
|
## 2.3 Version Support Policy
|
|
|
|
Version Status
|
|
|
|
Policy
|
|
|
|
Current
|
|
|
|
Full support — all bugs fixed, all features available
|
|
|
|
Previous major
|
|
|
|
Security fixes only — 12 months after new major release
|
|
|
|
End of life
|
|
|
|
No support — customers on annual maintenance must update
|
|
|
|
|
|
|
|
# 3. Compliance & Certification
|
|
|
|
## 3.1 PCI DSS Compliance
|
|
|
|
Payment Card Industry Data Security Standard (PCI DSS) compliance is required for any business that handles card payments. The platform's architecture is specifically designed to minimize PCI scope.
|
|
|
|
|
|
|
|
Scenario
|
|
|
|
SAQ Level
|
|
|
|
Requirements
|
|
|
|
SaaS — Stripe Terminal + Elements
|
|
|
|
SAQ A
|
|
|
|
Self-assessment questionnaire only — no audit. Card data never touches platform servers.
|
|
|
|
Self-hosted — Stripe Terminal + Elements
|
|
|
|
SAQ A
|
|
|
|
Same as SaaS — Stripe handles all card data. Customer must secure their local network.
|
|
|
|
Any keyed entry NOT using Stripe Elements
|
|
|
|
SAQ D
|
|
|
|
Full audit required — avoided by design. Platform never implements raw card input fields.
|
|
|
|
|
|
|
|
SAQ A requirements for the platform vendor (Lunarfront Tech LLC):
|
|
|
|
- Never store, process, or transmit cardholder data on platform servers
|
|
|
|
- Maintain secure development practices — no card data in logs
|
|
|
|
- Annual SAQ A self-assessment completion
|
|
|
|
- Provide PCI compliance documentation to customers on request
|
|
|
|
- Self-hosted customers receive a PCI compliance guide covering their local environment requirements
|
|
|
|
|
|
|
|
## 3.2 SOC 2
|
|
|
|
Status
|
|
|
|
Priority
|
|
|
|
Notes
|
|
|
|
Not required at launch
|
|
|
|
Defer
|
|
|
|
SOC 2 Type II audit costs $20,000-50,000. Required only if large school districts or enterprise customers demand it. Revisit at 50+ customers.
|
|
|
|
|
|
|
|
## 3.3 Data Privacy — CCPA & GDPR
|
|
|
|
The platform stores customer PII including names, addresses, contact details, and payment references. Privacy obligations apply based on customer location.
|
|
|
|
|
|
|
|
Regulation
|
|
|
|
Applies
|
|
|
|
Requirements
|
|
|
|
CCPA
|
|
|
|
Yes
|
|
|
|
California Consumer Privacy Act — applies to any store with California customers. Right to deletion, data access requests, privacy policy required.
|
|
|
|
GDPR
|
|
|
|
Unlikely
|
|
|
|
EU General Data Protection Regulation — applies only if EU customers. US music stores unlikely. Monitor if international expansion.
|
|
|
|
|
|
|
|
### Required Privacy Controls
|
|
|
|
- Privacy policy published and linked from all customer-facing surfaces
|
|
|
|
- Data retention policy — define how long customer data is kept after account closure
|
|
|
|
- Right to deletion — PII nullification on customer records (append-only event sourcing uses nullification not deletion)
|
|
|
|
- Data access requests — ability to export all data for a customer on request
|
|
|
|
- Breach notification procedure — documented and tested
|
|
|
|
- Data processing agreements available for enterprise customers
|
|
|
|
|
|
|
|
## 3.4 Sales Tax on SaaS Fees
|
|
|
|
Selling SaaS subscriptions nationally creates sales tax nexus obligations in states where revenue thresholds are crossed. This applies to Lunarfront Tech LLC's own subscription fees — separate from sales tax the stores collect from their customers.
|
|
|
|
- Economic nexus thresholds vary by state — typically $100,000 revenue or 200 transactions
|
|
|
|
- Integrate TaxJar or Avalara for automated sales tax calculation on subscription invoices
|
|
|
|
- Register for sales tax collection in states where thresholds are crossed
|
|
|
|
- Texas (home state) requires registration from day one
|
|
|
|
- Revisit quarterly as revenue grows into new states
|
|
|
|
|
|
|
|
## 3.5 Music Industry — No Specific Certification Required
|
|
|
|
There are no industry-specific software certifications required to sell POS software to music retailers. NAMM (National Association of Music Merchants) is the primary trade organization — membership and NAMM show presence adds credibility but is not a certification or requirement.
|
|
|
|
|
|
|
|
## 3.6 Business Entity
|
|
|
|
- Lunarfront Tech LLC registered in Texas — covers software sales nationally
|
|
|
|
- Standard commercial software license agreement required for all customers
|
|
|
|
- Terms of service and privacy policy required before account activation
|
|
|
|
- Self-hosted customers sign a separate perpetual license agreement
|
|
|
|
|
|
|
|
# 4. Pricing
|
|
|
|
## 4.1 SaaS Subscription Pricing
|
|
|
|
Plan
|
|
|
|
Price
|
|
|
|
Includes
|
|
|
|
|
|
|
|
Starter
|
|
|
|
$149/mo
|
|
|
|
POS + inventory + customers + Stripe Terminal + basic reporting + cash drawer + email support
|
|
|
|
|
|
|
|
Standard
|
|
|
|
$249/mo
|
|
|
|
Everything in Starter + rentals + rent-to-own + lessons + scheduling + repairs + QuickBooks export + invoice printing + iOS convention app
|
|
|
|
Most stores
|
|
|
|
Professional
|
|
|
|
$349/mo
|
|
|
|
Everything in Standard + batch repairs + delivery tracking + school management + advanced accounting + multi-location + API access + priority support
|
|
|
|
|
|
|
|
|
|
|
|
### SaaS Add-Ons
|
|
|
|
Add-On
|
|
|
|
Price
|
|
|
|
Notes
|
|
|
|
Additional location
|
|
|
|
+$99/mo
|
|
|
|
Per additional store location
|
|
|
|
Priority support upgrade
|
|
|
|
+$49/mo
|
|
|
|
4hr response + emergency POS-down line
|
|
|
|
AIM data migration
|
|
|
|
$500-1,500
|
|
|
|
One-time — based on data volume and complexity
|
|
|
|
Onboarding & training
|
|
|
|
$300
|
|
|
|
One-time — 3hr remote session covering all modules
|
|
|
|
|
|
|
|
## 4.2 Self-Hosted Licensing
|
|
|
|
License
|
|
|
|
Price
|
|
|
|
Includes
|
|
|
|
Standard License
|
|
|
|
$2,500
|
|
|
|
Perpetual license — Standard feature set. Software works indefinitely.
|
|
|
|
Professional License
|
|
|
|
$4,500
|
|
|
|
Perpetual license — Professional feature set including batch repairs, delivery, school management.
|
|
|
|
Annual Maintenance
|
|
|
|
20% of license
|
|
|
|
Updates + standard email support. Without maintenance, software still runs but receives no updates after year 1.
|
|
|
|
|
|
|
|
### Self-Hosted Add-Ons
|
|
|
|
Add-On
|
|
|
|
Price
|
|
|
|
Notes
|
|
|
|
Cloud backup
|
|
|
|
$29/mo
|
|
|
|
Encrypted backups to vendor S3 — disaster recovery
|
|
|
|
Priority support
|
|
|
|
$49/mo
|
|
|
|
4hr response + emergency POS-down line
|
|
|
|
AIM data migration
|
|
|
|
$500-1,500
|
|
|
|
One-time — remote migration assistance
|
|
|
|
Remote installation
|
|
|
|
$250
|
|
|
|
One-time — vendor installs and configures remotely
|
|
|
|
Onboarding & training
|
|
|
|
$300
|
|
|
|
One-time — 3hr remote training session
|
|
|
|
|
|
|
|
## 4.3 Unit Economics (SaaS)
|
|
|
|
Customers
|
|
|
|
Avg Revenue/Mo
|
|
|
|
MRR
|
|
|
|
AWS Est.
|
|
|
|
10
|
|
|
|
$249
|
|
|
|
$2,490
|
|
|
|
~$200
|
|
|
|
25
|
|
|
|
$280
|
|
|
|
$7,000
|
|
|
|
~$400
|
|
|
|
50
|
|
|
|
$290
|
|
|
|
$14,500
|
|
|
|
~$700
|
|
|
|
100
|
|
|
|
$300
|
|
|
|
$30,000
|
|
|
|
~$1,200
|
|
|
|
|
|
|
|
Average revenue per customer increases as stores upgrade plans and add locations. AWS costs scale sublinearly due to multi-tenant efficiency. Net margin at scale is 90%+ before support labor.
|
|
|
|
|
|
|
|
## 4.4 Launch Pricing Strategy
|
|
|
|
First 10 customers should receive significantly discounted or free access in exchange for being design partners. These stores will surface edge cases, validate workflows, and serve as reference customers for future sales.
|
|
|
|
- Beta program: free for 6 months, then standard pricing
|
|
|
|
- Beta customers get lifetime 20% discount as reference customer reward
|
|
|
|
- In exchange: monthly feedback calls, permission to use as case study, referral introductions
|
|
|
|
- Target beta customers: stores currently on AIM with pain around cloud access, modern hardware, or school batch repairs
|
|
|
|
|
|
|
|
# 5. Support Model
|
|
|
|
## 5.1 Support Philosophy
|
|
|
|
The best support interaction is one that never needs to happen. Investment in self-service documentation, resilient software design, and proactive monitoring reduces support volume. When support is needed, response time and resolution quality matter most — a POS system is critical business infrastructure.
|
|
|
|
|
|
|
|
## 5.2 Support Tiers by Plan
|
|
|
|
Plan
|
|
|
|
Channel
|
|
|
|
Response SLA
|
|
|
|
Notes
|
|
|
|
Starter
|
|
|
|
Email only
|
|
|
|
48 business hours
|
|
|
|
Acknowledged at signup — appropriate for low-volume stores
|
|
|
|
Standard
|
|
|
|
Email + ticket
|
|
|
|
Next business day
|
|
|
|
Business hours: Mon-Fri 8am-6pm CT
|
|
|
|
Professional
|
|
|
|
Priority queue
|
|
|
|
4 business hours
|
|
|
|
Emergency POS-down line for payment processing failures only
|
|
|
|
Self-hosted + maintenance
|
|
|
|
Email + ticket
|
|
|
|
Next business day
|
|
|
|
Hardware issues are customer's responsibility
|
|
|
|
Priority support add-on
|
|
|
|
Priority queue
|
|
|
|
4 business hours
|
|
|
|
Available as add-on for any plan
|
|
|
|
|
|
|
|
## 5.3 Emergency POS-Down Definition
|
|
|
|
Emergency support (outside business hours) is reserved for true POS-down situations only — defined as the store being completely unable to process any payments. This is the highest-severity scenario.
|
|
|
|
|
|
|
|
Scenario
|
|
|
|
Emergency?
|
|
|
|
Response
|
|
|
|
Platform completely unreachable
|
|
|
|
YES
|
|
|
|
Emergency line — target 1hr response
|
|
|
|
Card payments failing, cash works
|
|
|
|
NO
|
|
|
|
Next business day — workaround exists
|
|
|
|
Specific feature not working
|
|
|
|
NO
|
|
|
|
Standard SLA — not a POS-down situation
|
|
|
|
Report not generating
|
|
|
|
NO
|
|
|
|
Standard SLA
|
|
|
|
Self-hosted server down
|
|
|
|
NO
|
|
|
|
Customer's infrastructure — guide to troubleshooting provided
|
|
|
|
|
|
|
|
## 5.4 Self-Service Infrastructure
|
|
|
|
Self-service resources reduce support volume and empower stores to resolve common issues independently. All self-service content is built and maintained as part of the product.
|
|
|
|
|
|
|
|
### Knowledge Base
|
|
|
|
- Searchable help articles for every feature and workflow
|
|
|
|
- Step-by-step guides with screenshots for all major operations
|
|
|
|
- Troubleshooting guides for common error conditions
|
|
|
|
- AIM migration guide — specific help for stores transitioning from AIM
|
|
|
|
- Hosted at help.platform.com — accessible without logging in
|
|
|
|
|
|
|
|
### In-App Help
|
|
|
|
- Contextual help tooltips on complex fields and settings
|
|
|
|
- Inline error messages that explain what went wrong and how to fix it — never just error codes
|
|
|
|
- First-run guided setup wizard for new accounts
|
|
|
|
- Search bar in admin panel searches knowledge base without leaving the app
|
|
|
|
|
|
|
|
### Video Library
|
|
|
|
- Short (3-5 minute) walkthrough videos for each major module
|
|
|
|
- Onboarding series: first week, first month
|
|
|
|
- Hosted on YouTube (unlisted) — embedded in knowledge base
|
|
|
|
|
|
|
|
### Status Page
|
|
|
|
- Public status page at status.platform.com (statuspage.io or similar)
|
|
|
|
- Real-time uptime for all platform components
|
|
|
|
- Incident history and postmortems
|
|
|
|
- Email/SMS subscribe for outage notifications
|
|
|
|
- Stores check status page before submitting support tickets — reduces 'is it down?' tickets
|
|
|
|
|
|
|
|
## 5.5 Proactive Monitoring
|
|
|
|
Catching issues before customers report them is the most effective support strategy. Automated monitoring alerts the vendor immediately when problems occur.
|
|
|
|
- PagerDuty or OpsGenie — on-call alerting for platform incidents
|
|
|
|
- Synthetic monitoring — automated transaction tests run every 5 minutes against production
|
|
|
|
- Error rate alerts — spike in API errors triggers immediate investigation
|
|
|
|
- Stripe webhook failure alerts — missed webhooks flagged within minutes
|
|
|
|
- Database performance monitoring — slow queries identified before they cause user impact
|
|
|
|
- Self-hosted: optional telemetry (opt-in) sends health metrics to vendor for proactive support
|
|
|
|
|
|
|
|
## 5.6 Scaling Support as Customer Base Grows
|
|
|
|
Stage
|
|
|
|
Support Approach
|
|
|
|
0-20 customers
|
|
|
|
Solo — founder handles all support. Invest heavily in self-service documentation to reduce volume. Target < 2 tickets per customer per month.
|
|
|
|
20-50 customers
|
|
|
|
Hire part-time support contractor with music retail background. Train on platform. Handle tier 1 tickets (how-to questions, basic troubleshooting). Founder handles tier 2 (bugs, integrations).
|
|
|
|
50-100 customers
|
|
|
|
Full-time support hire or VAR (value-added reseller) partnerships. VARs handle implementation and support for a region in exchange for revenue share (typically 20-30%).
|
|
|
|
100+ customers
|
|
|
|
Dedicated support team. Community forum where experienced stores help newer ones. Formal partner program for VARs and consultants.
|
|
|
|
|
|
|
|
## 5.7 VAR / Partner Program
|
|
|
|
Value-added resellers are consultants or IT companies that sell, implement, and support the platform on behalf of end customers. This is how many niche B2B software companies scale support without hiring — the VAR takes on the customer relationship in exchange for a cut of recurring revenue.
|
|
|
|
- VAR sells the platform to their existing music store clients
|
|
|
|
- VAR handles implementation, data migration, training, and tier 1 support
|
|
|
|
- VAR receives 20-25% of monthly subscription revenue for life of customer
|
|
|
|
- Vendor provides VAR training, certification, and technical escalation support
|
|
|
|
- NAMM show is the natural place to recruit VARs — music industry consultants attend
|
|
|
|
- Target: 3-5 regional VARs covering US geography within first 2 years
|
|
|
|
|
|
|
|
# 6. Go-to-Market Notes
|
|
|
|
## 6.1 Competitive Positioning
|
|
|
|
Feature
|
|
|
|
This Platform
|
|
|
|
AIM
|
|
|
|
Music Shop 360
|
|
|
|
Cloud-based
|
|
|
|
Yes
|
|
|
|
No
|
|
|
|
Yes
|
|
|
|
Self-hosted option
|
|
|
|
Yes
|
|
|
|
Yes
|
|
|
|
No
|
|
|
|
Offline POS mode
|
|
|
|
Yes
|
|
|
|
Yes
|
|
|
|
Limited
|
|
|
|
Convention iOS app
|
|
|
|
Yes
|
|
|
|
No
|
|
|
|
No
|
|
|
|
Full rent-to-own
|
|
|
|
Yes
|
|
|
|
Yes
|
|
|
|
Partial
|
|
|
|
Family billing
|
|
|
|
Yes
|
|
|
|
Limited
|
|
|
|
Limited
|
|
|
|
Batch school repairs
|
|
|
|
Yes
|
|
|
|
No
|
|
|
|
Partial
|
|
|
|
Delivery tracking
|
|
|
|
Yes
|
|
|
|
No
|
|
|
|
No
|
|
|
|
Billing date mgmt
|
|
|
|
Yes
|
|
|
|
Limited
|
|
|
|
Limited
|
|
|
|
QB export
|
|
|
|
Yes
|
|
|
|
Add-on
|
|
|
|
Unknown
|
|
|
|
AIM migration tool
|
|
|
|
Yes
|
|
|
|
N/A
|
|
|
|
No
|
|
|
|
|
|
|
|
## 6.2 Launch Sequence
|
|
|
|
- Phase 1: Build core platform with one beta store — validate all workflows against real operations
|
|
|
|
- Phase 2: Onboard 5-10 beta stores at no cost — gather feedback, fix edge cases, build case studies
|
|
|
|
- Phase 3: Launch at NAMM or via NAMM member outreach — music retail community is tight-knit
|
|
|
|
- Phase 4: Recruit first VAR partner — ideally someone already consulting for music stores
|
|
|
|
- Phase 5: Paid marketing — Google Ads targeting 'AIM POS alternative', 'music store software'
|
|
|
|
|
|
|
|
## 6.3 AIM Migration as a Sales Tool
|
|
|
|
The AIM installed base is the primary target market. Stores that have been on AIM for 10+ years are the most likely to be feeling the pain of outdated infrastructure and are actively looking for alternatives. The AIM data migration tool is a meaningful competitive differentiator — it reduces switching cost and anxiety.
|
|
|
|
- 'We migrate your AIM data' is a headline feature in sales materials
|
|
|
|
- Migration tool handles customers, inventory, rentals, lessons, repair history
|
|
|
|
- Parallel operation period means zero risk of data loss during cutover
|
|
|
|
- Target stores that have complained publicly about AIM (review sites, forums, NAMM community) |