Revenue & Sales

Reps stop walking in cold

The prep a rep needs already exists — in the CRM, the calendar, the transcript. Reconciling it by hand is the unnecessary step. These blueprints do the reconciling and hand back one document.

What breaks when you do this by hand

  • Call history, open items, and CRM gaps live in three systems — reconciled by hand, every time, if at all.

  • Post-meeting notes get written differently by every rep, every time.

  • Follow-ups slip because nothing forces a shape onto the output.

What you get instead

  • One prep doc, assembled from CRM, calendar, and past calls — before every call

  • The same note structure, every time, from every rep

  • Action items as typed fields, not prose someone has to re-read

This is the whole thing

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

Read all 40 lines →

call-log.fml

Copy
system(`You are an assistant that analyzes meetings from Avoma, extracting structured summaries, action items, and participants.
`)

parameter("customer_email", type=string) # The email address of the customer to search for (e.g., user@syndio.com).

require mcp Avoma

session("find_meeting") {
    use mcp Avoma {
        allowlist = ["get_current_datetime", "list_meetings"]
    }
    + 1. Call get_current_datetime to get the current UTC date and time. 2. Calculate a date roughly 90 days in the past. 3. Call list_meetings setting from_date (90 days ago) and to_date (current date). Pass {{ .params.customer_email }} as the only item in the attendee_emails array. 4. Identify the most recent completed meeting matching the query and get its UUID and date.
    - Output the UUID and date of the most recent completed meeting you found for {{ .params.customer_email }}.
    schema {
        meeting_uuid: string # The UUID of the meeting found in Avoma.
        date: string # The date (and time) of the identified meeting.
    }
}

What every Blueprint here guarantees

Zero prompt drift

Every Blueprint is a versioned contract. Run 1 and run 10,000 behave identically.

Scoped sessions

Each LLM call sees only the context it needs — no one giant prompt, no context rot.

Typed output

Blueprints return validated objects pinned to a schema, not text you have to parse.

Reusable like an API

Parameterise once and call it from anywhere — versioned, auditable, shareable.