This page is about the paperwork. Which work you bill and which agreement covers it is mapped in how to separate paid IT work from a referral arrangement; here the subject is where each sentence about a referral is written down, who can read it later, and how to fix a note that landed in the wrong place.
Where a ticket note can surface after you press save
A ticket note outlives the conversation that produced it. Before anyone types a referral line into one, look at where that line can travel.
| Where the note can surface | Example from vendor documentation | Who might read a referral line there |
|---|---|---|
| The client's self-service portal | In ConnectWise's classic PSA ticket documentation, Discussion notes can be viewed by customers in the Customer Portal, and so can the Resolution field (paraphrase) | Any client user with portal access, including staff the CEO has not told |
| The client's invoice | The same documentation says Discussion notes may print on an invoice, depending on the invoice template (paraphrase) | The client's finance team |
| A public reply by default | Zendesk says an agent's comment is public unless an admin changes the default (paraphrase) | The requester and anyone copied on the ticket |
| An internal note | Zendesk hides internal notes from requesters and end users while agents can still read them (paraphrase); ConnectWise keeps Internal notes off the portal and invoices (paraphrase) | Every agent on the ticket; in a helpdesk the client owns, that includes the client's staff |
| The ticket history itself | Tickets stay as long as the retention rules keep them; how long companies keep support tickets covers the range | Whoever reviews or receives that history later, such as a new provider if the client moves |
ConnectWise
ZendeskInternal notes reduce the audience; they do not remove it. And a ticket is the client's service record, kept under the client's retention choices. A sentence about your firm's possible reward has no business there, however hidden the field.
How a referral thought lands in a ticket
The slip rarely starts with a referral. It starts with ordinary work and an honest habit of writing everything down.
- A technician notices history. During a migration someone sees fourteen years of resolved tickets and types "huge archive, could be worth something" into the work notes.
- The client raises it in a ticket. An operations manager adds a line to a storage request: "Could we sell this old data?"
- A business review is logged as a ticket. The account manager records the quarterly meeting, including the side conversation about SourceX, as a service ticket because that is where meeting notes always go.
- Email turns into tickets. A reply to the client's CEO about the program is copied into the ticket system by an email-to-ticket rule.
- Time entries tell the story. "30 min: discussed data licensing with COO" lands in a time entry that feeds the invoice.
The person who raises the idea, often an operations manager or a COO, can sponsor it inside the company. The CEO decides whether the company discusses licensing at all, and SourceX's screening page lists an introduction the decision maker never heard about among the usual poor fits. So the first written trace of the idea should be a neutral handoff, not a summary of the opportunity.
The separate-workflow documentation guide
Three parts: a rule for what goes where, the fields of the referral log, and the lines technicians use when the topic appears in their queue.
Part 1: one sentence, three possible destinations.
| Information | Service ticket | Referral log | Written nowhere |
|---|---|---|---|
| The service work itself: what was fixed, migrated or configured | Yes | No | No |
| That the client asked a question outside the service scope | One neutral line, no detail | Yes, with the date | No |
| The CEO's name and their dated, written yes | No | Yes | No |
| Your firm's possible reward | No | Yes, as disclosed to the CEO, with the date | No |
| Introduction method and time of submission | No | Yes | No |
| Status updates from SourceX | No | Yes, in generic stages | No |
| Record counts, storage sizes, screenshots, sample files | No | No | Yes, never recorded |
| Customer names, credentials, value guesses | No | No | Yes, never recorded |
Part 2: the referral log, field by field.
| Field | What to write | Where the entry comes from | Why it is there |
|---|---|---|---|
| Reference | A code such as REF-07, never the ticket number | You | Keeps the log from pointing back into client systems |
| Company and domain | Legal name and web domain | Public sources or the CEO | Section 3.3 of the partner agreement sample lists both for each introduction record |
| Decision maker | The CEO's name and the date and form of their yes | The CEO's own email | The decision belongs to the CEO |
| Disclosure | Date you told the CEO about your possible reward | You | A record that the CEO heard it before saying yes |
| Fit facts | Each fact as the CEO stated it, marked "CEO said" | The CEO | Peak full-time headcount of 50 or more, contractors excluded; years of records; rights; who decides |
| Earlier contact check | Date you asked whether anyone at the company had contacted SourceX, and the answer | The CEO | A company with an earlier application, lead, account or email thread is a duplicate |
| Agreement | Who at your firm signed the SourceX Channel Partner Agreement, and when | You | Signing comes before any submission |
| Introduction | Method and timestamp | You | Attribution is decided from dated records, and an oral introduction must be confirmed in writing (sample, section 1.2) |
| Stage | Generic stages only: introduced, applied, in review, closed or ended | SourceX updates | Section 4.6 of the sample describes generic stages or reference codes for partner updates |
| Next action | One dated step | You | Keeps the log from going stale |
The log holds sentences, never data. Section 4.4 of the sample bars a partner from collecting or retaining supplier dataset copies through the program without separate written authorization, and partners never see, upload or handle a company's records, inventory or data room in the first place.
Part 3: what a technician writes when the topic appears.
| Situation in the queue | Line for the ticket (Illustrative) | Then |
|---|---|---|
| The client asks about selling or licensing data | "Client raised a question outside the service scope; passed to the account lead." | Message the account lead outside the ticket system |
| You notice a long archive during a migration | Nothing beyond the migration facts | Tell the account lead in person or by direct message, without numbers |
| A client user asks for an export "for SourceX" | "Export request outside the service scope; passed to the account lead." | Do not run it; the account lead routes it to the CEO |
Who keeps which record, and for what
Three parties each keep their own record, and none should borrow another's.
- The custodian, your firm, keeps the service record: tickets, change logs and time entries, all of it the client's service history. It also keeps the referral log, which is about your own introduction and nothing else.
- The customer owner, the company, keeps its own decision trail: the CEO's correspondence, its application to SourceX and any agreements it signs. It describes its own systems when it applies.
- SourceX keeps the attribution record. Paragraph 8 of Schedule A in the sample says SourceX retains dated introduction evidence and attribution decisions, among other records.
A referral line in a portal-visible note (Illustrative)
Illustrative. The firm, client and people are fictional, and no outcome is implied.
A technician at an MSP finishes a file-server retirement for a 210-person engineering firm and writes in the ticket's Discussion note: "COO keen on licensing old project data to SourceX, roughly 40k tickets in the helpdesk too, nice reward for us if it lands." The client's office manager reads it in the portal the next morning.
The repair takes one afternoon:
- The technician tells the account lead the same day. No blame; the habit was reasonable and the field was the wrong one.
- The account lead tells the client's CEO what was written, and where, and explains the program and the possible reward in the same message, because the CEO is now hearing about it second-hand.
- The note is corrected the way the client prefers. Whether to edit, redact or leave the note and add a correction follows the PSA's permissions, your firm's records policy and the client's instruction. If the client or your firm is under a legal hold or a retention duty, ask counsel before changing anything.
- Only what the CEO confirms moves to the referral log. The 40,000 figure does not move anywhere: it came from the helpdesk, not from the CEO.
- The team rehearses Part 3 at the next stand-up.
The CEO asks for an introduction a week later. Nothing from the ticket travels with it.
Introduce the owner from the log, never from the ticket
Build the introduction from the log's fields and nothing else: the company, the CEO and the fact that the CEO asked to be introduced, your disclosed interest and your contact details. Leave out counts, systems data and any view on fit, rights or value; the company describes its own records when it applies, and SourceX decides fit and rights in its review. Submit only after the earlier-contact check and after your firm has signed the partner agreement. For the record types an MSP sees most, MSP ticket data and whether an MSP can share client ticket data cover the rights side.
Where a separate log is hard to keep
- One-person shops. If the owner is also the technician, the discipline is the same; only the two-person rule shrinks to one.
- The client's own helpdesk. When you work as an agent in the client's system, every internal note is the client's, and the client's admins can read it.
- Automation. Email-to-ticket rules and meeting-note integrations can copy a referral conversation into tickets without anyone choosing to. Send program emails from an address those rules do not capture.
- Ticketing replacements. Old notes travel with migrated history; the ticketing platform replacement guide covers what moves.
- No published data. Nobody has measured how often referral lines end up in tickets. Count your own: notes found, fields involved and time to repair.
The partner overview is on the managed service providers page, and more playbooks sit in the guides library.
Next step
Refer a company. No cap on rewards. Default reward on a company's first qualifying transaction: the greater of $50,000 plus 5% and 15% of Actual Supplier Payout, with no cap; further qualifying transactions first agreed within 12 months of the first Closing pay 15%. Eligibility and payment conditions apply, including the USD 100,000 Minimum Transaction, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
Once your referral log lives outside every client system and its first entry is the CEO's written yes, open a partner account, compare the company with the published fit criteria and go through the program terms; only then does the introduction leave your log.