> ## Documentation Index
> Fetch the complete documentation index at: https://deepline.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Turn call evidence into reviewed CRM updates

> Convert a ready meeting transcript into reviewed CRM update proposals with source evidence.

[Human guide: work with your agent →](https://deepline.com/docs/human/guides/post-call-crm-automation.md)

Convert one call record into proposed CRM changes. Link each proposed field value to the supporting call evidence.

## Before you start

Use an authorized workspace and a small file with stable source IDs.
Have source access and your team's acceptance policy available.
This guide describes customer-authored logic, not an automatically enabled product policy.

## 1. Understand the decision

A meeting-ended event does not necessarily mean the transcript is available. Choose a supported readiness signal or explicit retrieval check.

Test this fictional sample before calling providers:

| Case | Expected decision under this example policy |
| - | - |
| Transcript ready with explicit next step | Prepare the supported proposal |
| Meeting ended but transcript unavailable | Wait through the supported readiness path |
| Write submission timed out | Reconcile the destination outcome |

## 2. Inspect supported operations

```bash theme={"languages":{"custom":["/languages/deepline-prompt.json"]}}
deepline auth status --json
deepline search "meeting transcript call CRM update" --type tools,prebuilts --json
```

Inspect a returned ID with `deepline describe <returned-id> --json`.
Compare required identifiers, outputs, access mode, and price.
A similar title does not establish that a contract fits.

## 3. Implement the bounded workflow

Ask your agent to author `post-call-crm-automation.play.ts` using [Write Plays](https://deepline.com/docs/sdk-v2/plays.md).
Have it declare the CSV input and preserve source IDs.
Reuse existing contracts when they fit the transformation.

Implement these rules explicitly:

1. Distinguish meeting completion, transcript readiness, and retrieval failure.
2. Retrieve the authorized transcript and resolve participants to CRM identities.
3. Preserve the supporting passage for each proposed field or task.
4. Keep unstated dates and owners unknown. Reconcile uncertain writes before another attempt.

Keep external changes disabled for the first pilot.
That control belongs in the authored logic, not a universal Play dry-run flag.

## 4. Check and pilot

Prepare `pilot.csv` using [CSV-safe selection](https://deepline.com/docs/sdk-v2/batch-csv.md).
Then check the source:

```bash theme={"languages":{"custom":["/languages/deepline-prompt.json"]}}
deepline plays check post-call-crm-automation.play.ts
```

Resolve authoring errors first. After reviewing source and price, run only the pilot:

```bash theme={"languages":{"custom":["/languages/deepline-prompt.json"]}}
deepline plays run --file post-call-crm-automation.play.ts --csv pilot.csv --watch
deepline runs get <run-id> --full --json
deepline runs export <run-id> --out post-call-crm-automation-review.csv
deepline billing usage --run-id <run-id> --json
```

Use the ID returned by the pilot. Select a returned dataset path when several
exist. Provider-backed execution can incur usage.

## 5. Verify the outcome

Trace each proposal to the transcript passage. Keep source retrieval failures separate from meetings with no agreed next step.

> [!TIP]
>
> Every source ID has a result or explicit exception. The fictional cases follow
> the stated policy, and actual results retain their evidence.

Ask your agent why a record was accepted, held, or rejected.
Correct the rule before expanding input or enabling external writes.

## Continue

[Follow-up drafting](https://deepline.com/docs/guides/sales-follow-up-automation.md) covers commitments. [Monitor setup](https://deepline.com/docs/plays/set-up-a-monitor.md) applies only to supported feeds.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.