Every rep researches the same accounts the same way and none of them keep it. Here is the model behind an app that does, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
An account research app is four parts: everything you already hold about the account pulled into one place, a small set of external signals added on top, a written point of view that a person owns rather than a model generates, and a shelf life so nobody quotes research from eighteen months ago. The waste it removes is duplication. Every rep researches the same account the same way, keeps it in a doc nobody finds, and the next person starts again.
Account research
184
Accounts with a brief
31
Needing refresh
62%
Opened by someone else
41%
Of pipeline has no brief
Halden Foods
Brief by R. Iyer · signed 14 August · point of view 20 days old
External signals, with sources
You run sales, revenue operations or a field team where everybody researches accounts and nobody keeps it. What you want is for the second person looking at an account to start from where the first one finished.
What happens the second time somebody looks at an account.
Contracts, pipeline, tickets, usage, contacts and past conversations, with the age of each shown so a two-year-old ticket does not read like last week's.
Funding, headcount trend, technology, leadership changes. Chosen because they change the approach, not because they were findable.
And anything unverified is marked as such, because somebody will repeat it in a meeting.
Drafted from the context, edited and owned by a named human, because nobody defends a paragraph a model wrote.
Contract data refreshes continuously, funding ages in months, and the point of view ages fastest of all.
If only the author ever reads it, the app organised the duplication rather than removing it.
An account research app is not a summariser pointed at the internet. It is four parts, and the first one is the part people forget they already have.
Contract history, open pipeline, support tickets, product usage, past conversations, who you have met. Most of what a rep assembles by hand is already in systems they have access to.
Funding, headcount trend, technology in use, recent announcements, leadership changes. A small number of things that actually change how you sell, not everything findable.
A short written take, owned by a named person: why this account, what they are likely trying to do, who matters, and what would make us lose. Assembled with help, judged by a human.
An expiry on the research and a visible age on every brief, because a confident summary built on a two-year-old org chart is worse than no summary.
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.
Most of the manual research is this, and it is the easiest part to automate.
In this Helix project, build me an account research app.
Start with what we already know, because that is most of what a rep
assembles by hand.
For a given account, pull together: contract history and current value,
open and past pipeline, support tickets and any escalations, product
usage if we have it, every contact we hold with their role, and the
history of conversations we have had.
Put it on one page with the age of each piece shown. A support ticket
from last week and one from two years ago should not look the same.
That page alone removes most of the duplication, because the reason
everybody researches the same account is that nobody can see what the
last person found.
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.A few, chosen deliberately.
Now add external context, and be selective. The goal is not everything
findable, it is the handful of facts that change the approach.
Funding and ownership. Headcount trend, and by function if you can get
it, because a company hiring twenty support agents is telling you
something. Technologies in use where they are relevant to us. Recent
announcements, leadership changes and anything in the last quarter that
suggests a priority.
Cite the source and date of every external claim on the record. A brief
that cannot say where a number came from cannot be used in front of a
customer, and somebody will eventually repeat it in a meeting.
Where a signal cannot be verified, mark it as unverified rather than
leaving it looking like the rest. The difference between a confirmed
funding round and a rumour matters when a rep quotes it.The part not to automate.
Add a written point of view, and make it clear it belongs to a person.
Four short fields: why this account is worth time, what we think they are
trying to do, who matters and why, and what would make us lose.
Let the app draft each from the assembled context, and require a named
person to edit and sign it before it counts as research rather than a
draft. Show the author and the date on the brief.
A generated summary is useful input and a poor substitute for a
judgement. The value of this field is that somebody will defend it in a
pipeline review, and nobody defends a paragraph a model wrote.
Keep previous versions, so when the take on an account changes it is
visible as a change rather than a quiet overwrite.Worth knowing. This is the field that separates a research app from a summariser. Requiring a human signature is the whole mechanism.
Because stale research is worse than none.
Last, make research expire.
Set a shelf life per section rather than for the whole brief. Contract
and pipeline data refresh continuously. Headcount and funding age in
months. A point of view ages fastest of all, because it was written
against a situation.
Show the age of every section, and mark the whole brief as needing
refresh once the point of view passes a threshold I set. Do not hide the
old version, just stop presenting it as current.
Then the reporting worth having: which accounts have research and which
do not, ranked by pipeline value, so the gap is visible. How often
research gets refreshed rather than rewritten from scratch, which tells
you whether people are finding it. And how often a brief is opened by
somebody other than its author, which is the only real measure of whether
this removed the duplication it was built for.Worth knowing. The last metric is the honest one. If nobody but the author ever opens a brief, the app has organised the waste rather than removed it.
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>. Read contracts, pipeline, contacts and the history of what
has been sold to this account.
<Zendesk>. Read open tickets and escalations, which change how a
conversation should open.
<Amplitude>. Read product usage, so a brief can say whether they are
actually using what they bought.
<Gong>. Read what has been discussed on past calls, which is the context a
rep most often lacks.
<Okta>. Verify who is signing in and read their group, which is what the
app checks before showing a frank internal assessment.
<Snowflake>. Read usage and revenue history at depth, which the source
systems will not give you cheaply.
<Slack>. Tell the owner when a brief is approaching its expiry rather than
letting it go quietly stale.
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. Research briefs carry contract values and candid internal views, so set Access Control before sharing.
Almost all of this is reading systems the rep already has access to, which is precisely why doing it by hand is such a waste.
Salesforce
Read contracts, pipeline, contacts and the history of what has been sold to this account.
Zendesk
Read open tickets and escalations, which change how a conversation should open.
Amplitude
Read product usage, so a brief can say whether they are actually using what they bought.
Gong
Read what has been discussed on past calls, which is the context a rep most often lacks.
Okta
Verify who is signing in and read their group, which is what the app checks before showing a frank internal assessment.
Snowflake
Read usage and revenue history at depth, which the source systems will not give you cheaply.
Slack
Tell the owner when a brief is approaching its expiry rather than letting it go quietly stale.
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 app. It reads across your commercial systems and holds candid internal views of customers, so it needs to be run properly.
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
A research brief carries contract values and a frank internal assessment of an account. SSO means people sign in with their existing account and access is scoped to the field team.
App Security
Pulling contracts, pipeline, tickets and usage from four systems needs real access to each. Granting it to the app rather than pasting keys into it means credentials 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 assembles what you already hold about an account, adds a small set of external signals, and keeps a written point of view owned by a named person, so the next person to look at that account starts from where the last one finished.
Internal data. Contract history, pipeline, support tickets, product usage and past conversations. Most of what a rep assembles by hand already sits in systems they have access to, and duplicating that work is the waste the app removes.
Drafted, then owned. A generated summary is useful input and a poor substitute for a judgement somebody will defend in a pipeline review. Requiring a named person to sign it is what makes it research rather than output.
Because a confident brief built on an org chart from two reorganisations ago is worse than no brief. Set the shelf life per section: contract data refreshes continuously, funding ages in months, and a point of view ages fastest because it was written against a situation.
Measure how often a brief is opened by somebody other than its author. If that number is low, the app has organised the duplication rather than removed it, which is the failure mode worth watching for.
Yes. The prompts here are written for Claude Code, Codex or Cursor and stage the build. The judgement calls are which external signals actually change how you sell, and resisting the urge to collect everything findable.
Sales and RevOps
Contacts, organisations, interactions and a small pipeline, for the teams whose relationships do not belong in the sales CRM. Prompts to build it, and what it takes to run it.
Sales and RevOps
Find the opportunities distorting your forecast, name who owns each fix, and make hygiene a short weekly list rather than a quarterly clean-up. 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.