Reducing License Activation Support Tickets for Indie Mac Devs

Most licensing support is the same three tickets, over and over: “I lost my key,” “I got a new laptop,” and “I’m out of activations.” The Keylight customer portal turns each one into an action the customer takes themselves — and removes the operational tax that makes most indie devs dread adding licensing. This post names the three tickets, shows exactly how the portal handles each, and includes the email template to redirect customers there.

The three tickets every indie Mac dev has answered too many times

Before you had a self-service portal, the workflow was manual and it looked like this:

Ticket 1: “I lost my license key.” The customer paid months ago — sometimes over a year ago. They switched computers, cleared out their inbox, or just never filed the purchase confirmation anywhere useful. Now they have reinstalled the app and cannot activate it. The fix is trivial: find the order in Stripe, look up the key in your licensing system, and paste it into a reply. Two minutes, maybe. But multiply that by every customer who has ever lost a key, and it becomes a persistent trickle of interruptions that never ends, because customers will always lose keys.

Ticket 2: “I got a new laptop, can you transfer my license?” The customer replaced their machine. Their key is still valid, but one of the activation slots is spent on a device they no longer own. Without self-service deactivation, they cannot free that slot themselves. They email you. You find the activation record, manually remove the old device, and tell them to activate on the new one. Another two-minute task that scales with your customer base. For how device activations work — fingerprinting, the activate flow, and why idempotency matters — there’s a full write-up.

Ticket 3: “It says I’m out of activations.” Semantically the same as ticket 2, often a different context: the customer runs your app on more machines than they expected, or forgot they had activated on an old machine they decommissioned. Some of these customers genuinely need more slots — that is a real signal about your product and how it is used. But most are just honest customers who need to rearrange their existing activations and have no way to do it themselves.

None of these tickets require expertise. None are interesting problems. They exist solely because the customer cannot see or manage their own license state — and fixing that is entirely on the tooling side, not on the customer’s competence or yours.

How the Keylight customer portal handles each one without your involvement

The Keylight customer portal is hosted by Keylight and available to every customer on every plan. You do not build it or maintain it. Customers reach it through a stable URL. Once there, they can do three things:

1. Retrieve a lost key. The customer identifies themselves — by the email they used to purchase — and the portal shows them their license key. The key is the same signed lease Keylight issued at purchase; retrieving it is displaying it, not issuing a new one. No ticket to you, no reply to write. The most common licensing support request becomes a page the customer visits on their own.

2. See their device list. The portal lists every machine the customer’s key is activated on, by friendly device name. A customer can see at a glance that two of their three slots are used and which machines those are. This is the starting point for both ticket 2 and ticket 3.

3. Deactivate a device they no longer use. From the device list, the customer can remove any device. Removing it decrements the activation count and frees the slot immediately — the customer can then activate on the new machine without waiting for you. This is what makes activation limits fair, in the wording from the customer portal feature page: a limit only works as an anti-sharing measure if honest customers can rearrange their own devices freely. The portal is that escape valve.

For the third case where a customer genuinely needs more slots — they really do run the app on four machines and have a three-device license — they will still contact you. That is fine, and it is actually useful: it is a customer telling you their current tier is not enough. That conversation has value; the “I forgot I activated on my old laptop” conversation does not.

One thing the portal does not do: handle refund requests. Refunds happen through Stripe, your payment processor. If a customer asks for a refund, that conversation still goes through your support channel. Keylight automatically revokes the associated license once Stripe reports the refund — the app will reject the key on the next online revalidation — but the refund request itself lands with you. For the full picture of how revocation reaches the app after a refund, see what happens after a refund in licensed software.

What to put in your app’s “Manage License” link

The customer portal URL is stable and specific to your Keylight tenant. To give customers easy access to it — from inside your app, so they don’t have to hunt for a link when something goes wrong — you open it in their browser with a single call.

On macOS:

import AppKit

// Open the Keylight customer portal in the user's browser. Customers sign in
// with the email on their license and see (or re-send themselves) their keys.
let portalURL = URL(string: "https://portal.keylight.dev")!
NSWorkspace.shared.open(portalURL)

On iOS or iPadOS, swap NSWorkspace.shared.open for UIApplication.shared.open(portalURL) — same URL, different API.

There is no automatic SDK helper that constructs this URL for you today; you construct it yourself and wire it to a “Manage License” button or menu item in your app. Where it lives depends on your UI: a preference pane, a Help menu item, or a button next to the activation status are all reasonable choices. The important thing is that it is reachable before the customer hits a problem — not buried in a settings panel they will only find while frustrated.

The call to action in your app can be as direct as “Manage your license at keylight.dev” or as integrated as a “Manage License” button that opens the portal. Either way, the link should be discoverable from the licensing section of your app, wherever that is.

Email template: redirecting support requests to the portal

Save this as a canned response. When a lost-key, new-machine, or out-of-activations ticket arrives, you spend thirty seconds scanning it, confirm it is one of the three, and send this. No manual lookup, no custom reply:

Subject: Re: License key issue

Hey [name],

You can manage your license yourself at:
https://portal.keylight.dev

From there you can:
• Retrieve your license key if you lost the original email
• See which devices your key is activated on
• Remove an old device to free a slot

If you need a refund or your plan changed, hit reply and I'll take a look directly.

Thanks,
[your name]

The template is intentionally short. Customers in support mode want to solve the problem quickly — a long email asking them to read instructions before clicking a link adds friction. The three bullets tell them exactly what they can do; the closing line tells them what still requires you. No ambiguity on either side.

Notice the last line is honest: refunds and plan changes still go through you. Do not promise the portal handles things it does not handle — a customer who clicks through expecting a refund flow and finds nothing will file a second, more frustrated ticket.

---

The three tickets above account for most of the licensing support load for apps with any real customer base. Eliminating them through a self-service portal is not a luxury — it is the difference between licensing being invisible background infrastructure and licensing being a recurring time drain. If you’re evaluating whether the customer portal alone is worth the integration, count how many of those three tickets you have answered in the last six months. The answer is usually the end of the conversation.

If you have a support pattern the portal doesn’t address yet, send us your feedback and we’ll take a look.