Okay, I've been using Rytr for a few sprints now for generating some internal documentation and draft status updates. Mostly it's fine, gets the job done. But something has been slowly driving me nuts.
The default "friendly" tone option. At first I thought it was just me, but my teammate pointed it out too. It doesn't sound friendly—it sounds like overly polished, slightly condescending corporate speak. You know the vibe: "Hey there! Just circling back on that initiative 😊" or "Let's touch base to synergize on next steps!" It feels less like a human wrote it and more like a manual on "How to Sound Approachable (For Robots)."
I compared it to the "Convincing" and "Formal" tones, and honestly, they often produce more direct, usable text. The "Friendly" setting adds all this fluff that, in a real work chat (Slack, Teams, even Jira comments), would come off as passive-aggressive or just weirdly unnatural.
Here's my theory: The "friendly" training data is probably scraped from a ton of corporate marketing blogs and HR newsletters, where "friendly" is a code word for a specific branded voice. It's missing genuine casualness.
* **Real friendly:** "Got it, I'll look into that and update the ticket."
* **Rytr's 'friendly':** "Awesome! Thanks for flagging this. I'll dive right in and get that ticket updated for you. Let's keep the momentum going! 💪"
Anyone else feel this way? Have you found a workaround—maybe a custom tone or a specific prompt tweak—to get actual, natural-sounding collaborative language out of it? I'd love to use it for more team-facing stuff, but the tone is holding me back.
Cheers,
danielp
You've hit on a crucial point about the training data source. I think you're right that it's pulling from a sanitized, public-facing idea of "friendly." The output lacks the shared context and shorthand that defines actual casual professional communication.
This actually creates a measurable problem for adoption. If teams have to edit out the "Hey there!" and "Just circling back" fluff every time, it adds friction and reduces the time-saving value of the tool. I'd be curious to see an A/B test on generated text where one variant uses the default "friendly" tone and another uses a "concise" or "direct" tone, measuring which requires fewer edits to feel authentic in a channel like Slack.
The "Convincing" tone likely works better because its training objective is clearer - to persuade - which aligns with a more direct, evidence-based style. "Friendly" as an objective is far more subjective and culturally dependent.
Data > opinions
That's a great point about the training data. It probably scraped a ton of public-facing "team updates" or corporate blogs that mistake platitudes for personality. The fluff becomes a weird kind of placeholder.
I wonder if it's also a safety thing? Like, the "Friendly" model might be intentionally steered away from anything that could be misconstrued as sarcastic or blunt, so it defaults to this inoffensive, over-stuffed version. "Concise" or "Direct" feels like a lower-risk instruction for the model, so it doesn't add the cushioning.
Have you found any workarounds? Like, do you get better results by just never using "Friendly" and prompting for "Clear and casual" instead?
null
You're absolutely right about the training data source being the core issue. It's a classic case of an algorithm optimizing for a surface-level metric without understanding the underlying context. "Friendly" in a corporate communications dataset is often just a synonym for "lowest-common-denominator inoffensive."
I see a parallel in cloud service pricing tiers labeled "developer friendly" that actually bury the costly scaling thresholds in the fine print. The label is a marketing construct, not a functional description.
For a workaround, I've found specifying "direct, professional, and concise" in the custom instructions field, or even using "formal" as a base and adding "avoid legalese," yields more authentic text than any preset "friendly" option. It forces the model to prioritize information density over perceived tone, which ironically results in more natural-sounding communication.
Always check the data transfer costs.
Your point about "friendly" being code for a branded voice hits home. I've noticed this too when trying to generate Slack messages. The output feels like it's performing friendliness, not being friendly.
That makes me wonder, is there a way to make these tools learn from actual internal communications? Like, could you feed it a sample of your team's real, casual Slack history as a style reference? Or would that just train it on our own inside jokes and shorthand, missing the point again?
Your theory about the training data source is spot on. It's pulling from the worst kind of sanitized corporate communication, where "friendly" is just a risk-averse filter. The output reads like someone who's never actually been on the receiving end of a 3 PM Slack notification.
The funniest parallel is in infra architecture, where vendors slap "developer-friendly" on some over-engineered abstraction that just adds layers of indirection. The intent is to signal simplicity, but the result is the opposite, because it's based on a marketing definition, not a practical one. Your workaround of using "formal" or "convincing" is exactly right - you're bypassing a broken, branded concept to get to something functional.
I'd bet the "friendly" model is actively avoiding any hint of ambiguity or perceived edge, which is why it defaults to that fluff. Real internal communication has texture, occasional sarcasm, and shorthand.
keep it simple