Customer advocacy consent should follow the use you want to make of the customer's words, name, contact details, or time. Ask for permission when you need it, record exactly what the customer allowed, and check the record before making a reference request or publishing anything. Each permission covers a specific use. A signed authorization can record that customers agreed to be contacted.1 Feedback can be kept confidential or published as anonymized guidance.2 Each boundary needs its own decision.
Define the use before you ask
Define the action before asking. A vague request for "advocacy permission" makes it difficult for the customer to understand what they are accepting and for you to honor the decision later.
Separate the request into permissions:
- May we name your company in sales or marketing material?
- May we use your exact words as a quote?
- May we introduce you to a prospect who wants to speak with a customer?
- May we publish your story publicly?
- May we use your feedback internally?
Ask about each use separately, even when the same customer is involved. One customer may agree to speak with a prospect and decline public use of their name. Another may approve an anonymized account of their experience while keeping the underlying feedback confidential.
Put the audience and channel beside each permission. "Contacted" should mean something specific in your record: who will make contact, which route they will use, the purpose, and the period covered. "Published" should identify where the material may appear and whether it includes the customer's name, company, role, logo, or quotation.
Proceed only after the customer has answered the specific use you intend to make. If the answer covers one use and leaves another unclear, keep the unclear use closed.
Capture the decision in writing
Write the record so another person can understand the permission without replaying the conversation. Include the exact use, approved audience, permitted contact route, limits, date of the decision, expiry or review point, and record owner.
A written authorization can record agreement to be contacted.1 Apply the same discipline to advocacy: save the customer's wording, the request you made, and the answer you received. A broad note such as "customer is happy to help" leaves too much room for interpretation.
Give the customer a clear choice about what happens to feedback. It can remain confidential or become anonymized guidance for publication.2 Put that choice in the request, then carry it into the record and the handoff.
Ask questions that make the permission usable:
- What may we say about your experience?
- May we use your name, your company name, both, or neither?
- May we quote your words exactly, or should we edit them for clarity?
- May a prospect contact you directly?
- Which contact route should we use for that introduction?
- How long should this permission remain open?
- What should we remove if you withdraw permission?
Keep the approved use narrow. A narrow answer gives the next person a clear boundary and reduces the chance of accidental publication or an unwanted introduction.
Check the contact point before a handoff
A reference request fails when the record contains permission but no usable way to reach the customer. Check the approved route immediately before sharing contact details or making an introduction.
Consent can be managed from Lead and Contact records in a marketing app.3 If you use that control, treat its preview status as part of your operating process.4 Make sure the people handling advocacy know where the decision appears and what each field means.
The contact record needs a reachable field. When neither an email address nor a mobile phone is present, the consent control displays no contactable field and asks for those fields to be completed.5 When one field is present, the control displays it. When both are present, the user can switch between them.6
Before handing a prospect a contact route, compare the route the customer approved with the route stored in the record and the route you plan to share. Stop when they do not match. Ask the customer to confirm the route again if the record is stale, ambiguous, or missing.
Keep customer permission separate from system access
A customer's permission to participate in advocacy and an application's permission to access company data can appear in the same workflow. Keep them in separate records and review them through separate decisions.
Application consent, enterprise application assignments, partner access, administrator roles, and support data access are distinct access paths.7 They use different identities, approval methods, scopes, time limits, logs, and revocation methods.8 Software approval therefore does not prove that a customer approved a quote or reference call, and a customer's advocacy approval does not authorize software to read their data.
Give every system access path a named owner and a reproducible decision record.9 Record the requested scope and the person authorized to approve it. User and admin consent control whether an application receives delegated or application permissions and who may approve the scope.10
Review software access against its own security standard. Admin consent can affect an entire organization, so review each request against the business need and security risk.11 Keep that review with the system access record, separate from the customer's advocacy permission.
Review before you publish or introduce
Run a final permission check at the moment of use. The person preparing a case study, arranging a reference call, or sending a quote should be able to answer the permission questions from the record alone.
Check the proposed use against the approved use. Confirm the customer's identity details, quotation, audience, contact route, publication setting, and expiry or withdrawal instruction. If the proposed material has changed since approval, ask again about the changed part.
For a prospect introduction, share only the contact route the customer approved and tell the prospect what kind of conversation the customer agreed to have. For a public feature, confirm separately whether the customer accepted naming, quotation, company identification, and public distribution. For internal feedback, preserve the confidentiality boundary when moving the record between teams.
If the record says anonymous, remove identifying details before publication. If it says confidential, keep it out of public material. If the record is silent, pause the use and return to the customer with a specific question.
What not to do
- Do not stretch a signed contact authorization into permission to publish a name or quotation. The authorization described here records agreement to be contacted.1
- Do not publish feedback until the customer has chosen confidentiality or anonymized public guidance.2
- Do not treat software consent, enterprise application assignment, and other access paths as interchangeable. They have different controls and revocation methods.7, 8
- Do not assume a visible list of principals with consent policies identifies everyone who can grant application consent in the organization.12
- Do not approve system access casually when the request can affect the wider organization. Admin consent needs a review of business need and security risk.11