Huawei and Digital Inclusion: Explaining Technology Through Tangible Public Value

01 Facts & context

Brand positioning: embracing the mission through digital inclusion

Huawei's official website states its vision and mission as bringing the digital world to every person, home, and organization, and building an intelligent, connected world. TECH4ALL, a long-term digital inclusion initiative launched in 2019, provides a concrete entry point for observing this broad claim. Official materials describe focus areas including education, environment, health, and development, and discuss technology, applications, and digital skills together. The brand can thus explain the significance of connectivity, cloud, artificial intelligence, and devices through the problems people face, giving non-technical audiences an opportunity to understand the relationship between technological capabilities and social life.

02 Facts & context

Key approach: using projects to showcase technology combinations

The TECH4ALL website organizes practice content by issue, covering areas such as digital skills, remote communities, accessible services, and nature conservation, and emphasizes joint promotion with partners. This organizational approach makes it easier for different audiences to enter from relevant needs and gradually understand the underlying technology. It also demonstrates the collaborative conditions required for technology application: beyond product capabilities, it involves usage contexts, target users, and local partners. For brand content, a specific project can simultaneously explain what problem is addressed, what tools are provided, and how partners participate, forming a more complete explanation than merely listing technology terms.

03 GSP analysis

Public issues must first answer who faces what difficulties

To avoid vagueness in technology explanations, one should first clarify the difficulties encountered by the target users in specific tasks. A company learning from this can first select a type of user and describe the obstacles in their daily operational processes, such as teachers in remote areas lacking localized resources for lesson preparation, or visually impaired users struggling to complete online registrations independently. The problem statement should include existing alternatives and their limitations, such as time-consuming phone consultations or the need for assistance from others, to highlight the entry point for technological intervention. At the same time, usage conditions should be explained, such as network coverage, device performance, or operational skill requirements, to prevent portraying the technology solution as unconditionally applicable. This task-oriented narrative is more likely to help audiences understand why the technology is necessary than directly claiming to 'promote educational equity.'

Once the problem is clear, the role of technology should be limited to a tool that completes specific steps, not a universal solution. A company learning from this can explain the inputs, such as users uploading photos or voice, the technology performing recognition or conversion, and then human or partner review and follow-up services. This division of labor narrative should clarify technical limitations, such as reduced recognition accuracy in low light or limited dialect support, to avoid exaggerating capabilities. If partners are involved, describe their actual responsibilities in needs confirmation, on-site implementation, or maintenance, rather than merely listing them as supporters. By breaking down the task chain, audiences can judge the true boundaries of technology contributions, and companies can more easily verify effects later.

For partner collaboration to be effective, it must cover the entire process from needs identification to service continuity. A company learning from this can first conduct needs research with organizations familiar with the target users, confirming task priorities and existing barriers; then, during implementation, clarify each party's responsibilities, such as the company providing equipment and training, and partners organizing users and collecting feedback; after the service goes live, arrange ongoing maintenance, including fault response and content updates. If partners only participate in the launch ceremony and no one follows up, the project may stall. Therefore, cooperation agreements should include regular communication mechanisms and exit plans to ensure that when one party's capabilities change, the service can still be continued by another party, avoiding users being left without support.

A case study that clearly presents both process and evidence can establish a structured recording framework. A company learning from this can first record the problem background and implementation steps, then collect observable changes, such as shortened task completion times or increased independent operation counts. Information sources should distinguish between company self-tests, partner feedback, and third-party observations, and note items pending verification, such as long-term effects or applicability in different regions. Company introductions and independent evaluations should be clearly separated, not treating promotional materials as proof of effectiveness. If results later fall short of expectations, analyze whether the issue lies in technology adaptation, implementation execution, or information explanation, and adjust accordingly. This recording method supports internal improvement and provides a verifiable factual basis for external audiences.

04 GSP analysis

Let technology assume an explainable role in the problem

To let technology assume an explainable role in a specific problem, a company learning from this must first clarify the inputs and boundaries of its own capabilities. For example, a company providing image recognition can explain that its input is field-captured image data, the technology completes the step of automatically detecting specific features, and humans or partners confirm the detection results and take follow-up actions. This narrative should avoid vague claims like 'using AI to solve a problem' and instead break it down into verifiable steps, honestly acknowledging technical conditions, such as limitations in lighting, angle, or data quality. This way, audiences understand what the technology actually does, not just the result label.

In terms of operational mechanisms, companies can establish a narrative template of 'problem-input-processing-output-human continuity.' The technical team describes algorithm logic and performance boundaries, the project team records actual input conditions and output results in real applications, and the communications team translates these into non-technical language. The key is to have real projects as support, not fabricated scenarios. A company learning from this should choose problems closely related to its core capabilities, first confirm needs with organizations familiar with the target users, and then design the technology intervention point. If lacking contextual knowledge, partners can provide situational guidance, but the division of labor must be clear: the technology side explains capabilities, and the partner validates needs and applies results.

Conditions for success include: the company has reusable technology modules and is willing to invest time in field testing; partners have trust and channels with the target users and can provide genuine feedback; management accepts that narratives must include limitations and not exaggerate effects. Operationally, one can first pilot in a small scope, record the entire process, including successful and failed cases of technology processing, and then refine the narrative. For example, if technology is used to identify certain environmental changes, explain which changes can be identified and which cannot, and how humans review. This honest narrative actually enhances credibility, but note that the absence of a mechanism in materials does not imply the company lacks it or that it is a weakness.

Verifiable signals include: whether project records contain input data descriptions, technology processing steps, human intervention points, and result verification methods; whether content clearly distinguishes technology contributions from partner contributions; and whether audiences can restate technology application conditions. A company learning from this should regularly review these signals, and if it finds that narratives only emphasize technology while ignoring limitations, or partner roles are vague, adjustments are needed. Meanwhile, effect evaluation should be based on actual observation, not preset awareness or efficiency improvements. If a project falls short, it may stem from technology adaptation, implementation processes, or information explanation issues, which need separate investigation rather than simple attribution. Ultimately, narratives should serve audience understanding, not brand promotion, so technology can assume an explainable role in the problem.

05 GSP analysis

Partner collaboration needs to cover needs and service continuity

If a company learning from this wants to support digital inclusion projects through partner collaboration, it must first clarify each party's role. It is recommended that organizations familiar with the needs of the target users act as the needs proposer, the company as the technology capability provider, and both jointly define the problem boundary. Needs confirmation should be based on field observation or user feedback, not assumptions. For example, if targeting education in remote areas, first understand the existing tools and barriers of teachers and students, then determine the technology intervention point. The company can assign dedicated personnel for technology feasibility assessment, and partners supplement contextual knowledge, avoiding role overlap or omission.

06 GSP analysis

How a case study can simultaneously clarify process and evidence

To simultaneously clarify process and evidence in a case study, the key is to establish a unified recording framework. A company can start with the problem background, explaining who the target users are, what specific difficulties they face, and why existing alternatives are insufficient. Then record the implementation process, including what tools the company provided, what roles partners played, and how the two sides divided work. The section on observable changes should distinguish between direct results and indirect impacts, such as whether users can complete a task or whether the service continues to operate. Information sources must be clearly marked, indicating which come from the company's own introduction and which from independent evaluations or third-party feedback. Items pending verification should list assumptions that need further testing, such as technology adaptability, long-term effects, or cost-effectiveness. Such a framework presents a complete narrative while allowing readers to judge the strength of the evidence themselves.

In terms of operational mechanisms, a company should designate a cross-functional team responsible for case recording: the technology team explains capability boundaries, the project team provides implementation facts, and the communications team converts information into easily understandable language. During the recording process, each step should have a clear responsible person, and progress should be updated regularly. At the same time, the company needs to establish a fact-checking process to ensure all statements are verifiable. For partner contributions, clearly record their specific responsibilities, avoiding vague descriptions. Before publishing a case, conduct an internal consistency review to prevent exaggeration or omission of key information.

Conditions for success include the company having real, verifiable projects and being willing to invest time in maintaining case content. Projects should have clear goals and observable outputs, such as service coverage, user feedback, or environmental indicators. The company also needs to be aware of distinguishing between company introductions and independent evaluations, not treating its own publicity as third-party assessment. If independent data is lacking, clearly state information limitations rather than blurring them. For small and medium-sized enterprises, start with a clearly bounded project, record the complete process, and then consider expansion.

A practical approach is to adopt a sectioned case structure, where each section answers a core question, such as problem background, implementation steps, results and evidence, and items pending verification. In the narrative, use specific but qualitative descriptions, such as 'some users reported easier operations' rather than quantified results. Additionally, companies can invite external experts or beneficiaries to provide feedback as a supplement to independent perspectives. Verifiable signals include whether the case contains a traceable project timeline, lists partner responsibilities, and distinguishes facts from inferences. If others can replicate or evaluate based on the case, the recording framework is effective.

07 GSP analysis

Separate public value, brand understanding, and business opportunities

Public value communication, brand understanding, and business opportunities are three activities with different goals and cannot substitute for each other. Public value communication aims to let the public perceive technology's response to social issues, brand understanding seeks audience awareness of capabilities and positioning, and business opportunities focus on converting potential customers and partners. A company learning from this should clarify the primary goal of each piece of content, avoiding directly carrying sales expectations with public welfare narratives, and preventing commercial demands from undermining the credibility of public value. The three can proceed sequentially, but their effectiveness should be evaluated independently.

08 GSP analysis

Theme expansion should follow capabilities that can be sustainably delivered

When expanding issues, a company should prioritize whether it can sustainably deliver, rather than chasing hot topics for coverage. Focusing on an issue means having a deep understanding of the needs of a specific population and being able to assume long-term maintenance responsibilities. If choosing multiple directions, each requires matching professional knowledge and resource investment; otherwise, the credibility of the overall brand narrative may be weakened. A company learning from this can start with one problem closely related to its core capabilities, establish a complete service loop, and then assess the feasibility of expansion.

09 Suggested actions

Build project records from problems matching core capabilities

A company learning from this should first select a clearly bounded problem directly related to its core capabilities, rather than a vague social value slogan. The problem statement must be specific to 'who encounters what difficulty in what context' and clarify existing alternatives and their shortcomings. Then, work with organizations familiar with the target users' needs to confirm the problem definition, avoiding acting solely on internal assumptions. The key in this step is to establish a shared problem framework, giving subsequent technology intervention a clear focus.

10 Suggested actions

Use verifiable feedback to improve projects and narratives

To improve projects and narratives, a company learning from this can establish a verifiable feedback mechanism. First, before project launch, define the indicators to be tested, such as the target population's understanding of the technology tool, actual usage frequency, and the availability of ongoing services. These indicators should directly relate to project goals, not vague satisfaction surveys. Then, during implementation, regularly collect data, including user interviews, usage logs, and partner observations, forming a multi-source evidence chain.

In terms of operational mechanisms, establish a cross-functional feedback team composed of technology, project operations, and communications personnel. The technology team determines whether issues stem from technology adaptability, such as interface usability or whether features meet needs; the project team focuses on obstacles in the implementation process, such as whether training is sufficient or services are timely; the communications team assesses whether information explanations are clear or cause misunderstandings. The team meets regularly to analyze feedback against original goals, distinguishing problem types to avoid misjudging technology issues as communications issues.

Conditions for success include: the company has basic data collection and analysis capabilities and is willing to invest time in continuous tracking. Partners must recognize the value of the feedback mechanism and assist in obtaining user feedback. If real usage scenarios are lacking, first pilot on a small scale to ensure feedback channels are smooth. Additionally, the company should establish a clear decision-making process to adjust project design or narrative based on feedback results, rather than using feedback solely for promotion.

A practical approach is to set periodic review points in the project cycle, and after each review, produce a written record explaining discovered issues, actions taken, and expected impacts. When feedback shows users misunderstand, first check whether information explanations are clear; if usage rates are low, examine technology adaptation and implementation support. Only when evidence indicates the project is effective under specific conditions should expansion be considered. Verifiable signals include: whether users can accurately describe the technology's purpose, whether usage frequency is stable, and whether partners are willing to continue collaboration. These signals should serve as a basis for adjustment or expansion, not preset outcomes.