Sales wants a reference call. Marketing wants an interview. An event team wants a speaker. Each request may be sensible on its own, but the same customer can receive all three without anyone seeing the combined burden.
A reference-request queue gives a customer-marketing team or its agency one place to choose the next appropriate ask. Its purpose is to coordinate existing customer relationships, not to build a fresh prospecting list. The output is a decision for each request: proceed, clarify, use an existing asset, hold or decline.
Separate the business request from the customer invitation
Start with the internal need. What question must the buyer, viewer or event audience understand? When is the reference needed? What form of participation is being requested? A one-to-one call, filmed interview and public speaking slot require different commitments.
Next establish who manages the customer relationship and what the customer has actually agreed to. A previous interview does not mean the customer has joined an unlimited reference pool. An account marked “happy” does not establish availability, willingness or permission for another public use.
As one documented company example, GitLab’s public programme handbook describes coordinating customer activities and approved references. Its specific process is not a universal service standard. The useful principle for your own queue is that requests should be visible together before another invitation is made.
Use a decision queue, not a popularity score
A large logo can dominate a numeric ranking even when the requested experience does not fit. Begin with a few eligibility questions: does the customer have relevant experience, is the relationship owner aware of the request, and is there permission to make this particular ask?
Then consider timing and burden. Record the last request, any current commitments and the customer’s stated preferences. An unanswered invitation is still an active request until you have dealt with it appropriately; do not send another message from a different team to get around it.
Keep “unknown” as a real status. It asks for a check. It should not receive a convenient middle score that allows the request to proceed automatically.
A completed request queue
Fictional exercise: a SaaS team has three internal requests and two customers with relevant experience. The names, permissions and timing are invented solely to demonstrate the decisions.
| Request | Fit and relationship check | Customer capacity | Decision |
|---|---|---|---|
| A buyer asks how a regional team handled onboarding | Customer A has described that exact rollout; relationship owner is aware | Customer A has an unanswered interview invitation this week | Hold the new call request; ask internally whether an existing approved passage answers the question |
| A writer needs a process interview about handovers | Customer B took part in that process; permission to invite is confirmed | No other request is recorded; availability is still unknown | Relationship owner may make one specific invitation; do not mark an interview booked |
| An event wants a speaker on international expansion | Neither customer’s recorded experience establishes that topic | Not assessed because topic fit fails first | Decline these nominations and clarify the experience required |
This queue does not claim that Customer B is more valuable than Customer A. It identifies a relevant next check and prevents the second team from treating an unanswered invitation as an empty calendar.
Make the participation request concrete
Before inviting the customer, agree what you would ask them to do. Include the format, expected preparation, proposed duration, intended audience and how publication review would work. Let them decline or suggest a smaller form of participation.
For the fictional process interview, the internal request is one conversation about the customer’s own handover experience, followed by a review of proposed publication wording. It is not also a commitment to appear at an event, approve advertising or answer future sales calls.
If availability is uncertain, record the uncertainty and avoid building an externally promised delivery date around it. A customer agreeing to consider the invitation is different from accepting a time and scope.
Use an existing asset when it answers the question
The queue should allow a request to end without another customer interaction. A relevant, approved story passage may answer the buyer’s question. A recorded explanation might support a sales conversation if that use is permitted and its context remains clear.
Check what the asset actually says, rather than forwarding the nearest industry logo. Use the coverage audit to find a relevant passage. If adapting it, follow the sales-asset handoff so a shortened excerpt does not overstate the original account.
Review the request history with the relationship owner
Record the invitation, response, agreed next action and closure in the same queue. A refusal closes that request; it is not an instruction to try a colleague or another channel. Respect any broader preferences the customer communicates through the relationship team.
Use the approval map before a public reference is released. Track participation and permission separately: someone may agree to speak privately but decline a named quotation. A well-run queue helps the team meet a genuine information need while leaving the customer in control of whether and how to participate.