You have a prompt that works. Maybe it's the one that turns a Google review into a response that doesn't sound like a hostage note. Maybe it's the one that rewrites floor plan descriptions so they stop saying "cozy" about a 512 square foot studio. It works because you know the fifteen things you're holding in your head while you use it.
Now hand it to the leasing manager at your lease-up in Nashville.
It breaks. Not spectacularly. It just produces something slightly off that she doesn't have the context to notice, and now there's mediocre copy on your website with your name adjacent to it. This is the wall between "I have a trick" and "my department has a capability," and most marketing teams never get over it.
Here's how you do.
What actually breaks when a prompt leaves your desk
Your prompt isn't a prompt. It's a prompt plus everything you know that you never wrote down.
You know the Nashville asset is in lease-up and can't sound desperate. You know legal killed the phrase "luxury living" last year. You know the regional hates exclamation marks and the ownership group has opinions about the word "home." None of that is in the text you typed. It's in you.
So when you share the prompt, you're sharing maybe 40% of the thing. The other 60% is judgment, and judgment doesn't paste.
The fix isn't a better prompt. It's turning the prompt into a tool: something with fixed parts your team can't break, and variable parts they have to fill in. That distinction is the whole lesson. Fixed parts carry your judgment. Variable slots carry their specifics.
The four-block structure
Every team tool you build has the same skeleton. Write it in this order.
Block 1: Role and constraints. Not "act as a marketing expert." Something like: "You write for a Class A apartment operator. You never use exclamation marks, never say luxury, never describe who should live somewhere, and never invent an amenity that isn't in the input." These are your rules, permanently baked in. Your team doesn't get a vote and doesn't have to remember them.
Block 2: The variable slots. Bracketed, obvious, and few. Property name, unit type, the actual review text, the concession being offered. If a slot needs explanation, put the explanation in the bracket: [MOVE-IN DATE, format: October 15]. Six slots is a lot. Ten and people start guessing.
Block 3: The output spec. Length, format, how many options. "Give me three versions at 40 to 60 words each, labeled A, B, C" beats "write some copy" every single time, because now your team can compare instead of accept. Accepting the first output is how AI content gets flat.
Block 4: The self-check. This is the block everyone skips and it's the one that makes the tool safe to hand over. "Before you output, confirm: no amenity appears that wasn't in the input, no sentence describes a type of person, and every claim can be traced to the source text. If any fail, fix it and output the corrected version."
Models are much better at catching their own mistakes when you ask them to look than at not making them in the first place. Cheap insurance.
Fair housing, and why this block is not optional
Ask a model to write about a two bedroom near a hospital district and it will happily produce "perfect for young professionals and busy nurses." It's not being reckless. It's pattern-matching on a million real estate listings that did exactly that, and a lot of those listings were violations.
The rule you hard-code into Block 1: describe the unit, the building and the neighborhood. Never describe the resident. "Two blocks from Baptist Health" is a fact about location. "Great for nurses" is a statement about who belongs there, and that is the category of language fair housing law is built around. Same for "perfect for young professionals," "ideal for a growing family," "quiet building, great for mature residents."
Put it in the constraints block and put it in the self-check block. Both. Your leasing manager in Nashville shouldn't have to know the law to stay on the right side of it. That's what the tool is for.
Where to put it so people actually use it
A tool in a Google Doc is a tool nobody uses. The friction of finding it exceeds the friction of just writing the thing themselves.
Pick one of these:
A Custom GPT or Claude Project. Best option if you have a paid team plan. You load the instructions once, add reference files (your brand voice doc, your banned words list, your amenity sheets), and the team just talks to it. No pasting. Name it something findable like "Review Responses" and not "Marketing AI Assistant v3 FINAL."
A prompt library in your CRM or wherever the team already lives. Second best. Works if your team is small and disciplined.
A saved prompt in a shared Notion or SharePoint page, pinned. Fine. Lowest effort, highest decay rate.
The single biggest predictor of adoption isn't quality. It's whether the tool sits inside a workflow someone already does daily. Build the review response tool first, because someone is answering reviews every morning whether you help them or not.
Pilot it like a media buy
Don't roll out to forty communities. Pick three people, ideally including one skeptic, and give them the tool for two weeks with one instruction: send me anything it got wrong.
You're looking for a specific pattern. Every failure is either a missing constraint (add to Block 1) or a missing slot (add to Block 2). That's it. Sort every complaint into one of those two buckets and fix accordingly. After two weeks the failure rate drops off a cliff, and you have something worth naming.
Then version it. Date in the title, one owner, one line at the top saying what changed. Not bureaucracy. Just so that when the tool starts producing something weird in March, you know which change caused it.
What this actually gets you
The department version of a prompt is worth roughly ten times the personal version, because you stop being the bottleneck. You're not the one who "does the AI stuff." You built the thing that does the AI stuff, and it carries your standards into work you never see.
That's the job title change nobody announces. One week you're the marketer with a clever trick. The next you're the person whose judgment is running on eleven properties at once.
The honest footnote
Tools drift. Model updates change output tone without warning, your brand guidelines get revised, and a prompt that was perfect in January produces something oddly formal in June. Put a recurring 30 minute calendar block quarterly to re-run each tool against a known input and read the output. If it's off, it's usually one constraint that needs re-tightening.
Also: a tool multiplies whatever you put in it. Bad brand voice, faithfully reproduced eleven times, is worse than bad brand voice once. Get the standards right before you scale them.