Tip Goal Overlay Reset Rules for Long Streams

Long streams break vague goals

A tip goal that works for a three-hour desk stream can become confusing during a twelve-hour IRL day, subathon, charity block, or sponsor event. Viewers may ask whether the goal already completed, whether the next milestone started, whether offline tips count, whether refunds reduce the bar, and why the overlay reset while they were gone.

The fix is to decide reset rules before opening the overlay. The goal can reset by stream, by segment, by milestone, by day, by manual producer call, or by campaign. What matters is that viewers can understand the state without asking a moderator every ten minutes.

StreamableBot should treat a tip goal as a live production object, not a random progress bar. It needs a clear label, current goal, reset rule, contribution rules, replay behavior, and moderator controls.

• Stream goal: one bar for the whole live session.
• Segment goal: separate bars for IRL, desk, sponsor, or game blocks.
• Milestone ladder: each completed goal unlocks the next one.
• Daily goal: resets at a posted time, not whenever the browser source reloads.
• Campaign goal: survives multiple streams until the campaign ends.

Pick the reset model that matches the promise

The reset model should follow what viewers are funding. If viewers are funding tonight's food stream, reset by segment or stream. If they are funding a new camera, use a campaign goal that survives multiple streams. If they are funding challenges during a subathon, use milestone resets with clear unlocks.

Do not use a daily reset for a goal that viewers expect to roll over. Do not use a campaign goal for a joke that expires after one segment. The bar is a promise, and the reset model tells viewers what their money is doing.

When the stream changes mode, update the label. Dinner goal is different from afterparty goal. Travel battery fund is different from sponsor bonus challenge. Labels prevent viewers from feeling like the bar moved without explanation.

• One-night reward: stream or segment reset.
• Subathon extension: milestone ladder with posted increments.
• Charity block: campaign goal with careful public accounting.
• Equipment fund: campaign goal across streams.
• Sponsor event: segment goal with approved copy and reset time.

Make overlay state obvious

The overlay should show enough state to answer viewer questions. Current amount, target, goal name, reset model, and whether the goal is active, paused, completed, or rolling over. A plain progress bar with no context becomes confusing fast during long streams.

OBS Browser Source makes this possible, but it also creates failure points. If the browser source refreshes, hides, or reloads, the displayed state should not lose the goal. Keep the real goal state in the bot, not only inside the visible overlay.

Use short labels. Dinner goal, 2 of 5 milestones, campaign total, paused during sponsor, rolls over after break. Viewers should not need a moderator essay to know what the bar means.

• Active: contributions are counting toward this goal.
• Paused: contributions may still process, but the goal is not changing on screen.
• Completed: target reached and awaiting reset or next milestone.
• Rolled over: extra amount moved into the next goal.
• Manual review: payment or refund adjustment pending owner action.

Moderators need reset permissions

Not every moderator should be able to reset a money-facing overlay. A misclick can erase viewer trust even if the underlying payment data still exists. Give reset, rollback, manual adjustment, and campaign-close permissions only to trusted roles.

Regular mods can mark playback failures, answer viewer questions, and pause the overlay during risky segments. Lead mods or the account owner can reset goals, apply offline adjustments, or close a campaign. That role split keeps the stream moving without making every mod a finance operator.

Every reset should leave a log entry. Who reset it, when, from what amount, to what amount, and why. The log does not need to be public, but it should exist so the team can answer questions after the stream.

• Viewer mod: answer questions and flag issues.
• Queue mod: pause or resume visible goal moments.
• Lead mod: trigger pre-approved segment reset.
• Owner: manual payment adjustment, refund review, campaign close.
• System log: record every reset and adjustment.

Handle refunds and disputes away from the overlay

A viewer refund, chargeback, or payment dispute should not instantly create a public bar argument. Stripe and PayPal have their own refund and dispute flows, and those decisions should be handled by the account owner outside the live show.

The overlay can show a manual adjustment if the owner chooses, but the chat does not need private payment details. A mod can say the owner will review payment adjustments after stream. They should not read transaction IDs, billing emails, or dispute notes on air.

This is especially important for charity and sponsored goals. If public accounting matters, keep a clean campaign record and update the public total deliberately. Do not let the browser source become the only source of truth.

• Do not expose payment identifiers in chat.
• Do not let every mod issue manual money adjustments.
• Use owner review for refunds and disputes.
• Keep campaign records separate from visual overlay state.
• Explain public adjustments with short, non-private labels.

Use rollover rules before extra money arrives

The most common tip-goal fight happens when a goal completes and extra money arrives before the next bar appears. Does the extra amount roll into the next goal? Does it count as bonus support? Does it unlock another challenge? Decide before the stream.

Rollover is usually best for milestone ladders. If viewers push goal one past the target, the extra amount starts goal two. No rollover can make sense for one-off segment goals, where the promise was tied to a specific moment. Campaign goals should usually keep a total rather than resetting visually after each hit.

Put the rule in the overlay copy. Extra rolls into next goal. Extra stays as bonus support. Campaign total does not reset. That one line prevents a lot of chat confusion.

• Milestone ladder: rollover extra by default.
• One-off segment: no rollover unless posted.
• Campaign: keep cumulative total.
• Charity: follow the campaign's accounting rules.
• Sponsor: use approved reset and rollover copy.

Long stream examples

IRL food day: lunch goal resets after the lunch segment, dinner goal starts later, extra lunch support does not automatically become dinner unless the overlay says it rolls over. The producer switches labels when the stream changes location.

Subathon: each goal adds a posted amount of time or unlocks a challenge. Extra rolls into the next milestone. Mods can pause goal alerts during sleep, guest, or travel segments while the campaign total stays accurate.

Charity block: the campaign total stays persistent across breaks and streams. Public adjustments are handled carefully by the owner. The overlay can show current campaign total, source, and verified update time instead of a reset-happy bar.

• Food stream: segment labels and reset times.
• Subathon: milestone ladder and rollover.
• Charity: campaign total and owner-controlled adjustments.
• Sponsor: approved copy and limited reset permissions.
• IRL travel: pause visible goal during unsafe or private moments.

Reset checklist before going live

Before the stream starts, write down the goal name, target, reset type, rollover rule, who can reset it, what happens after completion, and how refunds or adjustments are handled. Then test the browser source.

Send a small test contribution, complete a fake goal, roll it over if needed, pause it, reset it, and reload the browser source. If the visual state and internal state disagree, fix that before viewers pay.

After the stream, export or review the goal log. Look for confusing resets, unclear labels, mod mistakes, and moments where viewers asked the same question repeatedly. That is where the next goal copy should improve.

• Goal label and target set.
• Reset model selected.
• Rollover rule posted.
• Reset permissions assigned.
• Refund and adjustment owner named.
• Browser source reload tested.
• Completion and next-goal behavior tested.

Other resources

Use these docs when connecting paid support, platform monetization, browser-source overlays, and refund handling.

• Twitch Help: Guide to Cheering with Bits.
• YouTube Help: Manage Super Chat & Super Stickers.
• OBS: Browser Source.
• Stripe Docs: Refunds.
• PayPal Help: How do I get a refund?