Skip to content

Jooble partnership — draft outreach (NOT SENT)

Status: DRAFT for Andrew's final say. Worth a read from Pam or David P before it goes. Nothing has been sent. It would be a reply to Jooble's key-issue email, which invited exactly this:

"If you want to increase the number of requests or have other questions, please write to us in response to this letter."

Reply-to: the inbox that received the key. From: whoever owns the relationship — this should come from a person, not an alias, if it is going anywhere near a partnership conversation.

What we are actually asking for, and what we are not

Not asking for: a bigger free tier for desktop users. Work Wingman's desktop edition is BYOK — each user brings their own Jooble key, and the free 500-request budget is roughly a whole job hunt for one person. Desktop needs nothing from Jooble.

Asking for: a workable arrangement for the CLOUD edition, where one key serves many users and 500 lifetime requests is not a starting point.

Leading with the first half matters. It says we understand their cost model and are not asking them to subsidise our entire user base.

What we can offer that nobody else in their chain can

Jooble sees an outbound click and nothing after it. So does every aggregator. Work Wingman drives the application itself, so it is the only party in the chain that knows whether a click became a submitted application.

That is real evidence they can take to their own supply partners — and we measured that their supply chain matters to them: their own source field shows listings arriving from rev.cpc.appcast.io, talent.com, and their internal PJA.J-VERS feeds.

Hard boundary, stated up front so it is never renegotiated under commercial pressure: aggregate only. Counts and rates, never a person's job search. "342 of 1,000 clicks became submitted applications" is a metric. Anything identifying an individual is the user's data, not ours to trade.

Draft

Subject: Re: Your API key is ready — Work Wingman, cloud edition volume

Hello,

Thank you for the key. We have integrated Jooble into Work Wingman, a job-application assistant, and I wanted to be straightforward about how we use it and where we would need something different.

Our desktop product is bring-your-own-key: each user registers with you directly and uses their own free allowance, which for one person's job search is comfortably sufficient. We are not asking you to change anything there.

Our cloud edition is the different case — one key serving many users — and the 500-request trial budget is not a starting point for it. I would like to understand what a commercial or partner arrangement looks like on your side.

What we can offer in return is unusual, and I think useful to you. Because Work Wingman assists with the application itself, we know whether a click became a submitted application — not just that someone clicked out. We would be glad to share that back as aggregate conversion reporting on traffic we send you: click-to-application rates by role category, in aggregate only, never individual user data. As far as we can tell, no one else in the chain can tell you that, since visibility usually ends at the outbound click.

One thing we appreciated while integrating: your source field. Being able to see which board a listing originated from is genuinely useful, and it is not something every aggregator exposes.

If there is a partnerships contact who is the right person for this, I am happy to be redirected.

Best regards, [name, title] Work Wingman

Notes for whoever reviews this

  • Tone deliberately not salesy. They invited the conversation; the job of this email is to be easy to say yes to, not to pitch.
  • The source compliment is genuine and load-bearing, not flattery. It saved us real work — Adzuna gave no equivalent, which is why answering "where do these links go" for Adzuna took a 250-page crawl and cost us an API suspension. Jooble states it per listing.
  • Do not promise a volume number we cannot hold to. The draft avoids "we will send you X clicks" on purpose.
  • Do not offer per-user data even if asked. If they push, the answer is aggregate or nothing.
  • Ask about rate shape, not just the total, if this progresses: 500 lifetime vs a daily/monthly allowance are very different to design against, and a per-user quota model would suit BYOK better than a single shared pool.

Talent.com — deliberately not approached yet

Their /publishers area is behind a login with no public API docs, so we cannot see terms or payload shape without an account. There is also a reason to think it is lower priority: talent.com appears as a SOURCE inside Jooble's own results, so some of its inventory would reach us through Jooble anyway. Worth measuring overlap before spending relationship effort there.