How can real customer cases demonstrate project scope without revealing customer information? The key is not to remove the customer’s name, but to first identify which facts are allowed to be disclosed, and then use the approved scope of delivery and visible evidence to explain what the team did. The credibility of a case comes from clear boundaries and verifiable evidence, rather than from piling up unauthorized screenshots or pretty numbers. This article provides an editing process for teams that have real projects and are preparing to write cases; the table is a fictitious demonstration and does not represent AIRSANG’s customer projects.

Make a list first: what can be real-name, what should be anonymous, and what cannot be made public

Before writing, ask the project leader to take out the contract agreement, communication records and the scope of display approved by the client, and establish an itemized disclosure list. Separate judgments between “customer names can be written” and “all background screenshots can be posted”: Agreeing to display the logo does not mean agreeing to disclose quotations, orders or conversion data; agreeing to quote a review does not mean agreeing to put the customer contact name on the website. Project details that are not explicitly approved are first classified as pending, and authorization cannot be presumed based on verbal impressions.

Divide materials into three levels

Real-name display available: The customer clearly approves the name, website URL, project category, page screenshot and text description, and the approval record can correspond to the current version. Can be displayed anonymously: Customers are allowed to outline the industry, business goals, page types and implementation steps, but no details that can be used to verify their identity. Not public: Unapproved contract amounts, backend accounts, order and visitor information, unreleased products, actual transaction amounts or strategy documents. Even if a piece of information seems ordinary on its own, check to see if it can identify the customer when combined with other clues.

The operations team can record the “original document, proposed public version, approver, approval date, applicable channels and withdrawal method” for each material in the list. This way, writers know what material makes it onto the page, designers know which images must be redone, and publishers can check the final URL before going live. Content Marketing Institute Tips for Inviting Clients to Participate in Stories There is also an emphasis on establishing a formal customer engagement and licensing process first; this is editorial practice advice and cannot replace the specifics of the parties’ contract.

Use the Delivery Scope Matrix to demonstrate work, not imply performance

When potential customers read the case, they first want to know which pages, content or functions the service provider is responsible for. The scope statement should start from requirements, to deliverable modules, and then to evidence of approval for presentation. For example, “remodeling the homepage” is too general; “sorting out the information structure of the homepage, making first-screen and industry application modules, and completing mobile terminal adaptation” can better explain the investment and boundaries. However, these verbs must be consistent with the real project records, and the development work done by the partner cannot be credited to one’s own name.

The following is fictional teaching demonstration sheet , only explains the writing method and does not correspond to any AIRSANG customers, orders or actual performance. When a customer story is actually released, it should be replaced box by box with verified project facts that are approved for disclosure.

The permission column on the right side of the matrix cannot be omitted: being able to produce working documents does not mean that you have the right to make the documents public. If the result indicator involves customer inquiry, orders, revenue or conversion rate, create a separate record of “Data Source – Statistical Interval – Attribution Limits – Customer Approval”. Without reliable measurement or approval, just describe the delivery, instead of “may improve the experience” as “bring about growth”. The public page only displays visible results and cannot independently prove the backend data or contract scope. You can view the public Phonix Audio website design case , observe how the page presents the project; this article does not infer its undisclosed contracts, metrics, or licenses.

Screenshots, files and links: What to check after removing a name

Case pictures are the easiest to leak information. When showing the website design process, the edge of the screen may contain the editor account, browser bookmarks, backend paths, email notifications, customer addresses, order numbers, and tracking parameters. Before publishing, export a version specifically for publicity from the original project assets. Do not directly drag internal meeting screenshots or backstage screen recordings into the media library. The person in charge checked the desktop size, mobile phone cropping size, thumbnails and clickable large images one by one to confirm that the covered area would not be re-exposed in any presentation method.

Check not only the visible screen. Images and documents may have metadata, filenames, hidden layers, or notes; links may have query parameters and accessible older versions. Even if the name is replaced by “a certain customer”, the combination of niche products, precise regions and launch dates may cause the identity to be reversed. Anonymization instructions for UK ICOs Emphasize that identification of an individual depends on the relationship of the information to available clues. What is quoted here is a general risk judgment idea, not a legal conclusion on Chinese regulations or a certain contract.

Change high-risk images into clearly labeled schematics

If the interface contains a large number of real orders, customer lists, or account information, coding one by one is laborious and easy to miss. A safer editorial choice would be to redraw a “Teaching instructions, not real customer background” A flowchart that explains the navigation structure, form path, or page components you made. The schematic diagram cannot reproduce the sensitive structure according to the customer’s real backend, nor can it insert fictitious customer inquiry data as the result. The main text must clearly state that it is only a method demonstration; when readers need to see real project evidence, priority should be given to website pages that have been approved for public disclosure or visual drafts confirmed by customers.

How can you write a case without real-name permission?

Without real-name authorization, it does not mean that the project must be written in a vague way. If the customer allows anonymous narration, you can use a general name such as “a B2B industrial equipment brand” to clearly describe the business situation, verified page range, delivery actions, and project boundaries. Avoid overlaying clues such as rare product models, cities, precise dates, unique business sizes, etc. Don’t write the title in a combination that is easy to be searched and reversed. After writing, let someone who is not involved in the project read it over to see if they can guess the customer based on these clues; if they can, continue to generalize or delete details.

Anonymous cases still require a basis of truth: the project actually happened, the scope of work is documented internally, and the wording of the disclosure is approved accordingly. Don’t combine two customer projects into one “real case”, and don’t use schematics to pass off actual delivery. If the client only approves the demonstration of a certain general method and does not approve any verifiable project facts, it is appropriate to position the article as a working method or tutorial rather than labeling it as a real client case. If the team is still deciding the content rhythm of cases and tutorials, you can refer to Writing order of platform tutorials and customer cases ; That article discussed scheduling, and this article only discusses the public boundaries of existing projects.

Approval is not just “can be issued”: let the text, pictures and URL match the version

When preparing to publish, the writer, project leader and the customer’s designated contact person should check against the same preview draft: whether the customer’s name appears, whether the page list is accurate, which version of the picture is, whether the data has a source, and where the external links will jump. It’s better to tie the approval record to the article version and the specific image file, rather than just leaving a “Agree for publication” out of context. If you later change the screenshot or add new indicators, you should reconfirm the changes. A contact person must also be designated internally to receive correction or retraction requests, and the modification time and page address must be recorded.

After going online, people who have not participated in the editing can use a non-logged-in browser to open the public URL and check the page, original image file, social sharing preview, search summary and mobile layout. If sensitive information is found, priority should be given to deleting public content or implementing access control, and then processing search results. Google Search Central’s instructions for controlling shared content pointed out that noindex It only affects search inclusion, and people with the link may still access the page; it does not replace confidentiality measures. For content that has been leaked, caches, attachments, and third-party copies will also be checked, but we cannot promise that all will be withdrawn.

Six pre-launch questions for case writers

1. Are the project name, scope, and delivery dates consistent with actual records?
2. Does every client name, logo, page, and metric have corresponding public approvals?
3. Can anonymous leads be combined to redirect to a customer or individual?
4. Have you checked the original image files, attachments, parameters and mobile cropping?
5. Are diagrams and fictitious tables clearly labeled and not pretending to be real results?
6. Who is responsible for reviewing, correcting, and handling retractions after publication?

Conclusion: Credible project scope comes from confirmable public boundaries

Real customer stories need to answer two things at once: what exactly the team did, and why that information should be made public. First establish a three-layer public list, then use the requirements, delivery and evidence matrix to write out the project scope; review the screenshots, files and links one by one, and finally ask the customer to confirm the specific versions of the text and pictures. It is better not to write data without permission, and do not write down performance without source. Cases written in this way may have fewer exciting numbers, but it will make it easier for potential customers to understand the scope of services, and also allow customers to retain the control they deserve.

If you want to start today, you can first use the fictitious matrix above to change it into a one-page internal worksheet, fill in the real records of your existing projects, and then let the project leader and the customer’s designated contact person decide what content can enter the public web page. Until approved, it remains an internal draft and not a publishable customer story.