There is a kind of endorsement a customer will never think to give you, because to them it isn't an endorsement at all — it's just how the work gets done. Somewhere in their internal wiki, their onboarding docs, or the runbook a new hire reads on day one, someone has written a sentence like "we use your product to handle X; here's how." Nobody wrote it to flatter you. They wrote it because your product is now load-bearing enough that a colleague needs to know how to operate it. That is what makes an internal-wiki mention unusually strong — and unusually delicate. The sentence proves adoption in the most concrete way possible, but it lives inside a confidential document that was never meant to leave the company, and you may not even be supposed to know it exists. It can become a testimonial, but only if you treat the wiki as evidence to point at, never as text to publish.
Why an internal-wiki mention is worth more than a solicited quote
Most testimonials describe a feeling: the product is great, the team is responsive, the onboarding was smooth. An internal wiki entry describes a behavior. When a customer writes "to reset a stuck sync, open [your product] and re-run the job from the dashboard," they are documenting that your product is part of their operating procedure — the thing they train new employees on and rely on under pressure. There is no marketing incentive anywhere in that sentence. It exists purely because the product earned a place in how the team works.
That is exactly the proof a skeptical prospect is looking for. Solicited quotes answer "do you like it?" An internal wiki mention answers a harder question: "did you actually build your process around it?" A prospect evaluating whether to bet their own workflow on you finds the second answer far more persuasive — which is precisely why you can't just screenshot the wiki page and post it.
The confidentiality problem is the whole problem
Everything about doing this well comes down to one fact: an internal wiki is a private operational document, and a mention inside it carries none of the permissions you need to publish it. You may have seen the page because a champion shared their screen during a call, or pasted a snippet into a support ticket, or forwarded a runbook so you could help them debug. None of those is consent to quote the page publicly with the customer's name attached. Worse, an internal wiki often reveals things the customer would never want public — team size, internal process gaps, how they've configured your product around a limitation, even the names of systems they'd rather not disclose. Screenshotting it doesn't just risk a testimonial they didn't approve; it risks exposing operational detail that gets your champion in trouble with their own security or legal team.
So the rule is simple and absolute: the wiki is not the testimonial. It's the signal that a testimonial is available for the asking.
Use the mention as the reason for the ask, not the quote itself
The move is to let the internal mention tell you who to ask and what to ask about, then go collect something you're actually allowed to publish. Instead of "can I use your wiki page," you go to the person who wrote it with something like: "I noticed your team has built [product] into your onboarding process — that's genuinely one of the strongest signals we get. Would you be open to a two-sentence version we could quote publicly?"
That framing does three things. It flatters them accurately, because you're pointing at something real they did rather than asking for a favor. It moves the conversation off the confidential artifact and onto a clean, quotable statement. And it lets the customer control exactly what becomes public — which is the only version that's safe to publish and the only version they'll feel good about later. The internal wiki did its job the moment it told you this customer's adoption runs deep enough to be worth a specific, credible ask.
Turn the operational detail into a specific prompt
The best thing an internal wiki gives you isn't a quote — it's specificity. Because the page describes an actual procedure, you already know the concrete way this customer uses the product. Use that to make your ask impossible to answer generically. Rather than "would you write us a testimonial," say: "your runbook mentions using [product] to handle sync failures during the overnight batch — could you describe in a sentence or two what that replaced and what it's saved the team?"
Now the customer isn't staring at a blank box trying to invent praise. They're confirming a story you already half-know, which is far easier and produces the specific, believable testimonial a prospect trusts. You've converted a confidential operational detail into a legitimate, publishable claim — without ever exposing the document it came from.
Get the permission in writing, then attribute carefully
Once the customer gives you a quote, treat consent the way you would for any testimonial: get an explicit, written "yes, you can publish this with my name and title." A verbal okay on a call is not enough, especially when the underlying source was an internal document — if anyone at the customer later asks how you got the quote, you want a clean paper trail that says "we asked, they approved this exact wording," not "we found it in their wiki."
Attribute the quote to the person and their role, not to the artifact. Never say "from their internal onboarding docs" or "as documented in their runbook" — that re-exposes the confidential source you just worked so hard to keep private. The published testimonial should stand entirely on its own words and the named person behind them. The wiki was the tip that this customer had a real story; the testimonial is the clean, consented version you're allowed to show the world.
The one-line rule
An internal wiki mention is the strongest adoption signal you'll ever stumble onto and the one you can least afford to publish directly. Treat the page as a private tip that tells you who to ask and what to ask about — then go get a clean, consented, specifically-worded quote you actually own. The proof was never the screenshot. It was the fact that a customer built you into how they work, and was willing to say so on the record when you asked well.