A customer sends an email about an existing project. An account manager finds the CRM record, checks the history, adds a note and prepares a reply. The same sequence happens whenever another message arrives.
An AI prototype can demonstrate parts of this work. Moving it into daily use means deciding which records it may read, which changes it may prepare and which actions it may carry out. The business goal is to reduce the total effort needed to handle the message while keeping responsibility clear.
For a first rollout, define one small workflow that the team can observe and evaluate. The example below shows how to do that. It is hypothetical; it does not describe a client project or a measured Madency result.
Define one unit of work
Start with a sentence that names an input, an output and an owner:
When a customer email arrives, prepare a CRM note and a reply draft for the responsible account manager.
Limit the first version to a defined inbox or message category and a known type of customer record. Agree what a useful note contains and who handles messages outside that category. A manageable starting point might be an internal draft containing a summary, the source message and a proposed next step.
Map the current process before adding AI. A fixed rule may be enough to route the message. Interpreting its text may need a different approach. Choose the simplest combination that can handle the defined work and be tested by the team.
If you are still choosing which process deserves attention, use the first-workflow scorecard to compare candidates.
Separate reading, drafting and taking action
These three capabilities require different decisions:
| Capability | Boundary in this example |
|---|---|
| Read | Retrieve the source email and the customer information needed for this task. |
| Draft | Prepare a proposed note and reply for the account manager to inspect. |
| Act | Add the approved note to the specified CRM record. Sending the reply requires a separate decision. |
For this first version, the manager sends the reply from their email client. The integration's write permission covers only adding the reviewed CRM note. Changing an opportunity value, deleting records or emailing customers would expand the scope.
Permissions need enforcement in the application performing the action. The design should check access for the relevant user, record and operation; a request to the model to follow the rules is insufficient. This follows OWASP's authorization guidance.
The existing AI–CRM integration guide explains the data and access foundations. Here, the next question is what happens when prepared information becomes a change to a business system.
Make approval specific enough to review
The manager should see what they are being asked to approve: the customer record, the proposed note and the email it came from. A button labelled “Approve” gives little context on its own.
In our example, the review screen could show the record name, a link to the source message and the exact text that will be added. If the note changes after review, the new version needs another decision. Approval should apply to the action the person actually saw, consistent with OWASP's transaction-authorization guidance.
The account manager also needs a practical way to edit or decline a draft. A workflow that produces plausible notes but makes correction awkward may add work to the day. Test the review step with the people who will use it.
Decide what happens when the workflow cannot continue
A successful demonstration usually follows a prepared path. A rollout also needs answers for interruptions. For the hypothetical email workflow, agree the expected behaviour for cases such as these:
| Situation | Expected behaviour to define |
|---|---|
| Two customer records could match | Ask the responsible person to choose before preparing a change against either record. |
| The email conflicts with a CRM note | Show both sources for review rather than silently choosing which one is current. |
| The CRM is unavailable | Keep a visible pending or failed status and give the task an owner. |
| A write request times out | Check whether the note was added before deciding to repeat the operation. |
| The draft is edited after approval | Return the changed version for review before execution. |
The timeout case deserves attention: a missing response leaves the outcome uncertain. The implementation needs a way to check the existing result and control retries. The exact mechanism depends on the CRM and integration.
Choose what the team must be able to inspect afterward: the source, proposed change, approving person, attempted action and observed outcome. Set access and retention rules for this record; logging should avoid unnecessary copies of customer information.
Measure the full human effort
Before the pilot, observe how the team handles comparable messages today. During the pilot, include preparation, review, correction and exception handling in the time spent on each message.
Useful questions include:
- How much manual time does a comparable message require from start to finish?
- How often does the manager substantially rewrite the note or reply?
- Were the approved changes made to the intended records?
- How much work returns to a person because the system cannot continue?
- Do team members use the workflow when they have a choice?
Agree the criteria for continuing before the pilot. More generated drafts alone do not establish value. The team needs evidence that the process helps with its actual workload at an acceptable level of quality and oversight.
The result may justify keeping the same scope, improving the review experience, expanding one permitted action or stopping the experiment. This is a practical measurement approach, not a promised saving or a universal rollout threshold.
Turn the boundaries into a build scope
The example now has concrete inputs for scoping: connected systems, allowed records, draft content, write permissions, approval behaviour, interruption handling, outcome records and a named owner after launch.
Those decisions also reveal the work beyond the prototype. The team needs access to the real systems, representative test cases and a clear way to handle problems. Assign responsibility for keeping the process useful as data and working practices change; the AI operations guide covers that ongoing role.
Madency's process starts with a fit call to assess the workflow. Where Discovery is appropriate, it costs $500, credited toward the build. Development is scoped afterward. Discovery does not promise a completed integration for that price. The cost guide explains what affects the scope and investment.
Bring one recurring task your team handles manually, including the point where a person needs to approve the result. Discuss the workflow with Madency so we can assess whether Discovery is the right next step.