Prepare for a demo from the last call

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.

# Prepare for a demo from the last call

You have access to a call-recording tool, a CRM, web search, a
professional network, and a messaging tool. Run this for **[the
company and the meeting date]**.

## 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 call-recording tool, your CRM, web search, a professional
   network, and your team's messaging tool.

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.

## 1. Pull what was actually said

Find every recorded call with this company. Search by attendee email
and separately by company domain, because a call is recorded by
whoever hosted it and the person you are looking for may sit on a
colleague's call rather than their own.

From each call, extract four things and nothing else:

- The problems they described, in their words, not paraphrased into
  your category names.
- Any objection raised, and whether it was resolved on the call.
- Commitments made by either side, with who owes what.
- Names and roles of everyone who spoke.

Quote them. A paraphrase into your own vocabulary is exactly the
translation that loses the detail worth repeating back to them.

## 2. Read the deal's state

Pull the opportunity: stage, value, close date, owner, and the history
of stage changes. A deal that has slipped its close date twice is a
different meeting from one that just opened, and the brief should say
which one this is.

Note anyone on the account record who has not appeared on any call.
A stakeholder who exists in the CRM and has never spoken is the single
most useful thing to flag before a demo.

## 3. Check what has changed since you last spoke

Search for anything public about the company since the date of the
last call: a funding round, a leadership change, a product launch, a
reorganisation. Check the attendees' own profiles for role changes.

A demo that opens by referencing something that happened last week is
a demo where they know you were paying attention. Keep the source URL
for anything you plan to mention.

## 4. Build the deck around their use cases

Draft the deck from the problems in step 1, in the order they raised
them. Not the standard deck with their logo on it: the sections exist
because they said those things.

Rules for the draft:

- One slide per problem they actually named. If they named three
  problems, the deck has three problem slides, not the usual seven.
- Any unresolved objection from step 1 gets its own slide. Skipping it
  means it gets raised in the room instead, with less preparation.
- Where a claim needs a number, leave a bracketed placeholder rather
  than inventing one. A confident wrong figure in a demo is worse than
  a gap the presenter fills from memory.

## 5. Post it before the meeting

Post to the team channel: the brief first, deck link second. The brief
is what someone reads on the way into the room; the deck is what they
open once they are there.

Lead the brief with the single most important thing, which is usually
either an unresolved objection or a stakeholder who has never spoken.

## Output

Report: calls found and their dates, problems extracted, unresolved
objections, stakeholders who have not appeared on a call, what changed
since last contact, and the number of slides drafted.