LOCAL

Seasonal local campaign plan

Use when demand for your service is seasonal and you need timed content and profile activity around it.

seasonal-local-campaign.md

Download .md

Plan a seasonal campaign for a local business whose demand rises and falls through the year.

Business and service: {{BUSINESS_AND_SERVICE}}
Area: {{AREA}}
Season or period: {{SEASON}}
What actually drives demand in this period, from our own experience: {{DEMAND_DRIVERS}}
Capacity limits or lead times: {{CAPACITY}}
Offers I am willing to run: {{OFFERS}}

Produce:

1. A timing table with columns: Week (counted relative to peak, so minus four, minus three and so on), What customers are doing then, Content or profile action, Channel (site page, GBP post, GBP offer, email, social), Owner.

2. Two site content pieces worth creating for this season, each with an H1, an outline and the search intent it serves.

3. Six GBP post concepts spread across the run-up, peak and tail, each 150 to 300 characters with the character count shown.

4. A tail plan for what to publish when demand drops, since the page needs to exist before next season.

Rules:
- Start the run-up early enough that content is indexed before peak demand. Say plainly how many weeks before peak the first publication must happen and why.
- Do not promise availability, turnaround times or prices beyond what my capacity and offers state.
- Do not invent weather patterns, local event dates or statistics. Where a date matters, write [CONFIRM DATE].
- No urgency language that is not backed by a real capacity or deadline constraint.
- No em dashes. No opener describing the season in general terms.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{BUSINESS_AND_SERVICE}}
{{AREA}}
{{SEASON}}
{{DEMAND_DRIVERS}}
{{CAPACITY}}
{{OFFERS}}

Getting a better result

Publish the seasonal page once and update it each year rather than creating a new dated page annually.
Your own booking data tells you when the run-up actually starts, which is usually earlier than it feels.
The tail plan is what stops the page going stale and losing its position before the next cycle.

Questions about this prompt

When is this better than a normal content calendar?

When demand genuinely rises and falls and you keep starting too late. A standard calendar counts weeks forward from today. This one counts backwards from peak, so the output states how many weeks before demand the first publication has to happen and why, which is the decision people get wrong.

What do I need to supply?

Your own booking data behind {{DEMAND_DRIVERS}}, real {{CAPACITY}} limits and lead times, and only the {{OFFERS}} you will honour. The prompt will not promise turnaround or prices beyond what you state, and it will not invent weather patterns or event dates, writing [CONFIRM DATE] wherever a date carries weight.

What comes back?

A timing table indexed against peak rather than against the calendar, two site content pieces with outlines and intent, six GBP post concepts of 150 to 300 characters, and a tail plan. The tail plan is the part people skip and the part that keeps the page from going stale before the next cycle.

What is the mistake?

Creating a fresh dated page each year instead of updating the one you have. You spread the same signals across a new URL every season and start again. Watch also for urgency language returning at the editing stage when {{CAPACITY}} does not support it, since the prompt strips it out for a reason.