In this article
The short answer
Don't give a sales agent one large permission switch. A draft and a delivery promise need different owners. Set approval rules for each action and test the stop controls.
Start with actions, not a single autonomy switch
A broad setting called autonomous hides important differences. A system reading a public company page is doing something different from sending an email or changing an opportunity. List those actions separately before deciding what can run unattended.
NIST's artificial intelligence (AI) Risk Management Framework is voluntary guidance for managing AI risks across design, use and review. It doesn't prescribe this sales approval map. The map below is our practical application of risk-based oversight. [1]
List each allowed action on its own row. Give 1 named person the right to pause it before a pilot starts.
Research: permit collection, review conclusions
Public facts can be gathered within an agreed research scope. Keep the source, date and company identity with each finding. Flag conflicting evidence rather than resolving it by guesswork.
Separate a fact from its reading. A new operations leader is a fact when a reliable source supports it. A claim that the business will buy a particular service is an inference.
A reviewer should be able to accept the first without accepting the second.
For a hypothetical Pune services team, a reviewer may approve research but lack authority to quote a delivery date. Keep those permissions separate.
For 1 researched company, ask a reviewer to separate sourced claims from guesses. An unread source is not a checked claim.
Messages: make approval specific
Show the recipient, channel, message and supporting evidence together. Approval of a template is not necessarily approval of every personalised claim inserted later. Decide which changes require another review.
Check the stop list at the point of sending. A message approved yesterday should not go out today if the person has since opted out. Prevent a retry from creating a second send when the first result is unclear.
These are review questions to ask a tool provider, not claims about every tool.
Change 1 recipient after approval in a safe test. Confirm that the old approval can't silently authorise the new send.
Records and commitments: narrow the permission
For customer relationship management system (CRM) changes, define the allowed fields and the reason for each change. Proposing a correction should not silently grant permission to replace the existing record. Preserve who requested the change and what was there before.
Keep pricing, legal terms, delivery promises and unusual security questions with the person in charge. A plausible sentence can become a commitment once it's sent. Escalation should retain the buyer's first question so that the person can answer in context.
A hypothetical Bengaluru seller may work in Indian Standard Time (IST) while the buyer works elsewhere. An approval should specify the send window as well as the message.
Take 1 proposed field change and inspect its old value. If the reviewer can't see it, they can't judge the change properly.
Test the boundary before raising volume
Use a small set of deliberate checks: a revoked approval, an opted-out recipient, a wrong-company source, an interrupted send and a conflicting CRM value. Confirm that each stops or goes to a person as intended.
A working pause control needs an owner and a clear scope. The team should know whether pausing stops future sends, queued sends or research as well. Record the answer in operating instructions and revisit it whenever permissions change.
The goal is an understandable process that can be inspected, not the appearance of zero human effort.
Use 2 test owners with different access rights. Confirm that each can approve only the actions assigned to their role.
Put it into practice
Write the approval card in plain words
An approval card should fit on one screen. Name the action, the audience, the reviewer and the expiry. Add the exact change that would cancel the approval.
Take an illustrative services team in Noida. Priya may approve an introductory email. Rohan must approve any proposed project start date.
Neither permission implies the other.
The card says: send this message to this person during this window. If the recipient, claim or attachment changes, ask again. That rule is easy to inspect.
Now test a reply that arrives before the send. The old message may no longer make sense. The system should pause it and show the new context.
Test an opt-out too. Approval can't revive a stopped contact. Show the decision at send time, when it matters, rather than relying on yesterday's list.
For a customer relationship management system, usually called a CRM, name the field that may change. Saying update the CRM grants far too much room.
An illustrative change might mark one task complete after its owner confirms the work. It shouldn't also change the person's role or the company's sales stage.
Keep the old value, proposed value and reason together. If a person rejects the change, keep that rejection visible to the next run. Don't make them correct it twice.
The tempting shortcut is a permanent approval for every message in a campaign. We would start smaller. Personal claims can change even when the template stays the same.
Give the owner a test they can run without an engineer. Pause a queued message and check that it stays paused. Then change its recipient and confirm approval resets.
Save the card beside the team's working instructions. Review it when the tool gains a new action. Extra access should be a deliberate decision.
Common questions
Does human approval make automation pointless?
No. Research and drafting can still remove repeated work. Approval concentrates human attention on factual accuracy and consequential actions.
Should every action need the same approval?
No. Set permissions per action and audience. Read-only research, external messages, record edits and commercial promises have different consequences.