guides

Writing Support Policies Buyers Understand

How sellers can describe support, response windows, exclusions, and customization boundaries without sounding hostile.

Writing Support Policies Buyers Understand

A support policy is not there to scare buyers away.

It is there to make the relationship easier before stress enters the room.

Say what support includes

Useful support policies mention:

  • Installation help.
  • Bug reports.
  • Compatibility questions.
  • License activation issues.
  • Basic configuration guidance.
  • Update questions.

Make the normal path feel simple.

Say what support does not include

Good boundaries are fair to both sides.

You may need to exclude:

  • Custom development.
  • Third-party service outages.
  • Hosting problems outside your control.
  • Deep debugging of unrelated plugins or themes.
  • Unsupported versions.
  • Buyer-modified source code.

This does not have to sound cold. Plain language is enough.

Give a realistic response window

Do not promise instant support unless you can deliver it.

Buyers usually respect realistic expectations:

  • Same business day.
  • Within two business days.
  • Priority support for higher tiers.
  • Community-only support for free add-ons.

Your support promise should match your pricing.

Tell buyers where to go

If support is handled through Lyrinox Market tickets, say that.

If you also use your own helpdesk, documentation, or GitHub issue tracker, explain when each channel is appropriate.

For customer support through Lyrinox Market, buyers can contact [[email protected]](mailto:[email protected]).

Support quality becomes reputation

Support is one of the ways sellers earn long-term trust.

Clear support policies reduce friction, and good support makes reviews easier to earn honestly.