# Account health without the gut feel

Nobody needs to read every Slack thread to know if an account is healthy — that's an inference problem, not a willpower problem. These blueprints read the scatter, Slack, usage, audit, and return the same structured health read every time.

[Book a demo](/content/demo/index.html) [Browse every blueprint](/content/blueprints/index.html)

## Parameters

Typed inputs, declared up front

## Tools

BigQuery

Slack

### Adoption risk

- Sessions
- Scoped context per call

### Typed output

- Health overview
- Risk flags
- Adoption gaps

## What breaks when you do this by hand

- Account health lives in someone's head, read fresh out of Slack threads every time.
- Adoption and reliability data sits in tables no one queries by hand — so health calls run on gut feel.
- Tenant reviews mean rebuilding the same deck from scratch, every quarter.

## What you get instead

- One structured health read — usage, audit, and error data, reconciled automatically
- Scheduled reporting instead of a person scrambling before every QBR
- The same signal, read the same way, across every account

## This is the whole thing

The opening of **Customer Health Report** — the system prompt, its typed parameters, and the tools it's allowed to reach, all declared up front. No canvas, no hidden nodes. 221 lines of source you can review in a pull request.

[Read all 221 lines →](/content/blueprints/customer-analytics/index.html)

customer-analytics.fml

Copy

```
system("You are a CS and DevOps analyst generating a customer health report.")

parameter("tenant_id", type=string, title="Tenant ID")
parameter("customer_name", type=string, title="Customer Name")

require mcp BigQuery

components {
    schema("ServerStats") {
        mcp_name: string
        status: string
        total_tool_calls: int
        total_errors: int
        error_rate: float
        active_users: int
        distinct_tools_called: int
        active_days: int
        first_call: string
        last_call: string
        days_since_last_call: int
        connected_but_never_called: bool
    }
}
```

## 3 blueprints you can run today

Every one is a typed FML plan. Open it, read the source, and run it — nothing here is a mockup.

[**Customer Health Report** \ 
Health calls run on gut feel because the data sits in warehouse tables nobody queries by hand.\ 
\ 
Customer success\ 
\ 
Account teams\ 
\ 
Ops\ 
\ 
Read the blueprint](/content/blueprints/customer-analytics/index.html) [**Customer Slack Signals** \ 
Account health lives in scattered Slack threads. No one has a repeatable way to read it — so nobody really does.\ 
\ 
Customer success\ 
\ 
Account management\ 
\ 
Support\ 
\ 
Read the blueprint](/content/blueprints/customer-chatter/index.html) [**Tenant Usage Report** \ 
A dozen ad-hoc warehouse queries, rebuilt by hand for every tenant review.\ 
\ 
Customer success\ 
\ 
Platform ops\ 
\ 
Account teams\ 
\ 
Read the blueprint](/content/blueprints/customer-logs/index.html)

## What every blueprint here guarantees

- Zero prompt drift
- Scoped sessions
- Typed output
- Reusable like an API

Every blueprint is a versioned contract. Run 1 and run 10,000 behave identically. Each LLM call sees only the context it needs — no one giant prompt, no context rot. Blueprints return validated objects pinned to a schema, not text you have to parse. Parameterise once and call it from anywhere — versioned, auditable, shareable.