Draft the monthly investor update

The prompt

The real prompt behind the steps above — detailed enough that an agent with a people-search tool, email/phone enrichment, and CRM access can run it as written.

# Draft the monthly investor update

You have access to a payments system, a CRM, a spreadsheet, and email.
Run this on **[the first working day of the month]**.

## 0. Set up (skip if you're already connected)

If you don't already have live tool access for this, connect it
first. This prompt is only as real as the tools behind it:

1. Create a free account at app.tulina.ai.
2. Add Tulina's MCP server to your assistant: https://mcp.tulina.ai/mcp
3. In Tulina, connect your own API keys for the tools this
   prompt uses: your payments system, your CRM, a spreadsheet, and your email.

Once connected, your assistant has real tool access and the rest of
this prompt runs as written.

## 0b. Already on Tulina? Three things around the run

An account and the MCP server are not the whole setup. Two of these come
before the run below and one after it, and together they turn this from a
one-off answer into a process your workspace keeps:

1. **Activate this process's connectors first.** Call
   `oto_connector(op="list")`, match it against the tools named in step 3
   above, and `oto_connector(op="select", name="...")` every one that
   isn't active yet. Selecting a connector does not mount its tools in the
   conversation you're already in — reach them through `oto_call` for this
   run, or open a fresh conversation once they're all on.
2. **Attach the work to an existing project.** `oto_project(op="list")`
   shows your active org's projects: pick the one this work belongs to
   rather than opening another, and keep its id. The project is where this
   process, the tables it writes to and the connectors it uses hang
   together.
3. **When the run is done, save it as a process — with its graph.** Write
   the body with `oto_procedure(op="set", ...)`, then attach it with
   `oto_project(op="link", project_id=..., target_type="procedure",
   target_ref="<your slug>")`. The body has to carry a drawing: read
   `oto_guide(op="read", slug="procedure-flowchart")` and follow it
   exactly — ONE untagged fenced block in that grammar, opening with the
   trigger and a quoted example of what you'd type to start a run. Tulina
   parses that drawing back into the graph it renders as the process's
   default view, which is what makes it come out in the same style as
   every other process in the app; a drawing the grammar can't read falls
   back to raw characters instead. Saving a process needs org-admin
   rights — without them, hand the finished body to someone who has them.

Every number in this draft goes to people who will hold you to it.
Nothing below may be estimated, and anything unavailable is left
visibly blank rather than filled with a plausible figure.

## 1. Pull revenue from the system of record

From the payments system, for the closed month:

- New recurring revenue started.
- Recurring revenue lost, split into cancellations and downgrades,
  because they are different problems.
- Net movement, and the closing recurring revenue figure.
- One-off revenue separately. Folding it into recurring overstates the
  thing investors track most closely.

Use the payments system for revenue and never the CRM. A CRM records
what was sold; a payments system records what was collected, and the
gap between them is exactly the sort of thing an update should not be
wrong about.

State the currency and the exact date range used.

## 2. Pull pipeline from the CRM

For the same period: deals opened, deals closed won and lost, current
open pipeline by stage, and the movement in the pipeline total.

Note any single deal large enough to move the total on its own. An
investor reading a 40% pipeline increase should be told when it is one
deal.

## 3. Read the plan, and compute variance

Take this month's targets from the plan spreadsheet. Compute actual
against plan for each, as both absolute and percentage.

Do not editorialise the variance. State it and, where a cause is
visible in the data, name it in one clause. "Revenue 12% under plan;
two enterprise renewals slipped into the following month" is useful.
"Slightly behind but momentum is strong" is not a number.

If a target is missing from the plan, say so instead of inferring one
from the previous month.

## 4. Reconcile against what you promised last month

Find last month's update in the sent mail and extract every commitment
it made: a hire, a launch, a target, a milestone.

For each one, state what actually happened: done, slipped with a new
date, or dropped with a reason.

This is the section that makes an update trustworthy over time and it
is the one that gets quietly omitted when the news is bad. Generate it
from the previous email rather than from memory, precisely because
memory is selective about which promises it retrieves.

## 5. Assemble the draft

Order it: headline numbers, variance against plan, last month's
commitments and their status, pipeline, then asks.

Rules for the draft:

- Every figure carries its source and date range.
- Anything unavailable is left as an explicit gap, never estimated.
- No adjectives on the numbers. The recipient can decide whether 12%
  is good.
- Commentary is limited to naming causes that are visible in the data.

Leave it as a draft. A person adds the qualitative half, which is the
part they should be writing themselves.

## Output

Report: the date range used, each figure with its source, variance
against each plan target, commitments carried forward and their
status, any figure that could not be retrieved, and the draft's
location.