Quiet by default
The logo helper should never open on its own, flash, cover important buttons, or keep repeating a greeting while someone is trying to read.
Guided support desk
A faster way to find the right tool without making people dig.
The bottom-right site guide is the site’s front desk: a quick way to describe the pressure point, tap a topic, and reach the closest existing tool without giving private records or waiting for live support.
Concierge guide
Start hereReview Guided Advocate blueprintWhat the guide does now and what belongs later.
This page is about routing behavior, not medical answers. The active guide sends visitors to existing tools; later contact or Supporter guided layers should add reviewed drafting only after privacy, storage, and safety rules are built.
Best first route
Use the current router
Visitors who are not sure where to start can use the fast-path cards or the bottom-right site guide without entering private details.
Why the widget matters
A visitor may arrive from a social post, support group, pharmacy problem, rushed appointment, harmful chart note, or chronic illness search. The guide should reduce the first decision to one practical question: which pressure point needs attention right now?
What the first version should do
The current version should stay simple: identify the issue, open the best page or tool, and avoid collecting private messages. Contact delivery belongs in a later reviewed flow with confirmation screens and privacy controls.
What it should not do
The widget should not diagnose, prescribe, offer legal conclusions, promise a reply, rank providers, guarantee pain medication access, handle emergencies, or pretend to be a live human when it is automated.
- No emergency handling or crisis monitoring.
- No medical, legal, pharmacy, or insurance decisions.
- No public provider claims without moderation and review.
- No hidden email sending before the user reviews the message.
Where Guided Advocate can help later
Guided Advocate can become valuable after the route map is stable. It can ask short questions, identify the closest site route, help draft a calm message, summarize user-selected facts, and explain which page or tool fits the situation.
Why email delivery waits
Real email delivery needs a verified sending setup, spam protection, rate limits, confirmation templates, privacy language, error handling, and a clear contact identity before it should go live.
Guided helper architecture
The floating logo helper should feel like a calm front desk, not a pop-up gimmick.
This page defines the guide itself: how it opens, how it routes, what it should ask, and what it must avoid. The broader platform framework belongs on the homepage; this page stays focused on the front-desk experience.
Bottom-right logo helper
Quiet until tapped.
The current guide opens only when tapped, accepts a short issue or topic chip, and routes users to existing help without collecting private messages.
TapType or tap topicReview
Widget behavior standards
The widget has to earn trust quickly. If it repeats itself, blocks content, asks for too much, or pretends to be smarter than it is, hurting users will close it and lose confidence in the site.
- Tap-to-open only. No automatic pop-ups, no shaking button, no repeated greeting on every page.
- Small bottom-right logo presence that respects mobile thumb space and does not cover forms, buttons, or legal text.
- Plain language first. No fake empathy loops, no stiff overexplaining, no pretending to be a live person.
- One question at a time for sick, tired, or overwhelmed users who cannot handle a long form.
- Clear safety boundary before sensitive topics: no emergencies, no diagnosis, no legal advice, no prescription instructions.
- Review-before-send for every message that may be emailed to contact@paincarerights.org.
I do not know where to start
Route the visitor by pressure point: appointment, pharmacy, records, complaint, story, support, source lead, or local care-access concern.
I want to request a story, quote, or interview
Collect the outlet, topic, deadline, contact details, and public-facing summary before any message is sent.
I want to thank or encourage the mission
Let patients send encouragement without making them share diagnoses, records, medications, or identifying medical details.
I am an advocate, attorney, clinician, journalist, or group leader
Collect the role, organization if any, public resource link, collaboration idea, and safest way to follow up.
I found a source, wording, or routing issue
Ask for the page, concern, public source if available, and the correction requested without inviting private records.
I know a useful community or resource
Gather the group name, platform, topic, location if relevant, public link, and safety notes before review.
Boundaries before advanced help is activated
The Supporter guided layer should be added only after the instructions, logging rules, error handling, privacy language, source limits, and fallback routes are designed. The current release should remain a guided router and drafting bridge, not a medical or legal decision-maker.
Email contact flow
The contact funnel should not send anything until the user sees the final message. A later delivery phase can send the reviewed message to contact@paincarerights.org and return a clean confirmation.
The confirmation email should be polished, but careful.
An eventual HTML reply can look professional and reassuring without promising review, legal help, medical advice, media coverage, or a specific response time.
- Use Pain Care Rights branding and contact@paincarerights.org as the public contact identity.
- Confirm the message category and receipt without promising a reply time, outcome, legal review, or medical help.
- Remind the sender not to email private records unless a secure process specifically requests them later.
- Use readable HTML with plain text fallback, large tap targets, and accessible contrast.
Guided Advocate safety readiness
The advanced helper should launch in layers, not as an open-ended help box.
The safest Supporter version starts with narrow guided drafting and routing. Official contacts, saved packets, outside lookup, email delivery, and account storage should arrive only after their source, privacy, and cost safeguards are ready.
Stage 1: route quality
The free site guide should continue routing visitors to existing pages and tools without collecting private records or pretending to provide live assistance.
Stage 2: supporter drafting
The first Supporter version should focus on reviewable drafts, clearer packets, and issue sorting. It should not send emails, save sensitive facts, or claim official-contact lookup until those systems are built.
Stage 3: reviewed official guidance
A curated official-source guide can later support state, federal, board, agency, insurance, pharmacy, representative, and patient-rights routing with review dates and source links.
Stage 4: saved work only by consent
Saved Advocacy Packets should wait for accounts, storage rules, export, delete, retention, access control, and plain privacy language.
Official-source guidance the future helper needs
Source-guided routing should be built from reviewed official guidance, not guesses. Each item needs a source link, review date, route category, and plain limit notes before it helps guide a user.
- State medical board guidance with source URL, complaint page, last-reviewed date, and maintenance notes.
- State pharmacy board guidance with official complaint route, contact page, and last-reviewed date.
- State insurance department guidance with plan-type warnings and official consumer complaint links.
- Federal agency guidance for HHS OCR, Medicare, Medicaid, disability, privacy, civil-rights, and public-benefit routes where applicable.
- Representative-routing guidance that points users to official lookup pages instead of storing political guesses.
- Patient-rights and medical-record correction guidance with source links, jurisdiction notes, and plain-language limits.
Hard safety rules
These rules protect the user, the site, and the mission. The advanced layer should help organize and draft, not cross into medical care, legal representation, or unsafe complaint behavior.
- No diagnosis, prescribing, medication instructions, emergency handling, legal conclusions, or guaranteed outcomes.
- No invented laws, deadlines, agencies, official contacts, provider claims, or complaint results.
- No message sending until the user sees the exact text, recipient, privacy warning, and confirmation screen.
- No saved sensitive work until consent, account controls, deletion, export, and retention rules are built.
- No provider ratings, blacklists, or public accusations without a separate moderation and defamation-risk framework.
- No private medical facts in ordinary logs, analytics, payment metadata, or support receipts.
Cost safeguards that protect a low price
A low supporter price works only if the costly work is bounded. The platform should spend advanced processing only where it adds clear value.
Cost safeguard
Route simple questions away from costly guided processing
If a visitor only needs a page or tool, the free Start Here flow should answer that without using costly guided support.
Cost safeguard
Use reviewed official guidance before outside lookup
The future helper should rely on approved official guidance first. Outside lookup should be rare, limited, and clearly marked for verification.
Cost safeguard
Limit long sessions
Fair-use limits, monthly resets, output size caps, and abuse controls protect the platform from being drained by a small number of heavy users.
Cost safeguard
Separate heavy features
Long document review, saved packets, file uploads, email delivery, and official-contact help should not be bundled into the first Supporter release without their own cost and safety checks.
User controls before each sensitive action
Trust improves when users know what is happening before money moves, before a draft is created, and before anything is stored.
The first Supporter version should be narrow enough to trust.
Start with better drafting and route sorting. Add saved packets, official-contact lookup, and message delivery only after the separate security gates are ready.
Guided Advocate source rules
Guided Advocate should earn trust by being narrow, source-aware, and reviewable.
The value is not unlimited conversation. The value is turning messy facts into clearer routes, stronger drafts, and better-organized packets while keeping the user in control.
Ask for the lane before drafting
The helper should first identify whether the user is dealing with a clinic delay, record problem, pharmacy barrier, insurance issue, board complaint, policy letter, or support request.
Use reviewed official sources first
If source-guided routing is available, it should use approved official sources before suggesting an office, form, route, or public contact page.
Show the limit of the route
A route can tell the user where an issue may fit. It should not promise the office will act, accept the complaint, change care, or agree with the patient.
Draft from user-approved facts
The helper should draft from the user’s own dates, impact, missing answer, and requested review. It should not add facts the user did not provide.
Keep private details out by default
The first draft should avoid full addresses, account numbers, prescription numbers, record images, unrelated diagnoses, and unnecessary family details.
Require review before action
Anything copied, saved, printed, emailed, or shared should be shown to the user first with a plain reminder to remove unnecessary private details.
Boundaries that protect users and the platform
A useful helper has limits. These boundaries keep the tool from sounding like a doctor, lawyer, emergency service, agency, or guaranteed complaint engine.
- It may help organize facts, classify the general route, prepare wording, and explain what to verify.
- It must not diagnose, prescribe, recommend controlled medication, or tell a patient what treatment they should receive.
- It must not give legal conclusions, threaten malpractice claims, invent citations, or promise that a board or agency will act.
- It must not create public accusations, provider blacklists, or rating-style statements from unreviewed user reports.
- It must not ask for unnecessary private identifiers or store sensitive material without a separate consent screen.
- It must redirect urgent medical danger, self-harm, threats, or emergency situations away from ordinary site tools.
Supporter value rules
People should understand exactly why Supporter Tools cost money. The Supporter version should save time, improve clarity, and help with harder drafting without weakening the free mission.
Draft quality checks before a user relies on it
Supporter Tools should feel worth paying for because the output is cleaner, calmer, and more usable than a blank text box or generic template.
Free help should bring people back. Supporter Tools should prove their value.
Keep the public tools useful, then offer deeper guided drafting and source-aware route guidance when a user needs more than a basic packet.
Guided Advocate safety build plan
The advanced system should be built from safeguards, not guesses.
Guided Advocate should follow a disciplined launch order: reviewed public guidance, clean payment boundaries, narrow drafting safeguards, privacy-first storage rules, and cost limits before stronger features are activated.
Gate 1: reviewed official guidance first
Reviewed official sources and route notes must be ready before stronger drafting points a user toward a board, agency, insurer, pharmacy, records office, or representative lane.
Gate 2: account and payment boundaries
Supporter access should be separated from health-related drafts. Payment records should never become a place where symptoms, prescriptions, diagnoses, or private stories are stored.
Gate 3: drafting safeguards
Advanced drafting should require an issue lane, recipient type, clear limits, review warnings, and reasonable output caps before it creates a stronger draft.
Gate 4: saved work by consent only
Saved packets should wait until users have clear controls for what is stored, how long it remains, how to export it, and how to delete it.
Official-source checklist before route guidance
Route guidance should be grounded in reviewed public information. This checklist keeps official guidance from turning into stale links, guesses, or overconfident instructions.
- jurisdiction, office type, route lane, and issue category
- official source URL, page owner, last-reviewed date, and reviewer note
- what the office can usually review and what belongs somewhere else
- required user warnings, route limits, and no-outcome-promise language
- maintenance status such as draft, approved, stale, retired, or needs review
- correction channel so outdated links or wrong categories can be reported
Service boundaries for the first release
A safe first release should feel useful because it is focused. It should help with route clarity and better drafts while refusing work that belongs to clinicians, attorneys, agencies, or live support staff.
Boundary
Free routing stays cheap
Basic site navigation should continue using browser-first routing and existing pages. A visitor should not trigger costly processing just to find the records tool, pharmacy packet, complaint chooser, or care-access timeline.
Boundary
Drafting has a narrow job
The first supporter release should help turn user-approved facts into clearer messages and packets. It should not diagnose, prescribe, investigate, threaten, or promise that an office will act.
Boundary
Official-contact help waits for verified public guidance
The helper should never invent an email, phone number, agency, deadline, form, law, board rule, representative, or complaint route. If reviewed public guidance is missing, the tool should say the route is not ready.
Boundary
Delivery comes after review screens
The safest first release ends with copy and print. Email delivery should wait for recipient confirmation, spam controls, delivery logs that avoid private facts, failure handling, and a final user approval screen.
Privacy safeguards that must exist before storage
Patients should not have to trade sensitive health details for help. Copy and print should remain the safe default, and saved work should come later as an opt-in feature with real controls.
- Ordinary logs, analytics, payment metadata, and support receipts should stay free of private medical facts.
- No sensitive draft storage by default; copy and print should remain the safest first-release output.
- No saved packet feature until account access, retention, export, deletion, and consent language exist.
- No public story, provider report, or complaint content should be published without a separate moderation workflow.
- No message should be sent to a provider, board, agency, insurer, pharmacy, or representative without exact user review and confirmation.
- No official route suggestion should be user-facing unless it has source ownership, review date, route limits, and maintenance status.
Cost controls that protect fair supporter pricing
A low annual supporter price only works if expensive processing is bounded. The system should spend more effort only where deeper drafting or route sorting adds real value.
Cost control
Tier the work by difficulty
Simple route questions should stay on the free side. Stronger packet drafting should use bounded prompts, short first answers, and longer outputs only when the user chooses a complex route.
Cost control
Limit unlimited-use risk
Fair-use limits, monthly resets, output length caps, abuse checks, and graceful refusal rules protect the low supporter price from being drained by heavy automated use.
Cost control
Avoid expensive launch extras
File uploads, document review, outside lookup, email delivery, saved packets, and large attachments should stay out of the first release unless priced and reviewed separately.
Cost control
Use reviewed official guidance before outside searching
A curated official-source guide is more predictable than live searching. Outside lookup should be rare, bounded, visibly labeled, and never used to make claims without user review.
Recommended build order after approval
The build should advance in controlled releases. Each release should prove trust, privacy, cost, and route quality before the next feature is allowed to depend on it.
Guided Advocate should not become powerful before it becomes trustworthy.
Guided Advocate should begin as a bounded drafting and route-clarity tool. Saved packets, delivery, official-contact help, public stories, and directories should each wait for their own privacy and review gate.
Guided Advocate workflow
The first Supporter version needs to be narrow, useful, and safe enough to trust.
The launch version does not try to do everything. It helps users turn difficult facts into clearer drafts and route summaries while keeping storage, delivery, public posting, and official-contact lookup behind separate gates.
1. Choose the issue lane
The user starts with the problem type: provider message, chart note, medication barrier, pharmacy issue, insurer delay, board complaint, agency route, or legislator letter.
2. Collect only needed facts
The form collects only the minimum facts needed to draft responsibly: dates, recipient, barrier, functional impact, prior messages, and the written answer requested.
3. Check source readiness
Route-specific help uses reviewed official sources when available. If the official guidance is not ready, the tool says so instead of guessing.
4. Build the draft
The first Supporter release focuses on cleaner drafts and packet structure, not message delivery, diagnosis, legal conclusions, or public posting.
5. Require user review
The user sees the draft, privacy warnings, route limits, and copy/print choices before relying on it. Nothing is sent automatically.
6. Save only by consent later
Saved work waits until accounts, deletion, export, retention, and separation from payment records are ready.
Best first Supporter release
Start with the work that creates obvious value and lower risk: better drafts, better structure, and better route sorting.
- advanced provider message draft
- medical-record correction or disagreement packet
- medication-access and pharmacy barrier packet
- care-delay or referral follow-up packet
- board, agency, insurer, or legislator letter draft
- route-sorting summary for complicated issues
Features that wait
These features can be valuable, but they carry higher privacy, accuracy, moderation, or support risk and stay out of the first release.
- saved advocacy packets
- reviewed official-contact helper
- state and federal official-source lookup
- caregiver-friendly account access rules
- message delivery only after separate approval
- public story submission only after moderation tools exist
Supporter value needs to feel professional before it becomes functional.
The product needs clear workflow, clear limits, and clear quality standards before Supporter access, accounts, saved work, official-source lookup, or message delivery are activated.
- adult wording, no hype, no fake urgency, no cartoon reward language
- short first answer before longer drafts to control cost and avoid overwhelming users
- clear source status when official routing is used
- plain privacy warning before sensitive facts are entered
- fair-use limits explained before payment
- no storage unless the user deliberately chooses saved work later
Official contact helper standards
A useful contact helper needs reviewed official guidance, not guesses.
Future Supporter Tools may help users identify the type of office, board, agency, insurer, records route, or policy contact that fits their issue. That cannot launch responsibly until each listing has a source, a lane, a review date, and clear limits.
Medical and licensing routes
State medical boards, nursing boards, pharmacy boards, facility licensing offices, and patient relations routes need clear limits on what they can review.
Coverage and access routes
Insurance departments, Medicaid offices, plan grievance routes, prior authorization resources, and appeal pathways need jurisdiction labels and source dates.
Records and privacy routes
Record amendment, release delay, privacy complaint, access denial, and statement-of-disagreement paths need careful separation because they do different things.
Policy and representative routes
Legislator, agency, and public-policy routes should focus on broader harm, access barriers, and patient dignity instead of asking lawmakers to manage a private medical case.
Each contact listing should include
A contact listing is not just a link. It needs enough context to prevent the tool from sending a user to the wrong place with the wrong request.
- official office or route name
- jurisdiction, state, federal, facility, insurer, or policy lane
- official source URL and plain source title
- what the route can review and what it cannot review
- contact method type, such as form, phone, mailing address, or public portal
- last-reviewed date and reviewer status
- warning notes for deadlines, privacy, eligibility, or complaint limits
- correction channel if a user reports the listing is wrong
No-guess rules
These rules protect users from false confidence and protect the site from looking careless.
- Do not invent a phone number, email address, form link, office name, or deadline.
- Do not imply a board, agency, insurer, or lawmaker will fix the issue.
- Do not list private staff contacts unless they are official public contacts.
- Do not show provider accusations, ratings, or user allegations inside contact listings.
- Do not use a contact listing for stronger route guidance until it has been reviewed.
Saved packet readiness
Saved work can be a Supporter feature only after users control it.
Saved Advocacy Packets are a strong Supporter Tools feature because they solve a real problem: sick users often cannot finish everything in one sitting. The feature should wait until account, privacy, delete, export, and retention rules are ready.
Leave with something usable today.
Free users should still be able to build a basic letter, complaint summary, medication-access packet, record-correction request, story draft, or visit-prep summary and copy or print it without payment.
Come back to organized work later.
Saved Advocacy Packets can become a supporter feature because storage, account security, deletion controls, and packet organization create real operating and maintenance costs.
Reuse facts without starting over.
A mature version can let users turn one private timeline into different drafts for a provider, board, agency, insurer, pharmacy, legislator, or records office without retyping every detail.
Packet types worth saving later
Storage should focus on high-value work that people may need to revisit, refine, print, or adapt for a different recipient.
- provider message packet
- medical-record correction packet
- statement-of-disagreement packet
- pharmacy or medication-access packet
- insurance or prior-authorization follow-up packet
- hospital grievance packet
- board or agency complaint packet
- legislator or policy letter packet
- private story packet
- care-access timeline packet
Rules before a save button appears
The save feature should be restrained, plain, and reviewable. A patient should never wonder whether private details were stored by accident.
Why saved packets create real Supporter value
The feature is not a gimmick. It helps people with fatigue, pain flares, brain fog, caregiving help, complicated timelines, and multiple complaint lanes keep their work usable.
Save later should never mean send now.
Saved packets belong behind clear account controls. Email delivery, public posting, and official submission should remain separate gates with their own review screens.
Define the Guided Advocate lane before it goes live.
Review the router blueprint before adding Supporter guided help, email delivery, saved messages, or expanded sitewide contact behavior.