Operator Handbook¶
Your daily guide to running AEO Bunny. This document tells you exactly what to do each morning, how to handle every type of approval, and what to do when things go wrong. If you have not read the System Overview yet, start there first -- it explains what each part of the system does. This document assumes you already know the basics and focuses on the how.
1. How to Access Dashboards¶
You will use three tools regularly. Here is how to get to each one.
Admin Portal (Daily Use)¶
- Open your browser and go to
https://portal.aireadyplumber.com/admin - Log in with your admin email and password (these were provided when your account was created)
- You will land on the Overview page, which shows a summary of all active projects, pending approvals, and failed pipelines
This is where you will spend most of your time. Everything described in this handbook happens here.
Railway Logs (When Reporting Problems)¶
Railway is the hosting platform where the backend server runs. You do not need to use it day-to-day, but if something goes wrong and you need to report it to the founder, here is how to pull up logs:
- Go to
https://railway.app/dashboard - Log in with the shared team credentials (stored in the team password manager)
- Click the AEO Bunny project
- Click the backend service
- Click the "Logs" tab on the right side
- Copy or screenshot the recent error messages and send them to the founder
You do not need to understand the logs. Just capture them so the founder can diagnose the problem.
Supabase (Founders Only)¶
Supabase is the database. Only the founder should access it directly, and only for emergency situations like manually creating a customer account when the normal onboarding flow breaks.
- URL:
https://supabase.com/dashboard - Access: restricted to founder accounts
If you think a situation requires direct database access, escalate to the founder rather than attempting it yourself.
2. Daily Checklist¶
Run through this list every morning. It takes about five minutes on a quiet day.
- [ ] Check for paused pipelines. Open the admin portal. Look at the Overview page. Any project showing "Paused" status needs your attention -- it is waiting for you to approve or reject something.
- [ ] Check the notification bell. Click the bell icon in the top-right corner of the admin portal. Unread notifications appear with a red badge. Each notification tells you exactly what happened and links to the relevant project.
- [ ] Check GHL for overnight alerts. Open GoHighLevel and review any notifications that arrived since you last checked. GHL receives automated updates at every major pipeline milestone. Look for anything flagged as urgent, especially visibility score drops or pipeline failures.
- [ ] Check for failed pipelines. On the admin portal Overview page, look for projects with a red "Failed" status. These need to be retried or escalated (see Section 6 below).
- [ ] Check for pending revision requests. Go to the Approvals page (sidebar link). Filter by "Revision" type. Any revision request listed as "Pending Approval" needs your review (see Section 4 below). (Note: When calling the API directly, use the lowercase filter value
revision, not capitalized.)
If everything is clear, you are done. If there are items needing attention, work through them using the procedures described in the sections below.
3. Quality Gate Handling¶
Quality gates are the core of your job. When the pipeline pauses at a gate, it is waiting for a human to check the work before it continues. Here is every gate you will encounter and exactly what to look for.
Phase A Gates (Operator Only)¶
These two gates happen once per project, right at the beginning. Only operators review these -- the customer never sees them.
Gate: BI Review (gate_bi_review)
When you see it: After the AI finishes researching the customer's business, industry, and local market.
What to check: - Does the research match what the customer told us in their intake form? (Business name, address, services, service area) - Are the identified competitors real businesses in that area? - Do the "questions people are asking" sound like real search queries for that industry and location? - Is the service area coverage correct? (Not too broad, not too narrow)
What good looks like: Specific, accurate local information. Real competitor names. Search queries that make sense for the industry. If you see generic or obviously wrong data (wrong city, wrong industry), reject it.
Gate: Matrix Review (gate_matrix_review)
When you see it: After the AI builds the 50-article content plan.
What to check: - Do the 50 article topics make sense for this business? - Are the clusters (topic groups) logical? A plumber should have clusters like "emergency services," "bathroom remodeling," and "water heater installation" -- not "pet care" or "accounting." - Are there duplicate or near-duplicate topics? - Is there a good mix of content types? (Service pages, how-to guides, FAQ pages, location pages) - Does the plan cover the customer's main services?
What good looks like: Well-organized topics covering the customer's core services, spread across their service area, with no duplicates or irrelevant entries.
Batch Gates (Batch 1: Operator, Batches 2-5: Customer)¶
These gates happen for every batch. For batch 1, you review first to set the quality bar. After you approve batch 1, the pipeline re-pauses so the customer can also review. For batches 2 through 5, the customer reviews directly without you.
Gate: Article Review (gate_batch_article_review)
When you see it (batch 1 only): After 10 articles have been written.
What to check: - Content quality: Is the writing clear, professional, and free of obvious errors? - Accuracy: Are factual claims reasonable? (We cannot verify everything, but catch obvious mistakes like wrong area codes or impossible service claims) - Voice and tone: Does the writing sound appropriate for the business type? A law firm should sound different from a pizza restaurant. - No placeholder text: Search for phrases like "Lorem ipsum," "[INSERT]," or "TBD" - Completeness: Each article should have a title, full body content, and meta description
Gate: HTML Review (gate_batch_html_review)
When you see it (batch 1 only): After the articles have been assembled into HTML pages with images and schema markup.
What to check: - Does the page layout render correctly? (Use the Preview tab) - Do images load properly? - Is the business name and contact information correct on the page? - Do internal links work? (They should link to other pages in the content set) - Is schema markup present? (You can check this in the Content tab -- look for the structured data section)
Customer-Facing Gates (Operator Cannot Approve)¶
Gate: Photo Upload (gate_photo_upload)
When you see it: After the article review gate is approved for batch 1 (both operator and customer reviews complete), before HTML assembly begins. The pipeline pauses waiting for the customer to supply photos.
What it means: The customer must upload at least 100 business photos via /portal/photos before the pipeline can assemble HTML pages for batch 1. You will see a photos_gate_waiting notification in the bell.
What you can do: You cannot approve this gate -- only the customer can satisfy it by uploading photos. Your options are:
- Check the admin photo status endpoint (GET /api/v1/admin/projects/{location_id}/photo-status) to see how many photos have been uploaded so far
- Send a manual GHL message to the customer reminding them to upload their photos and linking them to [portal URL]/portal/photos
- Escalate to the founder if the customer is unresponsive for more than 3-5 business days
Photo quality badges: After each photo is uploaded, the Image Intel Agent scores it and assigns a quality badge: good, fair, or poor. All photos count toward the 100-photo minimum regardless of badge. However, poor-quality photos (blurry, dark, unrelated to the business) will not be used in HTML assembly. The admin photo status endpoint shows a breakdown of good/fair/poor counts so you can advise the customer if they have uploaded many poor-quality photos and may need to supplement with better ones.
When it resolves: Automatically, once the customer's photo count reaches 100. The pipeline resumes on its own without any operator action.
How to Approve or Reject¶
To approve: 1. Open the project in the admin portal 2. Review the content using the article queue and content preview panels 3. Click the "Approve" button 4. The pipeline automatically resumes
To reject: 1. Open the project in the admin portal 2. Click the "Reject" button 3. Write specific feedback explaining what needs to change (this is important -- your feedback goes into the customer's Dossier and directly improves the next attempt) 4. The pipeline stays paused. For batch 1 article review rejections, your feedback is saved as special instructions that the Writer AI uses when rewriting.
Decision Flowchart¶
Use this when you are unsure whether to approve or reject:
flowchart TD
Start["Review content at gate"] --> Q1{"Is the content<br/>factually accurate?"}
Q1 -->|No| Reject1["Reject with specific<br/>corrections needed"]
Q1 -->|Yes| Q2{"Does the quality<br/>meet our standard?"}
Q2 -->|No| Reject2["Reject with details on<br/>what needs improvement"]
Q2 -->|Yes| Q3{"Does it match the<br/>customer's preferences<br/>and business?"}
Q3 -->|No| Reject3["Reject with notes on<br/>tone, focus, or scope issues"]
Q3 -->|Yes| Approve["Approve"]
style Approve fill:#d4edda,stroke:#28a745
style Reject1 fill:#f8d7da,stroke:#dc3545
style Reject2 fill:#f8d7da,stroke:#dc3545
style Reject3 fill:#f8d7da,stroke:#dc3545
When in doubt, reject with feedback. It is better to send content through another round than to let subpar work reach the customer. Your feedback directly trains the AI for subsequent batches.
4. Customer Revision Handling¶
After batch 1, customers review their own content. When they want changes, they go through the Edit flow. Here is how that process works and what it means for you.
How the Revision Flow Works¶
- The customer opens an article and clicks "Edit"
- They use the chat interface to describe what they want changed (e.g., "The phone number in paragraph 3 is wrong" or "Make the tone more professional")
- When they are done with that article, they click "Finish Editing" (this sets the article status to "edited")
- After reviewing all 10 articles in the batch (approving some, editing others), the customer clicks "Finish Review"
- The system extracts the customer's feedback using Haiku AI, which updates the Dossier (the running record of the customer's preferences)
- The system calculates the revision cost based on how many articles need changes
What Happens Next Depends on Cost¶
flowchart LR
A["Customer clicks<br/>Finish Review"] --> B["Haiku extracts<br/>dossier updates"]
B --> C{"Estimated cost<br/>below $1.00?"}
C -->|Yes, and<br/>auto-approve on| D["Auto-approved<br/>Revisions execute"]
C -->|No, or<br/>auto-approve off| E["Operator reviews<br/>revision request"]
E --> F{"Approve?"}
F -->|Yes| G["Revisions execute"]
F -->|No| H["Rejected<br/>Articles reset to pending"]
D --> I["Updated articles<br/>ready for review"]
G --> I
style D fill:#d4edda,stroke:#28a745
style H fill:#f8d7da,stroke:#dc3545
Cost calculation: Each article revision costs approximately $0.06 (the REVISION_COST_PER_ARTICLE setting). A batch with 3 edited articles would cost about $0.18. The auto-approve threshold is $1.00 (REVISION_COST_THRESHOLD), so revisions touching up to about 16 articles in a single batch can be auto-approved (if the auto-approve setting is enabled).
Revision cap: Each batch allows a maximum of 3 revision rounds (MAX_REVISION_ROUNDS). After that, the system blocks further revisions and tells the customer to contact support. If you think a customer genuinely needs more rounds, escalate to the founder to manually adjust the cap.
When a Revision Request Lands on Your Desk¶
- Go to the Approvals page and filter by "Revision" type
- Click the revision to see the details: which articles are affected, the estimated cost, and the customer's feedback
- Review each article's revision instructions -- these are the extracted customer requests
- You can optionally add "operator instructions" to override or refine what the customer asked for
To approve: - Click "Approve" (you can add instruction overrides before approving) - The revision executor runs in the background, rewriting the affected articles - The customer gets notified when revised content is ready for review
To reject: - Click "Reject" and provide a reason - The affected articles reset to "pending" status so the customer can review them again - The customer receives a notification that the revision was reviewed - You should follow up manually via GHL to explain why and discuss alternatives
Article Version History¶
Every time an article is revised, the system saves a snapshot of the previous version. Operators and customers can view version history from the article detail page using the version history panel. Each version entry shows who triggered the change (customer revision, operator rejection, initial write) and a timestamp.
This is useful when a customer says "the old version was better" — you can point them to the version history panel so they can compare. You cannot roll back to a previous version from the admin portal; if a customer genuinely needs a rollback, escalate to the founder for a manual database restore of the article body.
When to Push Back on Revisions¶
- Scope creep: The customer is asking for entirely new topics or services not covered in their package. Redirect them to the upsell path.
- Excessive rounds: The customer has used all 3 revision rounds for a batch and keeps requesting changes. Escalate to the founder for a conversation about expectations.
- Unreasonable demands: Requests that would require completely rewriting articles for subjective style preferences after multiple rounds. A polite conversation about what the package includes is appropriate.
5. Pipeline Status Walkthrough¶
The admin dashboard shows the status of every customer project. Here is how to read what you see.
Pipeline Statuses¶
| Status | What It Means | What to Do |
|---|---|---|
| Queued | The pipeline is about to start or resume after an approval. | Nothing -- it will begin running within seconds. |
| Running | The pipeline is actively working (AI is researching, writing, or building pages). | Nothing -- let it run. This can take a few minutes to an hour depending on the step. |
| Paused | The pipeline has stopped at a quality gate and is waiting for human review. | Check which gate it is paused at and follow the procedures in Section 3 or 4. |
| Completed | All 5 batches have been shipped and the project is done. | Nothing -- the project moves to ongoing visibility monitoring. |
| Failed | Something went wrong. The error message gives a clue about what happened. | See Section 6 below. |
Reading the Project Detail Page¶
When you click into a specific project, you see three columns:
- Left column (Article Queue): Lists all articles for the current batch. Each article shows its title, content type, and review status (pending, approved, or edited).
- Center column (Content Preview): Click an article in the left column to view its content here. Switch between the Content tab (markdown text) and Preview tab (rendered HTML page).
- Right column (Pipeline Journey): Shows the batch stepper -- a visual indicator of which batch the project is currently on and what stage within that batch.
Understanding Batch Status¶
Each batch has its own status that tracks where it is in the production cycle:
| Batch Status | Meaning |
|---|---|
| pending | Batch has not started yet. |
| writing | Articles are currently being written by the AI. |
| article_review | Articles are ready for review (at the article review gate). |
| building_html | HTML pages are being assembled. |
| html_review | HTML pages are ready for review (at the HTML review gate). |
| ready_to_ship | Pages are packaged and ready for the customer to download and deploy. |
| shipped | The customer has confirmed deployment for this batch. |
| failed | Batch failed during processing (see failed_at_status for recovery point). |
What "operator_reviewed" Means¶
For batch 1 only, there is a dual-review process. When you see "operator_reviewed" flagged on batch 1, it means you (the operator) have already approved the content, and the pipeline has re-paused for the customer to review the same batch. This is normal -- batch 1 always gets reviewed by both the operator and the customer.
Finding a Specific Customer's Project¶
- Use the search bar at the top of the admin portal
- Search by business name, customer email, city, state, or industry
- Click the result to open the project detail page
6. How to Trigger a Re-Run¶
When a pipeline fails, the dashboard shows a red "Failed" status with an error message. Here is what to do.
Step 1: Read the Error Message¶
Click into the failed project. The error message appears in the pipeline status area. Common errors include:
- AI API timeout: The AI service took too long to respond. This is temporary and usually resolves on retry.
- Database connection error: The database connection was interrupted. Usually resolves on retry.
- Validation error: Something about the data was invalid. May need investigation before retrying.
Step 2: Decide Whether to Retry or Escalate¶
Retry if: - The error mentions a timeout, connection error, or temporary service issue - This is the first or second failure for this project (the system allows up to 3 attempts) - The error message is something you have seen resolve itself before
Escalate to the founder if: - The project has already failed 3 times (maximum retry limit reached) - The error message mentions data validation, missing records, or anything you do not recognize - The same project keeps failing at the same step
Step 3: Retry the Pipeline¶
- Open the failed project in the admin portal
- Click the "Retry" button (if available -- it only appears when retries remain)
- The pipeline re-queues and starts running again from where it failed
The API endpoint for this action is POST /api/v1/projects/{location_id}/retry. The admin portal handles this for you when you click the button. The maximum number of retry attempts is 3 (MAX_PIPELINE_ATTEMPTS).
7. Manual Customer Onboarding¶
Normally, customer onboarding happens automatically: the customer buys through GoHighLevel, the purchase webhook fires, and the system creates their account. But sometimes the webhook fails or the customer has trouble. Here is the manual fallback.
Option A: Ask the Founder to Create the Account in Supabase¶
If the GHL purchase webhook failed entirely (no PendingLead record was created), the founder can manually insert one in the Supabase SQL editor:
INSERT INTO pending_leads (id, name, email, ghl_contact_id, product_tier, status, created_at, updated_at)
VALUES (
gen_random_uuid(),
'Test Customer', -- Customer's full name (NOT NULL, VARCHAR 255)
'customer@example.com', -- Customer's email (lowercase)
'ghl_contact_id_here', -- From the GHL contact record
'$497', -- Or '$997' depending on their purchase
'pending',
now(),
now()
);
After running this SQL, direct the customer to the onboarding form at their portal URL (e.g., https://portal.aireadyplumber.com/onboard). They will create their password and fill in their business details from there.
Option B: Retry the GHL Webhook¶
If the purchase happened in GHL but the webhook failed to reach our system, you can ask the founder to re-send the webhook from the GHL automation settings, or manually trigger the endpoint:
POST /api/v1/webhooks/ghl/purchase
Header: X-GHL-Signature: <Ed25519 signature> (preferred — primary auth method)
Header: X-GHL-Secret: <the webhook secret> (legacy fallback)
Body: {
"name": "Test Customer",
"email": "customer@example.com",
"ghl_contact_id": "...",
"product_tier": "$497",
"phone": ""
}
Note:
nameis required (min 1 character).phoneis optional and defaults to an empty string if omitted.
Option C: Customer Has an Account but Cannot Log In¶
If the customer created their account but forgot their password: 1. Direct them to the "Forgot Password" link on the login page 2. The system sends a password reset link through GHL (not email) 3. The reset link is valid for 15 minutes and is single-use
If the password reset is also not working, escalate to the founder for a manual password reset in Supabase.
8. Customer Communication Guidelines¶
AEO Bunny communicates with customers through GoHighLevel. Most notifications are automatic, but some situations require you to follow up manually.
Automatic Notifications (No Action Needed)¶
The system sends these through GHL at the appropriate pipeline milestones. You do not need to do anything -- they happen on their own:
| Event | What the Customer Receives |
|---|---|
| project_started | Notification that our team has started working on their content (GHL webhook only — no in-app notification) |
| research_in_progress | Update that market research is underway (GHL webhook only — no in-app notification) |
| strategy_complete | Update that the content strategy has been mapped out (GHL webhook only — no in-app notification) |
| photos_upload_needed | Prompt to upload business photos (sent at onboarding) |
| photos_complete | Confirmation that enough photos have been received and page building is resuming |
| batch_article_review_needed | Notification that a batch of articles is ready for their review |
| batch_html_review_needed | Notification that assembled pages are ready for their review |
| batch_ready_to_ship | Notification that a batch is ready to deploy |
| content_approved | Confirmation that their approved content is moving forward |
| revision_started | Notification that their requested revisions are being processed |
| revision_complete | Notification that revised content is ready for review |
| revision_rejected | Notification that a revision request was rejected by the operator |
| revision_failed | Notification that a revision encountered errors during execution |
| batch_visibility_measured | Notification that a per-batch visibility score is available |
| visibility_measured | Notification that their visibility score is available |
| project_complete | Congratulations message when all 50 pages are deployed |
Situations Requiring Manual Follow-Up¶
Revision rejection: When you reject a customer's revision request, the system sends a generic notification. You should follow up through GHL to explain why the revision was rejected and what the customer can do instead. Be specific and empathetic -- the customer put effort into their feedback.
Pipeline failure: If a pipeline fails and you cannot resolve it with a retry, reach out to the customer through GHL to let them know there is a temporary delay. Keep the message simple: "We're experiencing a technical issue with your project and our team is working on it. We'll have it resolved shortly." Do not mention AI, pipelines, or technical details.
Visibility score drop: When the system detects a significant drop in a customer's visibility score, it sends an alert to the operator. This is a potential upsell opportunity. Reach out through GHL to offer a consultation about additional content or optimization services.
Stuck at customer gate: If a project has been paused at a customer review gate for more than 3-5 business days, send a friendly reminder through GHL. The customer may not have seen the notification, or they may need help understanding the review process.
9. First Customer Walkthrough¶
Here is the complete journey for a real customer, step by step. We will follow "Memphis Plumbing Co," who just bought the $497 package.
Day 1: Purchase and Onboarding¶
What happens automatically:
- The customer buys through GoHighLevel. GHL fires a purchase webhook to our system.
- The system creates a PendingLead record for memphisplumbing@email.com with product tier $497.
- GHL sends the customer a welcome message with a link to set up their account.
What you see in the admin portal: Nothing yet -- the customer has not completed onboarding.
What the customer does: - Clicks the onboarding link and arrives at the intake form - Creates a password for their account - Fills in their business details: "Memphis Plumbing Co," located at 1234 Union Ave, Memphis TN. Services: emergency plumbing, drain cleaning, water heater installation, bathroom remodeling. Service area: Memphis metro, Germantown, Collierville, Bartlett.
What happens next: - The system creates their Business, Location, and User records - The pipeline starts automatically - A website readiness check runs in the background on their existing website
Customer's next action -- Photo Upload:
After completing the intake form, the customer should go to /portal/photos and upload at least 100 business photos (exterior shots, team photos, job-site photos, before/after images, etc.). They can do this at any time before batch 1 HTML assembly begins. You do not need to remind them unless the pipeline reaches the photo gate and they still have not uploaded any photos.
Day 1-2: Phase A -- Strategic Foundation¶
Step 1: BI Research
The BI Agent researches the Memphis plumbing market. It identifies local competitors, discovers what questions people are asking ("Who is the best emergency plumber in Memphis?", "How much does drain cleaning cost in Germantown?"), and builds a comprehensive Data Card.
The system also takes a baseline visibility measurement -- checking how visible Memphis Plumbing Co currently is when people ask AI tools about plumbers in Memphis.
What you see: A new project appears on the Overview page. Status: "Running." After a few minutes, it changes to "Paused" at gate_bi_review.
What GHL sends: Operator notification: "BI Research Ready -- Business intelligence research complete for Memphis Plumbing Co."
What you do: Open the project. Review the BI research. Does it correctly identify Memphis plumbing competitors? Are the service areas right? Do the search questions make sense? If yes, click Approve. If something is off, click Reject with specific feedback.
Step 2: Content Strategy
After you approve the BI review, the pipeline resumes. The Strategist Agent creates a 50-article Content Matrix with clusters like "Emergency Plumbing Services" (hub + spokes), "Water Heater Installation Memphis" (hub + spokes), "Drain Cleaning Services" (hub + spokes), and more.
What you see: Status changes to "Running" briefly, then "Paused" at gate_matrix_review.
What GHL sends: Operator notification: "Content Matrix Ready."
What you do: Review the 50-article plan. Do the topics cover Memphis Plumbing Co's services? Are the clusters logical? Any duplicates? Click Approve or Reject with feedback.
After both Phase A gates are approved, the system divides the 50 articles into 5 batches of 10 and enters the batch loop.
Day 2-3: Batch 1 -- Operator Review¶
Step 3: Article Writing
The Writer Agent writes the first 10 articles. Topics come from the Content Matrix. The writing incorporates the Data Card research about Memphis, the plumbing industry, and local details.
What you see: Status: "Running" during writing, then "Paused" at gate_batch_article_review. The batch stepper shows "Batch 1" highlighted, stage "Article Review."
What GHL sends: Operator notification: "Batch 1 Content Ready -- articles ready for review for Memphis Plumbing Co."
What you do: Read through the 10 articles in the content preview panel. Check quality, accuracy, tone, and completeness. This is batch 1, so you are setting the quality bar for the entire project. Click Approve if the content is good. Click Reject with detailed feedback if it needs work -- this feedback gets saved into the Dossier and improves all future batches.
After your approval: The pipeline marks batch 1 as operator_reviewed and re-pauses for the customer to review the same articles.
What GHL sends to the customer: "Content Ready for Review -- Batch 1 articles are ready for your review."
What the customer does: Logs into their portal, reads the articles, approves the ones they like, and uses the Edit flow for any articles they want changed. When done, they click "Finish Review."
Photo Upload Gate (gate_photo_upload)
After both operator and customer article reviews are complete for batch 1, the pipeline pauses at the photo upload gate before HTML assembly can begin. The customer must upload at least 100 business photos via /portal/photos. You will see a photos_gate_waiting notification in your bell.
What you see: Pipeline status: "Paused" at gate_photo_upload. The batch stepper shows batch 1 is still in the article review / pre-assembly stage.
What you do: You cannot approve this gate. If the customer has not uploaded photos within a day or two, send a manual GHL reminder pointing them to their photo upload page. The pipeline auto-resumes once they hit 100 photos -- no action needed from you at that point.
Steps 4-6: Media and Assembly
Once the customer has uploaded enough photos, the pipeline processes images, generates schema markup, and assembles HTML pages. The pipeline then pauses at gate_batch_html_review.
For batch 1, you review the HTML pages first (same dual-review as articles). Check that pages render correctly, images load, and the layout looks right. After your approval, the customer reviews and approves.
Step 7: Deployment
The batch is marked "ready to ship." The customer downloads the ZIP file, uploads the pages to their website, and completes the deployment checklist (confirming pages are uploaded and submitted to Google Search Console).
What you see: Batch 1 status changes to "shipped." The pipeline automatically advances to Batch 2.
What happens in the background: The system measures visibility again to see the impact of the first 10 pages. A readiness check also runs on the customer's updated website.
Day 3-7: Batches 2 Through 5¶
Batches 2 through 5 follow the same pattern as Batch 1 but without operator review. The customer reviews directly. Each batch benefits from the accumulated Dossier -- the customer's preferences and corrections from prior batches make each subsequent batch more aligned with their expectations.
Each batch includes links to all previously deployed pages, so the internal linking structure gets stronger with each delivery.
What you see: The batch stepper advances through batches 2, 3, 4, 5. You only need to intervene if a revision request comes in that exceeds the auto-approve threshold or if the pipeline fails.
What GHL sends: The customer gets notified at each milestone -- content ready for review, pages ready for review, batch ready to deploy.
Day 7-10: Project Complete¶
After all 5 batches are shipped and confirmed, the pipeline marks the project as "Completed."
What GHL sends: - Operator: "Project Complete -- All batches shipped for Memphis Plumbing Co." - Customer: "Project Complete! All your pages are live for Memphis Plumbing Co."
Ongoing: Visibility Monitoring¶
After completion, the system automatically checks how visible Memphis Plumbing Co is in AI search results on a recurring schedule — weekly for the first 30 days after deployment, then monthly. These frequencies are configurable defaults via the SCAN_FREQUENCY_EARLY_DAYS and SCAN_FREQUENCY_STEADY_DAYS env vars (not hardcoded). Scans run in the background without any operator action.
What you see: The Visibility tab on the project detail page shows the score over time, broken down by search engine and content cluster. Customers get an in-app notification and a GHL message (visibility_measured) when each scan completes.
What you do when score drops: Reach out through GHL to offer a consultation. This is a natural upsell opportunity.
To adjust scan frequency or disable scans: Go to Admin → Settings → Visibility. Toggle "Scheduled Scans Enabled" off to disable, or adjust the early/steady-state frequency values. These correspond to the SCAN_ENABLED, SCAN_FREQUENCY_EARLY_DAYS, and SCAN_FREQUENCY_STEADY_DAYS env vars.
10. System Broadcast Banner¶
Super admins can push a system-wide announcement to every customer dashboard at once using the System Broadcast Banner. Use it for scheduled maintenance windows, important product updates, or any message that all active customers should see immediately.
How to Send a Broadcast¶
- Open the admin portal and go to Admin → Settings
- Scroll down to the System Broadcast card
- Type your message in the text field
- Click Send Broadcast
- The amber banner appears at the top of every customer's dashboard within seconds
How to Remove a Broadcast¶
- Go back to Admin → Settings → System Broadcast
- Click Deactivate
- The banner disappears from all customer dashboards
Rules and Behavior¶
- One broadcast at a time. If you send a new broadcast while one is already active, the old one is automatically deactivated. There is no way to have two banners live simultaneously.
- Only super admins can create or deactivate broadcasts. Regular operator accounts do not see this card.
- Customers cannot dismiss it — the banner stays visible until you deactivate it.
When to Use It¶
| Situation | Example Message |
|---|---|
| Scheduled maintenance | "We'll be performing system maintenance on Friday March 28 from 2-4 AM ET. The portal may be briefly unavailable." |
| Feature announcement | "New: Your visibility scores now update weekly automatically. Check your Visibility tab to see the latest." |
| Urgent system issue | "We're aware of a delay affecting content delivery for some projects. Our team is on it — no action needed from you." |
| Holiday / availability notice | "Our team will have reduced availability March 29 – April 1. We'll respond to all requests by April 2." |
Quick Reference: Key Numbers¶
| Setting | Default Value | What It Controls |
|---|---|---|
MAX_REVISION_ROUNDS |
3 | Maximum revision rounds per batch before the system blocks further revisions |
REVISION_COST_THRESHOLD |
$1.00 | Revisions below this cost can be auto-approved |
REVISION_COST_PER_ARTICLE |
$0.06 | Estimated AI cost per article revision |
MAX_PIPELINE_ATTEMPTS |
3 | Maximum times a failed pipeline can be retried |
| Batches per project | 5 | Fixed: every project has 5 batches of 10 articles |
| Articles per batch | 10 | Fixed: 10 articles written, reviewed, and deployed together |
| Password reset expiry | 15 minutes | How long a password reset link stays valid |
When to Escalate to the Founder¶
Not everything can be resolved at the operator level. Escalate when:
- A pipeline has failed 3 times and retries are exhausted
- A customer's onboarding webhook failed and needs manual database intervention
- You see error messages you do not recognize
- A customer is requesting changes that go beyond their purchased package
- A customer has hit the revision cap and is still unhappy
- You suspect a security issue (unusual login attempts, data appearing where it should not)
- Visibility monitoring shows a sudden, unexplained drop across multiple customers
When escalating, include: the customer's business name, their project URL in the admin portal, a description of the problem, and any error messages or screenshots you captured.
Tips for New Operators¶
- Approving is not rubber-stamping. Read the content. Your review is what separates us from automated content mills.
- Rejection feedback is the most valuable thing you write. It directly improves the AI's output for all future batches. Be specific: "The phone number in article 3 is wrong" is much more useful than "Some things are off."
- The customer portal is your reference. Log in as a customer occasionally (use the preview mode) to understand what the customer sees. It helps you explain things when they ask questions.
- When in doubt, ask. It is always better to ask the founder than to approve something you are unsure about, or to guess at a solution for a failed pipeline.
- The Dossier is cumulative. Every piece of feedback -- yours at batch 1, the customer's at batches 2-5 -- builds up. By batch 5, the AI should be writing content that closely matches the customer's expectations. If it is not, something earlier in the process went wrong.