Workflow

Customer Reference Workflow: Request Permission and Coordinate the Conversation

Coordinate customer references with a permission request, introduction template, and follow-up board. Let Aurora prepare context while you approve the conversation.

By Finta Editorial TeamPublished October 13, 2026

A permission checkpoint connecting a reference request to a reviewed conversation.
Audience
Startup founders
Products
Aurora, CRM
Prerequisites
Approved customer context, Defined reference request, Customer permission
Expected outcome
A permissioned customer-reference request with confirmed scope, an approved introduction, and an owner for the next step.
Approval boundary
You approve the customer request, participants, shared materials, and outgoing messages.

Coordinate a customer reference by agreeing on the purpose, asking the customer for permission, sharing only approved context, and keeping the follow-up connected. A satisfied customer is not automatically available to speak with every investor or prospect.

This workflow gives the relationship owner a request template, a coordination board, and an Aurora assignment. It is a human-reviewed process you can run in Finta, not a promise that a preinstalled automation contacts customers for you.

The outcome

One appropriate reference conversation, with an agreed topic, a willing customer, correct participants, and an owned next step. If the customer declines, the outcome is a respectful closure rather than more reminders.

You need: a relationship owner, a specific reference request, the relevant customer context, approved materials, and a place to record the customer's response. Connected email or calendar can supply context where available; you can also provide the necessary notes yourself.

You approve: who is asked, what information is shared, every outgoing message, and any introduction or scheduling step.

1. Define what the conversation is for

Ask the requesting person what they want to learn. Product use, implementation, support, and buying experience are different subjects. Choose a customer who can speak about the relevant experience, not simply the most recognizable name.

Record the expected participants and the proposed time commitment. Do not promise that a customer will participate before asking them.

QuestionRecord
Who is requesting the reference?Person, organization, and relationship
What do they need to understand?One or two concrete topics
Which customer might help?Relevant experience, not assumed availability
Who owns the relationship?Responsible team member
What can be shared?Approved topics and materials
What remains unknown?Availability, permission, or sensitive information

2. Ask the customer without pressure

Adapt this message before sending:

Hi [name],

[Person and organization] would like to learn about [specific topic]. Your experience with [approved context] may be relevant.

Would you be comfortable having a [proposed duration] conversation about [scope]? No problem if the timing or request does not work for you.

I would only introduce you after you confirm, and I can share the proposed questions first.

Thanks, [Relationship owner]

Do not insert a positive quote the customer has not approved or suggest that they owe the company a reference. An unanswered email is not agreement.

3. Confirm the scope and contact details

When the customer agrees, check which contact details may be shared, which participants they expect, and whether any topics are off limits. The customer can choose a narrower conversation than the requester originally wanted.

Keep internal account notes separate from the introduction. A useful brief contains the approved topic and logistics, not unrelated commercial details or private customer information.

4. Make a specific introduction

Hi [customer] and [requester],

Thank you both. [Customer] has agreed to discuss [approved topic] with [requester]. The proposed conversation is [duration], and [scheduling owner] will coordinate a time.

The focus is [question one] and [question two]. [Relevant boundary, if agreed].

I will leave the conversation with you and follow up afterward on any agreed next step.

Verify every recipient before sending. If the customer's scope or availability changes, update the introduction plan rather than keeping an outdated promise in motion.

5. Use a reference coordination board

RequestCustomer permissionApproved topicScheduling ownerStatusNext action
Requester and reasonPending / Agreed / DeclinedExact scopeNameResearch / Asked / Coordinating / Completed / ClosedAction and date

For a hypothetical example, an investor might ask about implementation. A customer willing to discuss onboarding but not commercial terms should receive an introduction limited to that scope. This is a process illustration, not evidence of a customer result.

Afterward, thank the customer. Record whether the conversation happened and what follow-up was explicitly agreed. Do not create a testimonial or marketing quote from private feedback without separate permission.

Give Aurora a useful preparation job

Use this assignment with the approved context:

Prepare a customer-reference coordination brief from these notes. Identify the requester's question, relevant customer experience, relationship owner, permission status, and unanswered logistics. Draft a permission request, not an introduction. Do not infer consent, add private account details, or send anything. Return the brief and a review checklist.

Aurora can work with the context you provide and supported connected sources. Finta CRM helps keep people, relationship context, and next actions together. You review the brief, approve messages, and decide whether the reference should happen.

Check the result and close the loop

Before marking the request complete, verify permission, participants, scope, the actual conversation status, and the owner of any follow-up. If the customer declined or the request no longer matters, close it cleanly.

For general preparation, use the meeting-prep workflow. Keep the broader follow-up workflow separate from the permission decision: a reference request needs its own consent and scope, not just another scheduled touchpoint.