> ## Documentation Index > Fetch the complete documentation index at: https://docs.usecustory.com/llms.txt > Use this file to discover all available pages before exploring further. # Weekly workflows > See how teams use Custory week to week so a journey turns into a real operating habit instead of a one-time mapping exercise. If your first journey already exists, the next question is simple: what should the team actually do with it every week? Custory is most useful when it becomes part of the team's normal review habit, not a separate documentation project. ## A simple weekly rhythm Most teams do not need a complex process. They usually need four small habits: 1. review the journey 2. triage new signals 3. prioritize the next change 4. connect shipped work back to the map That is enough to keep the journey current, actionable, and worth maintaining. ## 1. Review the journey Use this when the team needs a shared view of what changed in the customer experience. What to review: * new or updated [items](/items) * stale stages or steps * the biggest friction points in the current journey * opportunities that need reframing or closure Keep it short. A 20 to 30 minute review is usually enough for one focused journey. ## 2. Triage new signals Use this when important evidence is arriving from analytics, support, billing, or chat threads and you do not want it to disappear. Typical inputs: * product or revenue signals from PostHog or Stripe * customer feedback in Slack or Discord * notes from support, sales, or onboarding calls The job is not to capture everything. The job is to decide: * does this belong in the journey? * where does it belong? * should it become a touchpoint, insight, metric, or opportunity? ## 3. Prioritize the next change Use this when roadmap or sprint planning is about to happen and you want priorities tied to customer moments instead of isolated tickets. A good planning pass usually looks like this: 1. filter for high-priority or high-impact opportunities 2. inspect the linked evidence 3. compare likely solutions 4. create or update linked delivery work 5. confirm the metric that will validate the change See [Prioritize with customer context](/prioritize-with-customer-context) for the detailed prioritization workflow. ## 4. Connect shipped work back to the map Use this when work has shipped and the journey needs to stay honest. After a release: * link the shipped work to the relevant [solution](/items#solutions) * update the journey if the customer experience changed * check the validating [metric](/metrics) * add a follow-up insight if the result was different from what the team expected This is what keeps the journey aligned with the product. ## Where automations help These habits can start manually, then get lighter with automation. Good first fits: * [Weekly journey pulse](/automation-templates) for the review rhythm * [PostHog event drift](/automation-templates) for signal triage * [Priority focus](/automation-templates) for planning follow-through * [GitHub merged PR journey refresh](/automation-templates) for shipping updates Automations work best after the manual habit already makes sense. ## Example week for a small product team Monday: * review the journey for 20 minutes * triage new signals from the last week Wednesday: * compare the top opportunities * choose one or two responses to move into delivery Friday: * connect shipped work back to the journey * check whether the expected metric is moving That is enough to make Custory operational without turning it into heavy process. ## Weekly rhythm mistakes to avoid If the team only looks at the journey occasionally, it will drift. Weekly light-touch review is usually better than rare big cleanup sessions. A signal only helps if the next person can see what it meant and what happened because of it. Convert important inputs into linked items. The journey should reflect the current product. If the product changed but the journey did not, the team loses trust in the system quickly. ## Next step Read [Automations](/automations) when you want to reduce the repeated manual parts of these workflows. Read [Integrations](/integrations) if your team needs the right signal sources and delivery tools connected first.