The forecast is built on opportunities with close dates in the past and no activity for six weeks. Here is the model behind a dashboard that says so, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
A pipeline hygiene dashboard is four parts: rules describing a well-maintained opportunity, an evaluation of every open deal against them, a short per-rep worklist rather than a company report, and a trend over time. The trap is building a report that only management reads. Hygiene improves when the person who can fix a record sees a short list of their own records and nothing else, and when the list is short enough to clear before a Monday call.
Pipeline hygiene
6
On your list today
2.4M
Flagged pipeline value
41%
Of pipeline at risk
+12
Score, last 30 days
Ranked by flagged pipeline value, not by record count. The two highlighted rules account for 1.9M of the 2.4M at risk.
You run revenue operations or a sales team. You already know your stages and your forecast categories. What you want is for the pipeline review to stop being an argument about data quality and start being a conversation about deals.
What a rep sees on a Monday, and what a manager opens before a pipeline review.
Close date in the past, no recent activity, missing next step, too long in stage, and whatever else you decide healthy means here.
Their own records only, ranked by forecast impact, capped at a length they can clear before a Monday call.
Simple fields are editable inline; anything else jumps straight to the CRM record.
Teams ranked by flagged pipeline value rather than flagged record count, so the review starts with what matters.
Total pipeline, and how much of it fails at least one high-weight rule.
Score snapshotted daily, charted, and overlaid with forecast accuracy once quarters close.
A hygiene dashboard is not a list of empty fields. It is four parts, and the third one decides whether anything actually gets fixed.
What a healthy opportunity looks like in your business: close date in the future, activity within a threshold, next step present, stage consistent with the amount of time spent in it, required fields complete for the current stage.
Every open opportunity checked against every applicable rule, with the result attached to the record rather than aggregated away. Aggregates tell you there is a problem; the record-level result is what someone acts on.
Each rep sees only their own flagged records, ranked by forecast impact, capped at a length they can clear. This is the part that changes behaviour.
Hygiene score per team over time, alongside forecast accuracy. Without the trend you cannot tell whether a clean-up stuck or whether it happened once before a board meeting.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
Rules first, because the rules are the opinion and the rest is plumbing.
In this Helix project, build me a pipeline hygiene dashboard.
Start with the rules, in one file I can edit, because they are the part
that is specific to us. Give each rule an id, a description, the
condition, a weight, and the stages it applies to. Seed it with these:
close date in the past, no activity in a set number of days, next step
missing or overdue, too long in the current stage, amount missing or zero,
and forecast category inconsistent with stage.
Weight them by how much they distort the forecast, not by how easy they
are to check. Otherwise the whole thing gets dominated by trivia.
Then load opportunities from a CSV to start, with a clear route to pulling
them from the CRM on a schedule later, and evaluate every open deal
against every rule that applies. Store the result on the record with a
plain sentence explaining what is wrong.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.The one screen that actually changes the data.
Now build the screen that does the work.
Each rep sees only their own flagged opportunities, ranked by forecast
impact: rule weight multiplied by deal value, weighted higher for
late-stage deals. Cap the list at a number I set, around ten. Show the
count of what is below the cap but do not list it.
Each row shows the deal, the specific problem in one sentence, and the
field that needs changing. Not every rule it failed, just the one worth
acting on.
Let them fix simple fields right there, and jump to the CRM record for
anything else. And when the list is empty, say so properly. That sounds
trivial and it is the reason people come back tomorrow.Ranking by money rather than by count.
Add the manager view, and rank by flagged pipeline value rather than
flagged record count. A blank field on a tiny early-stage deal should
never outrank a stale close date on the biggest one.
Per team and per rep: hygiene score, flagged records, flagged pipeline
value, and the split by rule.
Then the number worth putting in a forecast conversation: total pipeline,
and how much of it fails at least one high-weight rule. That second figure
is the honest version of the first.
Highlight deals whose close date has moved more than twice. That is a
stronger slip signal than any single stale date.Trends, and the overlay that ends the argument.
Snapshot the hygiene score per team daily and chart it, so I can see
whether a clean-up stuck or happened once before a board meeting.
Then, if I give you closed data, overlay forecast accuracy for the same
periods. Until you can do that, hygiene is a preference. Afterwards it is
a number, and the conversation changes.
Refresh from the CRM on a schedule, record when the last successful sync
happened and show it on every page. If a sync fails, say so on the screen
rather than serving stale data quietly. And send each rep and each manager
a weekly digest of their current list.Worth knowing. The forecast accuracy overlay is the part that wins the argument. It is also the part most dashboards never build.
The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<Salesforce>. Pull every open opportunity on a schedule, with stage,
activity and next step, and optionally write simple field fixes back so a
rep can clear the list without leaving it.
<Okta>. Match the CRM's opportunity owner to a signed-in person and their
team, which is what lets the app give each rep their own list.
<Slack>. Send each rep their short weekly list, which is what makes the
data actually get fixed.
<Gong>. Read call and email activity, which is a truer engagement signal
than a logged task.
<Snowflake>. Read historical pipeline for the trend, since the CRM only
holds the current state.
<Looker>. Feed the team view into the weekly sales dashboard, so hygiene
sits beside the number it distorts.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. This app ranks people by their data quality, so set Access Control before sharing: reps see their own list, managers see their team.
This app reads a lot and writes almost nothing. Its job is to tell people what to go and fix in the CRM.
Salesforce
Pull every open opportunity on a schedule, with stage, activity and next step, and optionally write simple field fixes back so a rep can clear the list without leaving it.
Okta
Match the CRM's opportunity owner to a signed-in person and their team, which is what lets the app give each rep their own list.
Slack
Send each rep their short weekly list, which is what makes the data actually get fixed.
Gong
Read call and email activity, which is a truer engagement signal than a logged task.
Snowflake
Read historical pipeline for the trend, since the CRM only holds the current state.
Looker
Feed the team view into the weekly sales dashboard, so hygiene sits beside the number it distorts.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working dashboard. It reads live pipeline, ranks people by their data quality, and feeds a forecast conversation, so how it is run matters as much as what it computes.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
Pipeline data and per-rep rankings are sensitive. SSO means people sign in with their existing account, and access is scoped so a rep sees their own list while a manager sees their team.
App Security
Reading opportunities on a schedule needs real CRM access. Granting it to the app rather than pasting a key into it means it can be rotated or revoked without a redeploy.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
It checks every open opportunity against rules describing what a well-maintained deal looks like, then gives each rep a short list of their own records to fix. Its purpose is to stop pipeline reviews being an argument about data quality.
Close date in the past, no activity within a threshold, missing or overdue next step, excessive time in stage, and a forecast category inconsistent with the stage. Close dates in the past are the highest value because they are a forecast error already in flight.
Because they are built for management and delivered as an aggregate. Data only gets fixed when the person who can fix it sees a short list of their own records, capped at a length they can clear before a Monday call.
By forecast impact: rule weight multiplied by deal value, with late-stage deals weighted higher. Ranking by record count puts a blank field on a tiny early-stage deal above a stale close date on your biggest one.
Snapshot the score daily and chart the trend, then overlay forecast accuracy for the same periods. A single snapshot tells you the state. Only the trend shows whether a clean-up stuck or happened once before a board meeting.
Yes. The prompts here are written for Claude Code, Codex or Cursor and stage the build, starting from a CSV before connecting the CRM. The judgement calls are your rules and their weights.
Sales and RevOps
Route discount requests by depth and deal size, give approvers the context to decide in minutes, and keep a record of every exception granted. Prompts to build it, and what it takes to run it.
Sales and RevOps
Split accounts into territories, load quota against them, and see the coverage and fairness of a plan before you commit to it. Prompts to build it, and what it takes to run it.
Marketing
Route every lead to a named person in seconds, by rules you can read, with nothing ever landing in a pool nobody owns. Prompts to build it, and what it takes to run it.
Customer Success
Build a health score from signals that actually predict renewal, show the trend rather than the number, and turn a red account into a named action. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.