Don’t let the friction stay hidden in dashboards
Without automation, a PostHog drop stays in a dashboard until someone notices it, discusses it, writes a ticket, and maps it back to the journey. That loop is slow and often breaks. Custory closes it automatically.
Custory turns analytics and customer signals into journey updates, follow-up work, and team notifications so important changes do not stay trapped in separate dashboards.
Automations
Custory automations help teams keep the journey current without constant manual upkeep. They watch for changes on a schedule or from connected systems, then update journey context, create follow-up work, or send the right update to the team so customer understanding keeps moving with the product.
The core loop is simple: a signal comes in, Custory interprets it in journey context, and the system either updates the map, creates the next action, or notifies the right people. That makes automations useful for the work product teams already do every week: keeping metrics fresh, spotting new friction, and turning changes into visible follow-up.
Because the automation system is built around Custory objects, the output stays useful inside the product rather than becoming another disconnected alert stream. The result is less maintenance work and a journey system that stays much closer to reality.
Starts from: A schedule, a product signal, a GitHub event, or a change inside Custory
Can do: Update journey context, create follow-up work, refresh priorities, or send team updates
Why teams use it: To keep customer understanding current without adding more manual process
Set Up with AI
Describe the outcome you want in plain language and Custory drafts the automation around it. A product lead can say “pull weekly PostHog funnel data, update the onboarding journey, and flag new drop-off risk” and start from a strong first draft inside the editor, then fine-tune the workflow visually before turning it on.
This is how Custory treats AI: as a faster way to get from intent to a usable workflow. The draft maps your goal into concrete triggers, actions, connected integrations, and journey updates, then hands everything back to the editor so the team can inspect, adjust, and approve the final version with confidence.
That is especially valuable for lean teams that want the leverage of automation without becoming automation specialists. AI removes the blank page, while the editor keeps the workflow readable, flexible, and fully under the team’s control.
Input: A plain-language goal such as pulling analytics, posting updates, or creating new journey insights
Output: A drafted automation with trigger logic, actions, and the right journey scope already mapped
Why it matters: Teams get to a high-quality workflow faster, then refine it in the editor instead of starting from zero
Templates
Templates give teams a fast, opinionated starting point for recurring Custory workflows. Instead of starting from scratch, you can begin with patterns designed to keep journeys current, surface high-signal customer changes, and route the right follow-up into the rest of your stack.
The strongest templates are not just generic automations. They are pre-shaped around the way Custory works: structured journey context in the middle, connected signals on one side, and execution or team updates on the other. That makes them especially useful for teams who want fast setup without losing the logic of why the workflow exists.
Examples: Weekly journey pulse, PostHog event drift updates, active team member recaps, and priority handoff flows
Editable: Yes, teams can change triggers, actions, AI-drafted text, integrations, and scope
Why it matters: The team gets to a useful Custory workflow quickly without rebuilding the same operating logic every time
Triggers
Automations in Custory can run on a schedule or react to events, which means the journey can stay current without manual policing. You can review metrics every Monday morning, react when an item crosses a priority threshold, or listen for GitHub pull requests opening or merging.
This is where the product moves from static system to current system. Time-based triggers handle recurring monitoring and reporting. Event-based triggers react when something actually changes, so updates land when they are relevant instead of after someone remembers to follow up.
That helps teams catch friction, quality issues, and priority shifts earlier. Instead of waiting for a weekly meeting to notice that onboarding dropped, a PR merged, or an item’s impact changed, the system can move first and bring the right context with it.
Schedule: Hourly, daily, or weekly runs for recurring reporting, monitoring, and updates
Event: Custory item events and GitHub events such as item updates, threshold changes, PR opened, and PR merged
Why it matters: The journey stays current because important changes can trigger action automatically, not only on review day
Integrations
Connected integrations turn automations into real operating workflows instead of internal reminders. An automation can read product signal from PostHog, create or update a journey insight in Custory, notify the team in Slack, and open follow-up work in GitHub or another connected system as one continuous flow.
Signals can come in from the tools your team already uses, and the output can land exactly where the next decision or action should happen. Custory keeps the journey in the middle, so the workflow feels connected instead of improvised.
Instead of pushing generic notifications around the stack, teams can create workflows that refresh journey context, send focused updates, and open follow-up work while keeping the original customer problem visible.
Analytics: PostHog and Stripe as connected signal sources for behavior and revenue context
Execution: GitHub and connected work systems for follow-up actions and product delivery loops
Communication: Slack and Discord for alerts, summaries, and keeping the team aligned in-channel
Why it matters: Workflows can read from one system, update Custory, and push the next action outward without losing context