How support works at SkillKit
Every support request at SkillKit becomes a ticket with an ID, a status, and a full history that both you and the support team can see. Tickets are the single channel for everything that needs a human: bug reports, billing and refund questions, account access, listing reports, and feature ideas. Using one channel is deliberate — it means nothing is lost in scattered chat threads, and every promise we make is written down where you can hold us to it.
The pipeline is simple. A submitted ticket enters the queue as pending. A team member picks it up, reproduces or investigates the issue, and replies — the status moves to processing while we work on it, and to resolved when the fix or answer is delivered. You can always reopen a resolved ticket by replying to it; resolution is not a door closing. Tickets keep their history forever, so if a similar issue resurfaces months later, the context is one search away instead of starting from zero.
Response targets: first reply within 24 hours on business days (Monday to Friday), typically much faster. Refund decisions within 24 hours of the request. Withdrawal reviews within 24 hours, settlement within 7 days. During new-release windows we add staffing to keep the first-response target, and any exception is announced on the site banner rather than discovered by waiting.
Before you submit — five things that speed everything up
Most tickets are resolved in a single exchange when they arrive with the right context. Before writing yours, gather these:
- The page URL where the problem happened, and what you clicked immediately before.
- The Skill name and version if the issue involves a specific listing — both are shown on its detail page.
- Your agent and setup if it is an install issue: which agent (Claude, Cursor, other), and where you pasted the install prompt.
- Order ID for anything billing-related — the fastest possible routing shortcut, found in your order history.
- One screenshot of the error or unexpected output. A picture of the wrong state beats three paragraphs describing it.
Signed-in tickets attach your account and order history automatically, which is why we recommend signing in before submitting — it converts several identity-verification round trips into zero.
Submit your ticket
The form below creates a real ticket in the SkillKit system with an ID you can track from your member center. Fields marked required keep the queue fair — tickets we cannot act on get bounced, and nobody wants that round trip.
Ticket types, and when to pick which
🐛 Bug report is for things that do not work as documented: an install that fails, a page that errors, previews that render wrong, a filter that misbehaves. Include the page URL and the click path. Bugs are triaged daily; anything that corrupts financial records or blocks sign-in is escalated immediately.
💳 Billing & payment covers charges, refunds, wallet balance questions and withdrawal status. Always attach the order ID. Refund eligibility is simple — within 72 hours and fewer than three installs — and tickets of this type that meet the policy get approved in the first reply rather than after a negotiation.
💡 Feature request is for the Skill or marketplace capability you wish existed. These are read by the product team, not just support: requests are tagged, deduplicated, and counted. Popular ideas get built, and the changelog credits the earliest requesters. If your idea becomes a Skill, you will be notified.
💬 Other is everything else — account access, listing reports, partnership questions, press. It reaches a generalist who routes internally so you do not have to guess the right department.
Tracking, status meanings, and escalation
Every ticket ID can be tracked from your member center's support panel, which lists your tickets with their statuses and the full reply history. Pending means received and in queue. Processing means a human owns it and is actively working — if a reply needs your input, it will say exactly what is needed. Resolved means an answer or fix was delivered; replying reopens it automatically with the original context intact.
If a ticket misses its target — no first reply within 24 business hours — reply to it with the word escalate. Escalated tickets jump the queue to the on-duty lead, and the response includes what went wrong in routing. We would rather be held to our numbers than have you guess whether silence means progress.
Feedback and the public roadmap
Not every piece of feedback needs a formal ticket, but every piece reaches the same place. Feature ideas become roadmap candidates ranked by the number of distinct requesters — not by who shouts loudest. Bug trends feed directly into the curation checklist for new listings. Even praise is useful: it tells us which parts of the experience are load-bearing and should not be "improved" casually. The changelog on each Skill detail page and the site-wide release notes are where shipped work becomes visible; requesters are credited by name when their idea ships.
Frequently asked questions
Do I need an account to submit a ticket? No — the form works for guests. But signing in first attaches your account and order history automatically, which removes the verification round trip for anything account-related.
Can I attach screenshots? The full attachment picker lives in the floating ticket widget on any page and in the member center; this page's form links your description directly to the ticket. If screenshots are essential, submit via the member center panel.
How do refunds actually work? Within 72 hours of purchase and fewer than three installs, refund requests are approved in the first reply. The creator's commission is clawed back automatically, so there is no awkwardness between you and the creator.
What if my issue is urgent — a payment went through twice? Mark the ticket type as billing and put "duplicate charge" in the first line. Duplicate charges are reversed before the standard 24-hour target, always.
Do you offer live chat? Not yet. The ticket system with written history has proven faster end-to-end than chat for this kind of product — and every promise is searchable later.
What happens after you press submit
Your ticket is written to the support system the instant you press the button, and the ID you see is the permanent key to the whole conversation — every future reply, status change and internal note attaches to it. From there the process is deliberately boring, because boring is reliable. The queue orders tickets by age and severity: anything that blocks sign-in or involves a double charge jumps ahead of cosmetic issues, and everything else is handled first-in, first-out within its type.
When a team member picks up your ticket, their first reply does one of three things. It either resolves the issue outright — most billing questions, policy questions and known bugs fall here — or it reproduces the problem and tells you what happens next, or it asks for one specific piece of missing information. That last category is the only one that benefits from a long description on your side: "the install button does nothing on Chrome after I click Buy" is actionable; "the site is broken" starts a conversation instead of a fix.
If your issue turns out to be a genuine product bug, your ticket becomes part of the fix. Bugs are tagged with the page and flow affected, verified against the next build, and the resolution reply tells you which release carries the fix. You will know your report mattered because the changelog says so — and because the bug you hit stops reproducing.
Service level summary
| Request type | First response | Resolution target |
|---|
| Bug report | Under 24 business hours | Fix shipped in next release, or workaround provided |
| Billing & refund | Under 24 business hours | Eligible refunds approved in first reply |
| Duplicate charge | Immediately escalated | Reversal before the standard target |
| Feature request | Under 24 business hours | Tagged, deduplicated and counted; no time promise |
| Withdrawal review | Under 24 hours | Settled within 7 days |
These targets are commitments, not aspirations — they are the same numbers published in the Terms of Service, and escalations exist for when we miss them. A support system that hides its own numbers is asking for patience without earning it; we would rather publish, miss, explain and fix.