the hour the founder bottleneck shows up
If you are personally approving refunds after 10pm, your refund process is the symptom, not the disease.
If you are an info-product creator and you are personally answering refund tickets at 11pm, you do not have a refund problem. You have an operational structure problem, and the refunds are the visible part of it.
This is one of the most common patterns we see in $500K to $5M ARR info-product businesses (courses, memberships, coaching programs). The founder personally approves every refund because they are afraid that a team member will give one away when they shouldn't, or refuse one when they should. The fear is rational. The solution is not to be the one approving every refund forever.
Here is what is actually happening, and the workflow that gets refunds off the founder's plate without raising the refund rate.
Why the founder ends up at 11pm
Three structural reasons.
Reason 1: the refund policy is in the founder's head, not in a doc. The policy is some version of “we offer a 14-day guarantee, but exceptions can happen if the customer has a real reason.” The exceptions are the entire issue. The founder is the only person who knows what counts as a real reason. So every exception ticket flows to the founder.
Reason 2: the dollar value feels significant enough to warrant founder review. An info-product refund is $497, $997, $2,000+ depending on the product. To a VA making $5/hour, this feels like a lot of money to be making decisions about. They escalate.
Reason 3: the founder doesn't trust the team to defend the brand. Refund conversations are emotionally charged. A poorly-handled refund response generates a 1-star review or a public complaint. The founder reads every refund response and rewrites it. Eventually they just write them all.
So at 11pm, after the day's customer-facing work is done, the founder sits down and processes the refund queue. This is the worst part of being a 7-figure info-product creator.
Refund tickets at 11pm are not a refund problem. They are the place where the founder's refusal to document their judgment becomes a Tuesday-night ritual.
What a refund workflow that holds actually looks like
The fix is the same in every business: document the judgment, build the approval tiers, train the team against the documentation, audit weekly.
Step 1: write the actual refund policy. Not the marketing one. The real one. Include every exception. “If the customer is more than 14 days in but is under 30 and hasn't logged in more than 3 times, approve.” “If the customer claims technical issues and we don't have logs of them contacting support first, decline but offer 30 more days of access.” “If the customer's purchase amount is over $2,000 and they have completed the core curriculum, escalate to me but I'll approve 9 times out of 10.”
This document is uncomfortable to write because it forces you to articulate edge-case judgment. The discomfort is the point. If you can't write it, no one else can be expected to execute it.
Step 2: build the approval tiers.
- Tier 1 (VA or support specialist, no approval needed): refunds within the standard policy window. Customer says “not for me, refund please” within 14 days. Standard reply, processed immediately.
- Tier 2 (senior support, no approval needed but logged): exception cases that match a documented exception pattern. Logged daily for founder review.
- Tier 3 (founder approval required): novel situations not covered by the policy. Reviewed within 48 hours. Resolution gets added to the policy doc for next time.
Step 3: train the team against the doc. This is a 2-hour session, then a series of mock refunds where you grade their decisions. You will disagree with some. The disagreements are how the policy doc gets sharpened. After 3 to 4 weeks, the team is making the same decisions you would.
Step 4: audit weekly. Once a week, the founder reviews a random sample of 5 refunds the team approved without escalation. If they all match how you would have decided, the system works. If you disagree with one, you discuss with the team and update the policy doc.
The goal: 90%+ of refunds resolved without founder approval. The remaining 10% flow through Tier 3 with a 48-hour SLA, not an 11pm ritual.
What this is worth in founder hours
Real math from a creator we worked with last year:
- Refund volume: 35 per week
- Founder time per refund (when they personally handle): 8 to 12 minutes
- Weekly founder hours on refunds before the workflow: 5 to 7 hours
- After the workflow (Tier 3 only): 30 to 45 minutes per week
- Weekly hours saved: 4 to 6
- Annualized: 200+ hours per year
200 hours is more than a month of full-time work. The creator was paying themselves to be a refund clerk because the workflow didn't exist.
Why this connects to the rest of your operations
The refund workflow is not an isolated fix. It is one specific instance of the broader 4 ops functions every 7-figure creator needs pattern: customer support is the first function to break, and refunds are the most-escalation-prone subset of customer support.
Building this workflow well requires the same infrastructure as building the rest of your customer support ops: documented patterns, tiered approval, trained team, weekly audit. The investment compounds across all your ops work, not just refunds.
For most info-product creators between $500K and $5M ARR, this is one of the first three operational fixes to make. The other two are usually community management at the $1M wall and newsletter ops cadence.
The diagnostic question
Open your calendar. Look at last week. How many evenings (after 9pm) did you spend on customer support, refunds, or community management tasks?
If the answer is more than one, you have the founder-bottleneck pattern. The fix is structural, not personal. Drinking more coffee will not help. Building the workflow will.