Business subscription (part-time vs full-time) context

[jayeclark]

When a business on a part-time subscription starts a conversation with a developer who is interested in part-time contract, full-time contract, OR full-time employment, it's not clear to that business that they are on a part-time subscription plan or that they are expected to only be reaching out to candidates about part-time or contract work.

This was discussed a bit in a Twitter thread in terms of Businesses trying to 'game' the system. I think it might be happening due to confusion rather than malicious intent. Unless a business attempts to reach out to a person who is only interested in full-time employment, they don't receive any contextual clues that they're not supposed to discuss full time work with the developer.

It feels reasonable that someone who likely has multiple subscriptions to multiple different hiring tools, after even just a day or two might not remember what plan they originally signed up for.

Here's a screenshot of what a part-time subscriber sees when starting a conversation with a developer interested in all types of roles. I have no context clues that I should only be reaching out about contract work.

I only know what plan I'm on when I go to Billing, but even then it's not clear that I'm not 'allowed' to talk about full-time employment with someone. Only the plan name is shown, not the description of the plan. I could easily interpret/misremember "part-time hires" as "I'm only occasionally looking to hire people."

The only time I learn that I might be doing the wrong thing by discussing full time employment is when I try to reach out to a developer who is ONLY interested in full time employment.

It feels like as a business subscriber I should have some context in the "start a conversation" flow that reminds me I should only be asking about contract work. It might be as simple as adding checkboxes for the three roles to cold message form - the full time employment checkbox would be disabled if the business has only a part time subscription. Something like this:

Thoughts @joemasilotti ??

[joemasilotti]

Thanks for bringing this up and documenting, @jayeclark! There's definitely some work to be done – and the green checks at the top only tell one side of the story.

From my perspective we need to address two different issues:

1. A consolidated screen to explain what plan someone is on and what permissions they are entitled to.
2. Reminding them of said permissions when (cold) messaging a developer.

Account page

Currently, if you have a Stripe account you can visit the Billing link from the user dropdown. As you outlined, this redirects you to manage your Stripe account.

Instead, I'd like to rename this to Account and render a screen on railsdevs with:

• The current plan
• When the plan expires (if cancelled) or renews (if active)
• A list of past expired plans, if any
• The permissions of said plan (who they can message)
• A link to Stripe to manage their billing information (where Billing goes now)
• Stretch goal: a button to upgrade their plan from part-time to full-time that takes them to a checkout-like page

Cold message form

I love the idea of asking the business what type of role they are hiring for. It makes it more obvious what you are allowed to do. It also provides a nice little CTA to entice them to upgrade if needed.

Enforcing one or more of these to be checked in the form validation sounds ideal to me. It ensures the business completely understands their plan level and slows down the outreach. We could even align the checkboxes with what the developer is looking for to ensure someone isn't contacted for a role type they aren't interested in.

But why is slowing down the initial outreach a good thing? In my opinion, it further enforces the idea that each of these messages should be genuine, organic, and specific to the developer. If a business complains about having to check an additional box then maybe they are sending a copy-pasted message to too many folks.

Next steps

I'm going to review some Tailwind UI screens and see if any could be used or tweaked to accomplish these two features. Once I have that I'll post some mockups here. From there I'll create two or three issues and we can start the work!

[joemasilotti]

On second thought, I'd love to see/hear ideas for how the two screens should be laid out! I'm having trouble coming up with something that works for the Account page, to be honest.

[jayeclark]

@joemasilotti I can mock up a few to get the discussion started - I have employer accounts on several hiring platforms (most of them dormant at this point, but I think there should still be a few that are active due to being prepaid for the year) so have some good existing flows to pull from.

---

I agree about the slower form being a good thing. It’s one or two or three clicks, not a huge deal and will slow down any potential spamming.

I’m not well-versed yet in the form customization options in Rails but I’d assume there is a way to set it up to validate in real time (ie prompt the Business to check one of the boxes & disable the send button if the Business starts writing a message without indicating what type of role(s) they’re offering.)

[joemasilotti]

That would be amazing, thank you!

Let's stick to model-level validations that return a custom error message for now. We can always layer on JavaScript-powered form validation in the future.