Plan a help center article around the exact question people are actually stuck on, not a rewrite of the feature's documentation

Plan a help center article based on a real cluster of support tickets, not a general rewrite of how the feature works.

TOPIC OR TICKET CLUSTER
About 15 tickets over a month from customers confused about why their scheduled report didn't send — turns out most had the wrong timezone set in their profile, not a bug.

EXISTING ARTICLES
There's an existing 'Setting Up Scheduled Reports' article that covers creation but doesn't mention timezone settings at all.

AUDIENCE TECHNICAL LEVEL
Non-technical end users, mostly small-business owners managing this themselves without an IT person.

PRODUCT AREA
The reporting and scheduling module.

FORMAT CONSTRAINTS
Articles should be under 400 words, use numbered steps for any action, and avoid internal jargon like 'scheduler service'.

STEP 1 — THE ACTUAL QUESTION
State the specific question or point of confusion these tickets actually share, in the customer's own framing, not the feature's official name — people search and get stuck using their own words, and an article titled around internal product terminology won't match what they're actually confused about or searching for.

STEP 2 — CHECK AGAINST WHAT EXISTS
Check the topic against the existing articles given. If something already covers this, state plainly that a new article isn't needed and instead recommend what should change in the existing one — a near-duplicate article fragments the help center and makes both versions less discoverable and more likely to drift out of sync with each other over time. Only plan a genuinely new article if the gap is real.

STEP 3 — OUTLINE SCOPED TO THE ACTUAL CONFUSION
Outline the article scoped tightly to the actual confusion identified in Step 1 — do not expand it into a full feature walkthrough covering everything the feature does, since a customer arriving with one specific stuck point wants that answered quickly, and padding the article with adjacent information they didn't ask about makes the actual answer harder to find. Pitch the language and assumed background at the stated audience technical level.

WHAT NOT TO DO
Do not invent product behavior, menu labels, or steps that weren't confirmed — if a specific UI detail is needed to write an accurate step and wasn't given, flag it as something to confirm before publishing rather than guessing a plausible-sounding label.

OUTPUT FORMAT
1. The actual question/confusion, stated plainly.
2. Existing-article check and recommendation (new article vs. update existing).
3. If new: article title and section-by-section outline.
4. Any UI or product detail that needs confirming before this can be published accurately.