For the complete documentation index, see llms.txt. This page is also available as Markdown.

Agency CRM example

This example brief accompanies Customize the CRM Template. Use the existing guide for setup, target creation, artifact order, review stages and deployment. This page adds an agency-specific scope and acceptance checks; the proposed agency app has not been implemented as part of this content series.

Watch the template overview

Define a useful first version

Start with account → opportunity → next action → pipeline review. Add the minimum proposal information needed to support that journey. Agree how a retainer relates to an account and an opportunity before introducing recurring commercial records.

Requirement
Question to resolve

Pipeline

What observable condition permits each stage change?

Account ownership

Can multiple team members work on an account?

Proposal

Which amount, version and decision status matter?

Retainer

Is it a separate relationship, record or opportunity type?

Follow-up

Who is responsible, and what defines an overdue action?

Approval

Which proposals or changes require a person’s decision?

The source demonstration uses widget-business records. Do not carry those examples into an agency’s real data or presentation.

Give the agent a focused brief

Complete Getting started with Builder MCP, then use:

Review the proposed model

Check whether proposed entities represent different business concepts or merely different names for the same thing. A signed retainer, an open proposal and a potential sale may need different lifecycle rules.

Make the expected source of each value explicit. For example, an opportunity forecast and an agreed contract amount should not become interchangeable just because both are currency fields.

Use the accepted model to guide screen bindings. Remove source IDs, labels and widget assumptions that do not belong in the target.

Verify the first agency journey

Create synthetic accounts with opportunities in different stages. Include an opportunity without a next action, an overdue follow-up, a lost opportunity and a proposal awaiting review, if those states are in the accepted scope.

Check
Pass condition

Create opportunity

Required fields validate and the correct account is linked

Board/list views

Both open the same underlying target record

Stage change

The agreed rules and permissions apply

Follow-up

Owner, due date and account/opportunity context persist

Proposal

Version, value and status match the accepted model

Retainer

The agreed relationship is preserved without duplicating commercial totals

Recommendation

A proposal remains distinct from an accepted fact

Required approval

An unapproved action cannot bypass the human decision

Restricted user

Protected commercial details and actions remain inaccessible

Retest after reloading the target app so the evidence covers saved behaviour. Record expected results, observed results and the role used for each check.

Add runtime AI access separately

Builder MCP changes the application definition. Buzzy Custom MCP exposes selected data and actions from the finished app to an approved AI client. Follow Custom MCP implementation only after the target permissions and approval boundaries are accepted.

Start with the smallest useful runtime tool set. An agent summarising an opportunity does not need the same permissions as one changing a sales stage or communicating with a customer.

Check the cost path

Direct artifact adaptation can use an eligible agent subscription allowance without Buzzy generation credits. Provider limits still apply; API billing, Buzzy-managed generation and deployment are separate. See AI usage and pricing.

Explore the template series

Read the article overview or explore the complete Builder MCP template series.

Last updated