Case Study: Workflow Automation
How We Turned 295 Instagram Accounts Into an Automated WordPress Events Pipeline
Local organizations announce events on Instagram and nowhere else. For one Florida community directory, that meant 295 source accounts full of events someone had to find and retype by hand, or miss entirely.
Jezreel Dinglasan and the 1StepAhead team built a pipeline that scrapes those accounts on a schedule, automatically filters and extracts real events with AI, removes duplicates, and delivers the results into the WordPress Pending Review queue the site already trusted. Events that previously required manual discovery and re-entry now arrive in one familiar review queue, ready for approval. Zero events publish automatically. A human approves everything that goes live.
From signed proposal to the full 295-account rollout took 21 days, most of it deliberate soak testing rather than continuous development. This is the complete build log, including what broke along the way.
At a glance
- Client
- Zushi’s List, a Jewish community directory for Florida
- Built by
- Jezreel Dinglasan and the 1StepAhead team
- Problem
- ~295 Instagram accounts announcing events that never reached the site’s calendar
- Solution
- Scheduled scrape → AI extraction → deduplicated calendar feed → WordPress Pending Review
- Timeline
- Proposal June 22 → paid pilot June 30 → full rollout July 13, 2026
- Final cycle
- 2,045 posts in, 56 clean events out, 31-minute runtime
- Auto-published
- Zero. A human approves every event
The client problem
Zushi’s List runs a busy events calendar on a serious WordPress stack: The Events Calendar Pro with Event Aggregator, already importing 12 structured feeds from Google Calendars and Eventbrite. Structured sources were solved. The gap was everything else.
Most local organizations publish no calendar feed at all. They announce events one way: an Instagram post, often a flyer image with the details baked into the picture. Getting one of those onto the calendar meant a person had to spot the post, read the date and venue out of a caption or flyer, retype everything into WordPress, re-upload the image, and pick a category. Across roughly 295 accounts, that work simply did not happen. Earlier scraping attempts had stalled on configuration and reliability issues that the pilot helped isolate.
Our bet was that we did not need to build a publishing system, because the site already had one. If we could turn messy Instagram posts into one clean, standards-compliant calendar feed, the site’s mature, widely used WordPress import machinery could treat us like just another calendar source, and the founder’s existing review workflow would not change at all.
The final automated workflow
- 1
Scheduled scraping
Pulls the most recent posts from every account on the list, on a fixed schedule.
- 2
A cheap text pre-filter
Discards posts that are obviously not events (quotes, recaps, congratulations) before any AI cost is spent. In the final cycle this cut 2,045 raw posts to a few hundred candidates.
- 3
AI extraction
Claude reads each candidate and returns structured fields: title, date, time, venue, description, category, image, and source link. When the caption is not enough, which is common because many events live entirely on flyer images, it reads the image too.
- 4
Stale-date filtering
Drops anything already in the past, re-checked against the current date on every run.
- 5
Category mapping
Places each event into the site’s existing category taxonomy, so nothing arrives uncategorized.
- 6
Three layers of duplicate control
Catch exact repeats, near-duplicates within a run, and the same event cross-posted by different accounts across runs.
- 7
A deterministic calendar feed
Publishes the clean events as a standards-compliant ICS feed at a stable URL. Every event carries a stable ID, so re-imports update existing records instead of duplicating them.
- 8
WordPress does the last mile
Event Aggregator polls the feed on its own schedule and creates each event as Pending Review, with the flyer sideloaded into the Media Library, a real linked venue, and real category checkboxes ticked.
- 9
A human approves
The pipeline has no publish permission at all.
The final outcome
First full 295-account cycle, fully unattended.
295
Instagram accounts scraped
2,045
Posts pulled
362
Potential events extracted
302
Already-past events filtered out
56
Final clean events in the feed
27
New WordPress events created
26
Existing events updated in place
100%
Flyer image coverage
98.2%
Category coverage
31 min
End-to-end runtime
0
Events published automatically
Of the posts that reached the AI stage, 342 required fresh reads and 179 more were answered from cache, extraction work already paid for on earlier runs. All 27 new events landed in Pending Review with their flyer, venue, category, and source link attached. Two days later the second full cycle ran hands-free with a warm cache, confirming steady state. Founder Yael Suissa engaged with the queue from the first unattended test cycle onward, reviewing and publishing real events during the rollout itself.
“Before Jez set up the automation, keeping our events updated was a very manual and time-consuming process. Jez was incredibly patient throughout the entire setup, explained everything clearly, and made sure I understood how it all worked. Now the system runs so much more efficiently, saves us a ton of time, and has made managing events for Zushi’s List so much easier. I couldn’t be happier with the result!”
Rollout timeline
Each stage had to run clean, unattended, before the next was allowed. We verified every rollout stage against a defined QA checklist before increasing account volume.
Paid pilot (18 accounts)
One controlled scrape and extraction pass in a sandbox
What it had to prove
The data is real: genuine events cleanly separable from noise on the client’s actual accounts
40-account daily schedule
Multiple unattended daily cycles, including three consecutive soak cycles after the optimization release
What it had to prove
The full loop fires on schedule with nobody watching, and re-imports stay duplicate-free
100-account test
A controlled run, then a full scheduled cycle
What it had to prove
The cost model holds at scale, and cross-post duplicate handling works on real data
295-account rollout
Full list, three scheduled cycles per week
What it had to prove
The production system, verified end to end
Smaller 10-account regression runs were also used along the way while fixing specific date-handling and feed issues. Those were controlled test reps, separate from the 18-account paid pilot. Two details we would defend to any engineer: every test event created during QA was tracked individually and removed before the client’s real queue went live, with the pre-existing published calendar count-verified untouched at every stage; and a written rollback plan existed before the full-list flip.
The build, step by step
The short version: scope and architecture in week one, a paid pilot to prove extraction quality on real data, one day of import-path testing that changed the architecture, then progressively larger unattended cycles until the full list earned its turn. In the initial pilot sample, roughly 42% of scraped posts were genuine upcoming events, which settled the core question early: the data was good enough to build on.
The full build diary, date by date+
Proposal and technical scoping. A read-only inspection of the WordPress stack confirmed the available import paths, and the feed-based architecture was chosen the same day.
Paid pilot on a sandbox account: 18 representative Instagram accounts. Extraction quality proved out, and the pilot isolated the configuration and reliability issues that had stalled earlier scraping attempts.
Import architecture QA in the morning (CSV ruled out, ICS in). Idempotency QA in the afternoon: the same feed imported twice produced zero duplicates, and one stable-ID gap was found and fixed. By evening, all 13 QA test events were cleaned out and a controlled 40-account daily schedule was enabled.
The first fully unattended cycle ran end to end: scheduled scrape, feed regeneration, automatic WordPress import, three new events in Pending Review. The founder reviewed and published two of them the same morning, unprompted.
Efficiency and duplicate-control release, built against 26 unit tests: fewer posts pulled per account, an extraction cache, and a cross-post duplicate registry. Three consecutive clean soak cycles followed at 40 accounts.
A controlled 100-account test, then a full scheduled 100-account cycle, including the first real cross-post merge handled correctly in production.
Costs reviewed with the client in plain terms, cadence chosen (three cycles per week), cost controls put in place, and the schedule flipped to the full list with a documented rollback plan.
First full 295-account scheduled cycle. The numbers above.
Second full cycle, fully hands-free, confirming steady state.
What our testing caught before launch
Automation projects do not fail on the happy path. They fail on integration details, and every issue below was caught by our own testing before it could reach the client’s live calendar. That is what the QA time in the schedule was for.
The one that changed the architecture: CSV was a dead end
The obvious first path was CSV import, and it mostly worked in a manual test. Two problems killed it. The importer only accepts CSV as a manual file upload, with no URL it can poll, which means a human uploading a file every day forever. Worse, the CSV path silently dropped one of seven test events with no error shown. A pipeline that loses data without telling you is disqualified on the spot.
The fix was ICS, through the right door
The importer has both an “Other URL” option and a dedicated “iCalendar” option, and they are not interchangeable. “Other URL” rejected our feed outright; it is a webpage scraper, not a calendar importer. The dedicated iCalendar origin, pointed at the same feed URL, imported all 8 test events with the required fields intact: flyer images in the Media Library, real linked venues, real category checkboxes, source links preserved, everything in Pending Review. One dropdown choice was the difference between impossible and done.
Duplicates were treated as the default, not an edge case
Community accounts cross-post constantly. Three automated layers handle it (details in the FAQ), merging only at high confidence and flagging uncertain pairs for human review instead of silently merging them. One honest miss during testing: the same real-world event, announced in two very differently worded posts, was published twice by human review. No automated threshold could safely catch that pair, which is exactly why the review layer exists and why reviewer guidance is part of the delivered workflow.
Technical detail: stale-date edge cases+
Instagram scraping looks backward, so a window of recent posts always includes events that already happened. In the final cycle, 302 of 362 extracted events were already in the past. The past-date filter therefore runs at feed-build time, against the current date, on every cycle, including over cached extractions. Verified live: a warm-cache run correctly re-filtered 41 past-dated events out of 51 cached extractions.
Technical detail: deterministic event IDs+
Every event carries a stable unique ID generated from its Instagram post’s permanent link, so the same post always produces the same ID and WordPress treats re-imports as updates, not new events. Testing exposed a real gap: for rare posts with no usable link, the fallback ID was built from the raw title, and the AI occasionally rewords titles between runs, which would have created duplicates. The fix normalizes the title before hashing, only in that fallback path. Verified in production: titles drifted between runs and the IDs held identical, and a full same-feed re-import produced zero duplicates.
Technical detail: caching and cost engineering+
Before scaling from 40 accounts to 295, cost was engineered down: fewer posts pulled per account (the deeper posts were mostly stale or non-events) and an extraction cache keyed to each post’s permanent link, so the AI never pays to re-read a post it has already processed. Caching the “not an event” verdicts is the biggest saving, since most posts are not events. Verified against QA records: these controlled caching and scraping optimizations reduced steady-state processing cost by more than half, and operating costs were reviewed with the client, with usage controls in place, before the full list ever turned on.
Technical detail: the platform restart incident+
A platform restart caused one full scrape to run twice. Event data remained intact, but it exposed a cost-resilience improvement for ongoing maintenance: checkpointing scrape progress so an infrastructure restart resumes work instead of repeating it. Identified, scoped, and on the maintenance roadmap.
What remains human
This system removes drudgery, not people.
Editorial control
Every event is approved by a human before it appears on the site. The pipeline cannot publish. This is permanent design, not a temporary setting.
Judgment calls
Hard duplicates with dissimilar wording, borderline events, and community fit are human decisions, and the system is tuned to surface rather than hide them.
The change
What used to be find, read, retype, re-upload, and categorize is now a review of a pre-filled queue.
Lessons and broader applications
- 1
The last mile decides the architecture
AI extraction was never the riskiest part. Which import path WordPress will actually poll on a schedule was. Test the boring integration point first.
- 2
Silent failure disqualifies
CSV lost a row without an error. Anything that loses data quietly is out, whatever its other merits.
- 3
Make re-runs boring
Stable IDs and verified idempotency are what turn “run it again” into a safe operation instead of a duplicate factory.
- 4
Under-merge, then let humans finish
A duplicate in a review queue costs seconds. A real event silently hidden costs trust. Pick your failure direction deliberately.
- 5
Scale is earned, not scheduled
Every account-list increase happened only after unattended cycles ran clean at the previous size, and after the client saw the cost picture and chose the cadence herself.
The pattern is not specific to events or Instagram. Wherever announcements live in unstructured posts, emails, PDFs, or images and a person retypes them into a structured system (a CRM, a booking tool, a catalog, a calendar), the same shape applies: extraction with AI, deduplication with discipline, and your existing review workflow kept exactly where it is.
Show Us the Workflow You Want to Stop Doing Manually
We’ll help you map the process, identify what should and should not be automated, and define a controlled pilot before building the full system.
Show Us Your WorkflowTechnical FAQ
Why not auto-publish?+
Because extraction from human-written captions and flyers will never be perfect, and a community calendar’s credibility is the product. The review queue costs minutes and catches everything from wrong dates to hard duplicates. Auto-publish was excluded in the original design and remains excluded.
Why ICS instead of CSV?+
CSV import in this stack is manual-upload only, so it can never be hands-free, and in live testing it silently dropped a row. The ICS calendar-feed path supports scheduled polling, imported with full fidelity (images, venues, categories, source links), and carries stable per-event IDs that make re-imports update instead of duplicate.
Can this work for other industries?+
Yes. The pipeline shape (scrape, filter, AI extraction, dedupe, feed, existing system, human review) applies to any flow where unstructured announcements need to become structured records: restaurant specials, gym schedules, open houses, nonprofit programs, municipal notices.
Does it require WordPress?+
No. WordPress with Event Aggregator was the right last mile here because the client already ran it. The pipeline outputs a standards-compliant iCalendar feed that many systems can consume, and the same extraction pipeline can feed an API, a database, or a different CMS instead.
How are duplicates handled?+
Three automated layers: exact-duplicate removal, near-duplicate removal within each run (same date and highly similar titles, with a rule that refuses to merge different venues), and a persistent cross-post registry that recognizes the same event announced by different accounts across runs and updates the existing record instead of creating a new one. Merges happen only at high confidence; uncertain pairs are surfaced for human review, never silently merged.
What happens when Instagram changes?+
Scraping any platform is inherently fragile, and we say so in writing rather than pretending otherwise. Every cycle emits a QA summary, failures are loud rather than silent, and platform breakage is handled under ongoing maintenance. The WordPress side is unaffected; the worst case is a paused intake, never corrupted data.