The partnership one-pager that gets a meeting

You want a meeting with a bigger platform's partnerships team. So you write to them. The message is a warm paragraph about how much you admire their product, a line about how you think there is a great fit, and an ask for thirty minutes to explore it. It gets no reply, and you assume they are busy. They are busy, but that is not why they passed. They passed because nothing in your message answered the only question a partner manager asks when a stranger requests time: what is in this for us, specifically, and can you prove it in ten seconds.

A partnership one-pager is how you answer that question before you are in the room. It is a single page, built for the partner's interest rather than yours, that a partner manager can scan in under a minute and forward to a colleague without adding context. When it works, the reply is not "tell me more," it is "let's find time." That is the whole job of the page: convert a cold ask into a booked meeting.

This guide is the deep version of that page. We cover what a partnership one-pager is and how it differs from a sales one-pager, the shared-customer hook that does most of the work, exactly what goes on the page and what good looks like for each part, the difference between a page written for the partner and a generic pitch, the outreach around it, and a copyable template you can lift into your own. At the end you get a template card you can fill in this week.

The 60-second version

If you only read one section, read this one:

• A partnership one-pager exists to get a meeting, not to close a deal or explain your whole product. Judge every line by whether it moves a partner manager toward "let's talk."
• The shared-customer hook does most of the work. Lead with the customers you both serve and the problem you solve for them together, because that is the fact a partner manager cannot ignore.
• Write it for the partner's interest, not yours. A page about what you get from the partnership reads as a favor request. A page about what the partnership does for their customers and their platform reads as an opportunity.
• The page has a knowable structure: a headline that names the joint value, the shared-customer hook, the integration in one line, three proof points, what you are asking for, and how to reach you.
• Concrete beats comprehensive. One named workflow with a real result outperforms a feature list every time.
• The generic version is the failure mode. A one-pager you could send to any partner by swapping a logo is a one-pager none of them will act on.
• The page is the start of a sequence. It rides on a short outreach note and leads to a first call, so build all three to work together.

What a partnership one-pager is, and what it is not

A partnership one-pager is a single page whose only goal is to earn a meeting with a potential partner. It is the artifact you attach to an outreach note, hand to a partner manager you met at an event, or send when a warm introduction asks "what should I forward them." It compresses your case for working together into something a busy person can absorb in the time it takes to read an email.

It is worth being precise about what it is not, because the most common mistake is writing the wrong document. A partnership one-pager is not a sales one-pager. A sales one-pager sells your product to a buyer; it leads with your features and your value to the end customer. A partnership one-pager sells a relationship to another company; it leads with what the two of you can do for a shared customer that neither does alone. Point the sales one-pager at a partner manager and they will read it as noise, because it answers a question they did not ask.

It is also not a pitch deck, a data sheet, or your homepage printed to PDF. A deck needs you in the room to narrate it. A data sheet is reference material for someone already interested. Your homepage is written for your buyer, not a partner. The one-pager is a standalone object that has to work with nobody there to explain it, which is a higher bar than any of those three clear on their own.

The mindset that makes the page work: it is not a description of your company, it is a proposal aimed at one reader with one job. That reader evaluates partnership opportunities for a living, sees dozens of these, and forwards almost none. Write the page for the moment they decide whether to forward it.

The shared-customer hook: the fact a partner manager cannot ignore

If you get one thing right on the page, make it the hook. The shared-customer hook is the opening claim that names the customers you and the partner both serve and the problem you solve for those customers together. It is the single most persuasive thing you can put in front of a partner manager, because it reframes the conversation from "a stranger wants something" to "there are customers we are both already serving who have a gap between us."

The reason it works is that a partner manager's job is to find partnerships that help the platform's own customers and expand its footprint. A shared-customer hook does that arithmetic for them. When you can say "hundreds of your customers in the mid-market segment are also trying to solve X, and today they stitch it together by hand," you have not asked for a favor, you have surfaced a problem the partner has a selfish reason to fix. The meeting is now about their customers, not your ambitions.

A strong hook has three parts: the shared audience, the shared problem, and the evidence that the overlap is real. The evidence is what separates a hook from a hope. "We think there is overlap" is a guess. "We have twelve mutual customers who asked us to integrate with you" is a fact that books a meeting. Even when you cannot name accounts, you can point to the pattern: a segment you both target, a workflow that spans both products, a support request you both field.

The hook is a small application of a broader idea. It is the joint value proposition, compressed to its opening line and aimed at a partner manager rather than a seller. If you have not written that underlying story yet, our guide to the joint value proposition is the place to build it, and the one-pager becomes the one-page expression of it. For the wider concept of a value proposition as a standalone claim, the Wikipedia entry on value proposition is a useful primer.

What goes on the page, and what good looks like

A partnership one-pager is short by definition, so every element has to earn its place. The structure below is the full inventory. On a real page it fits on one side, which forces the discipline that makes the page work: if a line does not move the reader toward a meeting, it does not belong.

Headline: the joint value in one line. The top of the page states what the two products do for a shared customer together, in a single sentence a partner manager could repeat. Good looks like naming the outcome, not the integration. "Push your design assets straight into production without a manual export" beats "an integration between our platforms." The headline is the page in miniature; if a reader stops after it, they should still know why to care.

The shared-customer hook. The opening claim from the previous section, stated with evidence. Good looks like a specific audience, a specific problem, and a fact that proves the overlap is real. This is the paragraph that earns the rest of the read.

The integration or partnership in one line. A plain sentence describing what actually connects the two products or what the partnership would do. Good looks like concrete and buildable, not aspirational. A partner manager needs to picture the thing, not admire the vision. If the integration does not exist yet, say what it would be in one sentence and move on.

Three proof points. The evidence that you are a credible partner and this is a real opportunity: a customer result, a relevant logo or two, a usage number, a shared customer who asked for this. Good looks like three concrete facts, not a wall of claims. Three is the number because a partner manager scanning the page will register three and forget ten.

The ask. Exactly what you want to happen next, which is almost always a short meeting. Good looks like a specific, low-friction request: a thirty-minute call to explore fit, not "a strategic partnership." The smaller and clearer the ask, the more likely the yes. A vague ask makes the reader do the work of deciding what you want, and they will not.

Contact and next step. Who to reply to and the single link that lets them act. Good looks like one name, one email, and at most one link to a page that backs the pitch, such as an integration or partner page. Do not bury the next step under five links; make it obvious.

A note on what to leave off. Your funding history, your full feature list, your origin story, and a second and third integration idea all belong somewhere, but not here. The page is a lever to get a meeting, and every extra element is weight on the wrong end. When you are tempted to add something, ask whether it moves the reader toward "let's talk." If not, cut it. The discipline of a single page is the same discipline that makes a good executive summary work: it forces you to lead with the point.

Written for the partner versus generic: the difference that decides everything

Two one-pagers can contain the same elements and land completely differently. The one written for the specific partner gets a meeting. The generic one, the page you could send to any platform by swapping the logo, gets ignored. The difference is not polish, it is whether the reader can tell you did the work of understanding their customers before you asked for their time.

A generic page talks about your product and gestures at synergy. A page written for the partner talks about the partner's customers and names the specific overlap. The tell is the hook: a generic hook says "companies like yours could benefit," which is true of everyone and therefore persuasive to no one. A specific hook names the partner's segment and a problem their customers actually have. A partner manager reads the first as a template and the second as a message meant for them.

This is the same principle Nielsen Norman Group has documented for decades about user-centered design: the artifact that works is the one built around the reader's needs rather than the author's, and you learn those needs by looking at real behavior rather than assuming it. Their piece on why you should not simply ask users what they want makes the point that stated preferences and real behavior diverge, which is why the specific evidence in your hook, what shared customers actually do, beats any claim about what they would like.

Making the page specific costs an hour of research per partner: who their customers are, where your products overlap, and whether any accounts already use both of you. That hour is the highest-leverage work in the whole outreach. A specific page to ten partners beats a generic page to a hundred, because the specific page gets read and forwarded and the generic one gets archived. If you are still deciding which partners deserve that hour, our guide to sourcing technology partners covers how to build and prioritize the list before you write a single page.

The outreach around the page

A one-pager does not travel alone. It rides on a short outreach note and leads to a first call, and the three have to work as a sequence. A brilliant page attached to a bad note never gets opened, and a page that earns a meeting but hands off to a rambling call wastes the yes you worked for.

The outreach note is three or four sentences, not a cover letter. It states the shared-customer hook in one line, says you have attached a one-pager, and makes the ask. The note's only job is to get the page opened; the page's only job is to get the meeting. Do not repeat the whole page in the email, and do not make the reader open an attachment to find out why you wrote. Put the hook in the first sentence of the note so it lands even in the preview pane.

When the page works and the meeting is booked, the next artifact is the first call, and that call has its own discipline: an agenda that qualifies fast so neither side wastes the time. We cover that call in depth in the first partner call: an agenda that qualifies fast. The one-pager and the call are two halves of the same motion: the page earns the meeting, the agenda makes the meeting count.

One practical rule ties the sequence together: every step should make the next step easier. The note's hook previews the page. The page's ask names the call. The call's agenda references what the page promised. When the three are consistent, the partner manager experiences a coherent, low-effort path from cold to meeting, and coherence is itself a signal that you will be an organized partner to work with.

Common mistakes, and the fix

Sending a sales one-pager to a partner manager. The fix: rewrite the page around the shared customer, not your features. A partner manager does not buy your product, they evaluate whether working with you helps their customers and their platform. Lead with that or you answer a question they never asked.

Leading with what you want. The fix: open with what the partnership does for the partner's customers, and put your ask near the end. A page that opens with "we would love to partner with you" reads as a favor request. A page that opens with a problem their customers have reads as an opportunity you are handing them.

Going generic to save time. The fix: spend the hour to make each page specific to the partner's customers and the real overlap. A page you could send to anyone persuades no one. The research that makes it specific is the work that makes it land.

Cramming in everything. The fix: cut to the six elements and hold the line at one page. Your funding, your full feature list, and your second integration idea all pull the reader away from the only decision that matters, which is whether to take the meeting.

Making the ask big and vague. The fix: ask for one specific, low-friction thing, almost always a thirty-minute call. "Let's explore a strategic partnership" makes the reader define what you want. "Thirty minutes to look at the accounts we share" is a yes they can give in one click.

FAQ

What is a partnership one-pager? It is a single page whose only goal is to earn a meeting with a potential partner. It leads with the customers you and the partner both serve and the problem you solve for them together, then adds a one-line description of the integration, three proof points, a specific ask, and how to reach you. It is built for a partner manager to scan in under a minute and forward without adding context.

How is it different from a sales one-pager? A sales one-pager sells your product to a buyer and leads with your features and end-customer value. A partnership one-pager sells a relationship to another company and leads with what the two of you do for a shared customer that neither does alone. Sending the sales version to a partner manager answers a question they did not ask.

What is the shared-customer hook? It is the opening claim that names the customers you and the partner both serve, the problem you solve for them together, and the evidence that the overlap is real. It works because it reframes your outreach from a favor request into a problem the partner has a selfish reason to fix, since helping shared customers expands their platform.

How long should it be, really? One page, and one side of it. The constraint is the point: a single page forces you to lead with the joint value and cut everything that does not move a partner manager toward a meeting. If it runs to two pages, you are writing a data sheet or a deck, which is a different document for a different moment.

What if the integration does not exist yet? Describe what it would be in one sentence and lead with the shared-customer evidence instead. A partner manager will take a meeting about a valuable integration that is not built yet if the shared-customer case is strong. What they will not do is take a meeting on the strength of an integration nobody has asked for.

How specific do the proof points need to be? Specific enough to be checkable: a named customer result, a real usage number, mutual customers who asked for this, a recognizable logo. Three concrete facts beat ten vague claims, because a partner manager scanning the page registers a few strong signals and discounts a wall of adjectives.

What do I attach it to? A short outreach note of three or four sentences that states the hook and makes the ask, with the page attached. The note gets the page opened; the page gets the meeting. Put the hook in the first sentence of the note so it lands in the preview, and keep the whole sequence, note, page, and first call, consistent.

Further reading

• Wikipedia, value proposition, on the underlying concept the one-pager compresses to its headline.
• Wikipedia, executive summary, on the discipline of leading with the point in a short document.
• Wikipedia, elevator pitch, on compressing a case to the few seconds a busy reader gives it.
• Nielsen Norman Group, the first rule of usability: don't listen to users, on why real behavior beats stated preference, which is why specific evidence outperforms a generic claim.

The short version

A partnership one-pager exists to do one thing: get a meeting with a potential partner. It works when it is written for the partner manager's interest rather than yours, which means leading with the shared-customer hook, the customers you both serve and the problem you solve for them together, backed by evidence that the overlap is real.

Build the page around six elements: a headline that names the joint value, the shared-customer hook, the integration in one line, three concrete proof points, a specific and low-friction ask, and one clear next step. Make it specific to each partner rather than generic, because the specific page gets forwarded and the generic page gets archived. Then attach it to a short outreach note and let it hand off cleanly to a first call, so the whole sequence moves a partner manager from cold to booked.

If you want the whole path handled, from partner strategy and a partner-ready API through the shipped integration, the enablement kit, and the outreach that gets meetings, that is exactly what a Partner Audit is for. We review your product, API, and partner potential, then define what to build, who to approach, and how to ship and sell it together.