The send permission is a policy, not a setting
A mailbox permission can let an assistant send anything. That does not mean the role should. The decision about autonomous sending belongs in a written policy that names message classes, audiences, and stop conditions.
Treat the send button as an authorization point. Every message class either has standing approval or it routes to a named reviewer. There is no third category called use judgment.
Classify messages by consequence
Low consequence: internal notes, confirmations of a time already agreed, and replies that only acknowledge a request. Medium: scheduling messages and follow-ups that restate an approved offer. High: pricing, legal terms, commitments, and anything sent to a new segment.
The classification should be based on what the message can commit, not on how routine it feels. A short message that confirms a discount is high consequence.
Write the approval matrix
Map each class to a sender, a reviewer, and an evidence requirement. The matrix should fit on one page and use role names rather than individual names so it survives staff changes.
Include a default row: anything not listed requires review. A default that permits sends will slowly expand the autonomous set without anyone deciding to expand it.
Use the related specialist service as a starting point for scope and evidence.
Log every autonomous send
Record the message class, the contact, the template version, the send time, and the rule that authorized it. If the assistant sends from a shared mailbox, the log should identify the role, not just the mailbox.
The log exists so a reviewer can sample sends without reconstructing them from memory. It also makes an unexpected expansion visible before a customer notices.
Review the boundary monthly
Sample autonomous sends across classes and check three things: the message matched its class, the evidence existed, and no stop condition was present. Include one send that a reviewer would have blocked.
When a mismatch appears, fix the classification or the template. Do not respond by removing all autonomy; that hides the specific defect and pushes the team back to a queue nobody can clear.
NIST, Digital Identity Guidelines (SP 800-63-4) provides public guidance that can help test workflow assumptions.
Escalate when the record is incomplete
An assistant should stop when the contact record is missing an owner, the suppression state is unknown, the thread contains a legal question, or the message would create a new commitment.
The stop should create a visible task with the reason and the evidence. A silent pause looks like a backlog and gets worked around.
Common questions
Can an assistant send scheduling messages alone?
Only if the written matrix classifies them as approved, the time was already agreed, and no new commitment is created. Otherwise they route to the owner.
What should be logged for an autonomous send?
Message class, contact, template version, send time, and the rule that authorized the send.
What is the safest default for unlisted messages?
Require review. A default that permits sends expands autonomy without an explicit decision.
Turn the guidance into a controlled role
Bring the workflow, systems, current owner, and known exceptions. We will help shape a focused first handoff.
Plan a consultation