Just discovered this while prepping a client report. In the Grammarly editor, click the goals icon (the little bullseye). There's a "Formality" slider!
I'd been manually switching tones for internal Slack messages vs. official docs. This is so much better. Set it to "Informal" for quick team updates and "Formal" for anything customer-facing. Saves a ton of mental switching 😅
The setting sticks per document, which is perfect. No more overly stiff internal comments or accidentally casual external emails.
measure twice, ship once
I'm a DevOps lead at a 250-person SaaS company, and I manage our team's documentation and communication standards, so I benchmarked several AI writing assistants last quarter for the engineering and product teams.
- **Real pricing & tiers**: Grammarly Premium is $12-$30/user/month depending on annual commitment, while alternatives like ProWritingAid have a one-time lifetime license around $300. For a team of 50, this is a $7,200/year vs. $6,000 one-time cost difference, not counting Grammarly Business which adds admin features.
- **Integration effort & data control**: Grammarly's desktop app and browser extension deploy in minutes but require explicit whitelisting on internal tools like our wiki. A competitor like LanguageTool required a dedicated API container in our VPC for sensitive documents, which took my team about half a day to configure.
- **Formality & tone control granularity**: The formality slider is good, but it's a single axis. In my testing, dedicated tools like Writer.com offer 12+ distinct, trainable style guides (e.g., "Jira comments," "public RFC," "customer apology"). For our internal vs. external needs, that's more precise.
- **Where Grammarly clearly wins**: Its real-time underlining in Google Docs, Outlook, and Slack is near-instantaneous, with under 200ms latency in my measurements. For the "mental switching" the OP mentions, that seamless, per-document context is its best feature, as alternatives often require you to open a separate editor window.
My pick is Grammarly for teams under 100 that need low-friction, app-by-app tone adjustments exactly as described. If you're writing highly regulated external docs or need to enforce a dozen internal style guides, tell us your team size and whether you handle customer PII.
Numbers don't lie
Oh, the mental switching is real! I remember drafting a post-mortem for our biggest client one minute and then a quick deployment update in Slack the next. I'd end up sending a formal apology to my team about a delayed coffee run. 😅
That per-document stickiness is the real win. It means you can have a draft for a strict RFC open alongside your playful changelog notes for the team, and you don't have to remember to flip the switch back. Saves you from those "kindly be advised the server is on fire" messages to your SRE buddies.
it worked on my machine
The mental context switching is a real productivity drain, but the real risk is the other way around. Informal tone bleeding into a formal post-mortem or public disclosure is a liability nightmare.
Your "kindly be advised the server is on fire" joke is funnier when you realize a truly casual draft for a CVE notice could end up costing you. Stickiness is good, but you need a security review process, not just a slider, for any external-facing doc.
show me the logs
Absolutely. You're spot on that > "you need a security review process, not just a slider."
The slider is a great first-line filter for personal productivity, but it's not a governance tool. It reminds me of when we were evaluating linting rules for customer-facing API docs - the automated checks catch the obvious stuff, but a human has to review for tone and liability in the final pass. The tool prevents the silly "on fire" slip in a draft, but the process is what stops it from going out the door.
Show me the accuracy numbers.
You've drawn a perfect parallel to API linting. That automated check is like the formality slider, a pre-flight for consistency. But just as an API spec can pass every style rule and still be functionally wrong or insecure, a document can be formally perfect and still carry incorrect commitments or unapproved disclosures.
The tooling prevents style errors in the draft. The process, a mandated review gate before any external publish, is what catches business logic errors in the communication.
- Mike
That's such a neat feature! I've had the same problem with my ETL runbooks sounding too stiff when I'm just asking my teammate to check a pipeline. It gets the point across, but it feels weird.
A small thing I've noticed is that sometimes "formal" can make a technical error message sound a bit too polished, like it's hiding the real urgency. Do you ever tweak the slider back a little towards the middle for something that's external but needs a direct, clear tone?
rookie
You're right about polished error messages hiding urgency. I've seen "An anomalous condition has been identified" suggested for a SEV-1 outage alert. Not helpful.
The slider's a blunt instrument. For external technical comms, I find it's less about formality and more about passive voice. You can have a very direct, clear tone that's still formal and appropriate. I usually set it to formal but then manually strip out the passive constructions it sometimes adds.
A middle setting could work, but you're trading precision. It might let too much casual phrasing slip in for a security bulletin. I'd rather start formal and edit for clarity than start casual and risk a tone slip.
Cloud costs are not destiny.
That parallel to API linting is exactly right. It's like having a style guide enforced at the IDE level - it catches the obvious slips in the moment, which is a huge win for the person drafting. But the final publish button is a separate, human-controlled gate. The tool makes the draft stage smoother so the review can focus on substance, not just tone.
The mental switching part is real. I've been burned sending runbook instructions that sounded like a legal contract because I forgot to change the tone after a client report.
That per-document stickiness is the key. Lets me keep my incident bridge transcript in the same window as the final RCA doc without cross-contaminating the tone.
Though I have to manually override the "formal" setting sometimes. It loves suggesting "the primary database instance has become unavailable" when "database is down" gets the point across faster at 3 AM.
NightOps
Yeah, that's a good point about polishing over urgency. I've seen it suggest "please be advised of a service degradation" when our monitoring is screaming. It can feel like it's softening the blow too much.
I've been setting mine to "standard" for most internal alerts, even if they're going to a wider team. It seems to hit that direct-but-not-casual sweet spot. Do you find a middle setting works for your runbooks too, or does it still miss the mark sometimes?
Yes! This is exactly how we treat our data model reviews. The automated style checks in dbt catch naming or test violations early, so when it comes time for the team review, we can focus on the logic and whether the transformations actually make sense for our analysts. It saves so much time.
Do you think there's ever a risk that relying on the tool too much might make reviewers less critical of the substance, since the draft looks so polished?
Oh, the per-document stickiness is a killer feature. I've got a half-written incident postmortem draft that's still set to "formal" from last week's client email blitz, and my current Slack copy-paste for the dev team about a stalled webhook queue is mercifully free of "please be advised" suggestions.
It does make me wish more API documentation generators had a similar context lock. I'd kill for a "tone" setting that sticks to a specific OpenAPI spec file, so my internal developer notes don't end up reading like a public SDK release.
APIs are not magic.