Apply with place context
The partner starts by describing the place, city, nearby landmark, audience fit, and intended ELC value.
Partner system
How ELC partnerships should work.
Partners belong around real places: destinations, city routes, landmarks, nearby moments, QR entry points, and Store handoffs. This shell explains the operating model without activating backend workflows.
Partner journey
A controlled path from place interest to future route activation.
Editorial review
ELC reviews whether the partner belongs in a destination, city, landmark, nearby place, QR, or offer route.
Choose visibility path
The partner is mapped to a future Presence, Journey, or Signature path without activating billing in this shell.
Prepare profile layer
Profile, media, location, and offer concepts can later be prepared for dashboard review and approval.
Connect to live routes
Future releases can attach the partner to city pages, landmarks, QR codes, Store offers, and reporting.
Where partners appear
Placement should follow the user journey, not interrupt it.
A partner should become useful when a reader is exploring a city, standing near a landmark, scanning a QR code, or choosing a relevant offer path. This keeps the system premium and contextual.
Destinations
Geographic pages create the route into countries, cities, and nearby partner opportunities.
Landmarks
Landmark pages become the natural place for nearby cafes, hotels, stores, and cultural moments.
QR routes
QR can later open partner profiles, landmark experiences, offers, staff verification, or redemption states.
Store offers
Commercial actions should stay in Store when buying, bundles, products, print, or offer paths are needed.
Future systems
These systems should stay out of the public shell until each backend phase is explicit.
Partner profile writes
Review and approval workflow
Stripe billing and plan status
QR issue, scan, and redemption backend
Dashboard analytics and reporting
Offer publishing and moderation
Next step
Start with the application shell, then build backend approval separately.
The safe sequence is public Partner Master, application shell, system explanation, then explicit backend PRs for validation, storage, review, billing, QR, and dashboard state.