How support is handled
MerchantDrafts support should first solve the real issue: setup confusion, expectation mismatch,
runtime friction, credits, plan confusion, or workflow gaps. A gesture is a follow-up layer, not
a replacement for support.
- Clarify the actual issue before offering a gesture.
- Prefer a direct operational fix over generic reassurance.
- Use credits, unlocks, or early access only after the problem is understood.
Review request policy
Review asks should be aimed at satisfied users after a concrete success moment, not dropped into
every conversation or tied to explicit quid-pro-quo language.
- Ask after a clear positive outcome, not before.
- Keep the tone light and non-transactional.
- Do not frame rewards as payment for changing or leaving a review.
Recovery after a bad review
Recovery should be practical. If a user is frustrated, MerchantDrafts should first address the
cause, then decide whether a goodwill gesture makes sense.
- Fix or explain the underlying issue first.
- Use larger support gestures only when the user actually had a poor experience.
- Invite follow-up by email when a deeper recovery path is appropriate.
Goodwill gestures
The working MerchantDrafts direction is to use low-risk gestures that cost little unless the user
remains active: hosted credits, unlocks, and early access.
- Silent hosted credit grants as the default fallback.
- Temporary feature unlocks where entitlement control is feasible.
- One-time content unlocks where the reward feels additive and concrete.
- Early-access flags for power users, LTD buyers, or strong positive signals.
When to move the conversation off-platform
MerchantDrafts can use its email list and direct support channels when a user is receptive and a
deeper next step is needed. That gives room for credit promos, unlock announcements, recovery follow-up,
partner/LTD updates, and launch offers without turning the public thread into a negotiation.
For current direct contact, use . For product
support orientation, use .