The 37Act content and tool roadmap

The 37Act site should become an informational resource hub for a very specific operational problem: California 1937 Act / CERL reporting workflows. The site is not just a brochure. It should answer the questions a retirement-system administrator, CFO, reporting manager, actuarial liaison, auditor, board secretary, or CIO would ask while trying to make the annual reporting cycle less fragile.

The reusable model

This is the same informational-site growth system Brandon asked to codify from The Glow Diary: combine a practical tool layer, evergreen guide cluster, recurring research loop, trust surfaces, AI/search discovery, and conversion path into one compounding site. For 37Act, each part maps to public pension reporting rather than health education.

Near-term content queue

1. Source-file inventory checklist for annual 37 Act reporting.
2. Contribution reconciliation exception-log template.
3. GASB 67 / GASB 68 support packet explainer.
4. Actuarial valuation data request packet guide.
5. Audit evidence binder readiness checklist.
6. Board packet production workflow for retirement systems.
7. County retirement system report-library source notes.
8. Procurement and security readiness for a design-partner pilot.

CERL-focused next-stage content plan

Source basis: SACRS describes the County Employees Retirement Law of 1937 as the law governing retirement benefits for certain county and district employees in adopting counties under Section 31500, and notes that 20 California counties operate retirement systems under the 1937 Act. The content should treat CERL as the legal backdrop for operational reporting workflows, not as a promise that 37Act provides legal, actuarial, or audit advice.

Stage 1: Strengthen the core CERL explainer cluster

Goal: make 37Act the clearest practical starting point for people searching for CERL, the 1937 Act, and county retirement reporting responsibilities.

Planned pages and updates:

• Expand /cerl-reporting-requirements into a source-aware pillar page that explains what CERL is, who it applies to, why Section 31500 matters, and how CERL creates recurring operational work for county retirement systems.
• Add a companion page: What is the County Employees Retirement Law of 1937? focused on plain-English orientation for administrators, finance staff, board members, and vendors.
• Add a companion page: CERL vs. CalPERS: why county retirement reporting is different with careful, non-legal language and an operations lens.
• Add an FAQ section covering: what CERL means, which entities may be involved, why reporting varies by county system, what software can support, and what still requires professional review.

Quality bar:

• Cite SACRS and other public sources where factual statements are made.
• Avoid compliance-certification language.
• Always connect legal context back to practical reporting, evidence, and review workflows.

Stage 2: Build workflow pages around CERL reporting pain

Goal: turn CERL interest into specific workflow topics that map to 37Act’s product wedge.

Planned pages and updates:

• CERL employer contribution reporting workflow — intake, reconciliation, exception handling, review, and exports.
• CERL member data reporting workflow — status changes, service credit data, demographic fields, and validation checkpoints.
• CERL actuarial valuation data preparation — data request packets, assumptions handoff, review history, and version control.
• CERL audit evidence binder — source files, reconciliations, approvals, and workpaper support.
• CERL board packet reporting checklist — exhibits, narratives, agenda support, and review routing.

Conversion angle:

Each workflow page should include a small “where spreadsheets break” section and a “how a purpose-built workspace helps” section. This keeps content educational while building demand for the product.

Stage 3: Publish CERL tool and template assets

Goal: create useful downloadable or page-based assets that expose pain points and support design-partner conversations.

Tool backlog:

• CERL annual reporting source-file inventory.
• Employer contribution reconciliation exception log.
• Member status-change validation checklist.
• Actuarial data request packet checklist.
• Audit evidence binder table of contents.
• Board packet readiness checklist.
• Reporting calendar / milestone planner for a county retirement system.

Lead-capture path:

• Keep the first version ungated or lightly gated to earn trust.
• Add a CTA for a workflow assessment or design-partner conversation after the tool explains the operational problem.
• Track which tools get interest to prioritize product development.

Stage 4: Create role-based CERL content

Goal: write for the people who actually feel the workflow pain, not just the generic keyword.

Role pages or article angles:

• For retirement system administrators: reducing annual reporting chaos.
• For CFOs and finance teams: traceability from source data to financial and GASB support.
• For actuarial liaisons: cleaner valuation data packages and assumption handoffs.
• For auditors: evidence organization, review history, and export consistency.
• For board secretaries: board-ready packet production and narrative consistency.
• For CIOs / IT leaders: integrations, security, permissions, and vendor review.

CTA strategy:

Each role page should point to the most relevant workflow page and tool asset rather than sending every visitor directly to the same demo pitch.

Stage 5: Deepen county-system context pages

Goal: use public-source county pages to build relevance without overclaiming knowledge of any system’s internal process.

Planned updates:

• Add a standard CERL context module to each county retirement system page explaining that the page is based on public information and that workflows vary by system.
• Link each county page back to the CERL pillar, reporting workflow pages, and relevant tool assets.
• Add public report/library source notes where available: annual comprehensive financial reports, actuarial valuations, board materials, employer contribution materials, and audit references.
• Prioritize pages for the 20 CERL county systems first, then refine based on search interest and design-partner relevance.

Guardrails:

• Do not imply endorsement, partnership, or inside knowledge.
• Separate public-source observations from product recommendations.
• Keep local pages helpful, factual, and operationally framed.

Stage 6: Build recurring CERL research briefings

Goal: make the content system compound through a repeatable research loop.

Monthly briefing format:

• New or updated CERL / 1937 Act source links.
• Public report examples worth learning from.
• Reporting pain patterns observed across county materials.
• Product hypotheses for 37Act.
• Content updates shipped this month.
• Open questions for professional review or design partners.

How to use it:

• Turn each briefing into updates for pillar pages, county pages, and tool templates.
• Feed high-confidence operational patterns into product requirements.
• Keep sensitive or speculative notes out of public copy until reviewed.

Stage 7: Add trust, review, and procurement surfaces

Goal: make CERL content credible enough for serious public-sector buyers.

Planned pages and updates:

• Professional review boundaries for CERL reporting software — what 37Act helps with, what counsel/actuaries/auditors must review.
• Security and permissions for county retirement reporting data — roles, access, source files, audit logs, retention, exports.
• CERL reporting software procurement checklist — pilot scope, data access, integrations, security review, acceptance criteria.
• Design-partner pilot plan for a CERL retirement system — low-risk pilot scope with non-production or limited-source data first.

Positioning principle:

Trust content should reduce perceived implementation risk. It should not create compliance promises that the product cannot safely make.

Recommended production sequence

1. Expand the existing /cerl-reporting-requirements page and add the general What is CERL? article.
2. Publish the source-file inventory and employer contribution exception-log assets.
3. Add the first three workflow pages: employer contributions, actuarial valuation data, and audit evidence binder.
4. Add role pages for administrators, finance teams, and auditors.
5. Add county-page CERL context modules for the 20 CERL systems.
6. Start the monthly CERL research briefing archive.
7. Add procurement, review-boundary, and design-partner pilot pages.

Immediate next five content tickets

1. Rewrite /cerl-reporting-requirements as the main CERL pillar page with SACRS source notes and safer professional-review language.
2. Draft What is the County Employees Retirement Law of 1937? as a plain-English article.
3. Draft CERL employer contribution reporting workflow as a product-aligned workflow page.
4. Convert the source-file inventory checklist into a CERL-specific tool asset.
5. Add a reusable county-page CERL context block that can be inserted into each CERL system page.