Make the section understandable
The client should understand this section in one pass without needing analytics training.
Portal experience
Launch Readiness View Portal Experience Guide
Launch Readiness View portal experience guide for turning internal ZartsAlgo records into a clear client-facing section.
Portal model
Turn internal work into a client-safe view.
The portal should reduce confusion, not create another dashboard to decode. Every section needs owner, source, freshness, privacy, and next action.
Assign an internal owner
Client success owner owns accuracy, freshness, and the next portal update.
Label the source before showing data
Every portal claim should have a source name, date range, baseline, current value, or status note.
Protect raw provider data
The client sees summaries and proof, while raw payloads, credentials, transcripts, and private customer details stay internal.
End with a next move
A portal update is useful only when it explains the next action, waiting item, or decision.
Review on a schedule
Keep this section fresh with a weekly, monthly, launch, or review cadence depending on client risk.
Data sources
Tables and records involved.
These are the first records to review when this portal section is connected to MySQL-backed admin data.
portal_usersportal_permissionscore_clientsmetric_snapshotsreport_reportsreport_metricsevent_admin_actions
Checklist
Publish only when the story is clear.
- Confirm that the client should see this data at all.
- Choose a simple section label and avoid provider jargon.
- Verify source, date range, status, and owner before publishing.
- Separate client-facing summary from raw admin notes.
- Include baseline and current value when the section describes improvement.
- Explain what changed since the last update in one short paragraph.
- Add the next action, waiting item, or decision needed.
- Remove or redact private lead details, payloads, tokens, notes, and transcripts.
- Check the mobile view before calling the portal update ready.
- Archive stale notes instead of deleting reporting history.
Signals
What this section can show.
These signals should feed short client-facing proof, not raw provider data.
section freshness
Use this signal only when it can be explained with source, period, owner, and next action.
client-safe status
Use this signal only when it can be explained with source, period, owner, and next action.
next action clarity
Use this signal only when it can be explained with source, period, owner, and next action.
source labels
Use this signal only when it can be explained with source, period, owner, and next action.
Timeline
Portal publishing rhythm.
Prepare checkpoint
Decide what the client should see and which admin records feed the section.
Verify checkpoint
Check source labels, values, status, owner, privacy, and date range.
Publish checkpoint
Write the portal-safe summary with one next action or decision.
Review checkpoint
Compare the section during the next report cycle and mark stale items.
Improve checkpoint
Use questions from the client to simplify labels and proof language.
Avoid
Portal mistakes that create confusion.
- Do not turn the portal into a raw analytics dashboard.
- Do not show metric movement without source and date range.
- Do not expose private provider payloads or customer details.
- Do not publish a green status when there is a waiting approval or access blocker.
- Do not mix paid marketplace leads, organic leads, calls, and referrals without labels.
- Do not let old portal updates imply current progress.
- Do not rely on screenshots when a structured metric or status record exists.
- Do not make the client guess what ZartsAlgo needs next.