On June 19, 2026, the University of Manchester said Teaching and Research staff and Postgraduate Researchers had begun receiving Microsoft 365 Copilot access, backed by live training, guidance, feedback channels, and dedicated support as part of its wider institution-wide AI rollout. The announcement is not just another campus IT update; it is a marker of how quickly generative AI is moving from optional experiment to managed infrastructure. Manchester is trying to make Copilot boring before it becomes unavoidable. That may be the right instinct, but it also exposes the central tension every university and enterprise now faces: AI adoption is less about switching on a product than governing a new layer of institutional behavior.
The University of Manchester’s latest Copilot update lands at a telling moment. For the first two years of the generative AI boom, many organizations treated tools like ChatGPT, Copilot, Gemini, and Claude as edge cases: useful to enthusiasts, worrying to compliance teams, and awkward for policy writers. Manchester’s move says that phase is ending.
The institution is not merely allowing staff to use Microsoft 365 Copilot. It is giving access to broad categories of academic users — Teaching and Research colleagues and Postgraduate Researchers — while surrounding that access with live learning sessions, policy work, advisory groups, and feedback loops. The shape of the rollout matters because it reflects the product’s actual risk profile. Copilot is not a standalone chatbot sitting outside the workplace; it is an assistant threaded through email, documents, meetings, calendars, files, and collaboration spaces.
That makes it powerful in precisely the ways that make IT departments nervous. A tool that can summarize a Teams meeting, draft a policy note, query a document set, or help structure a grant application is also a tool that depends heavily on identity, permissions, data hygiene, and user judgment. If those foundations are weak, Copilot does not merely automate work. It can automate confusion.
Manchester’s answer is to frame adoption as a shared institutional project rather than a vendor deployment. The university says it has adapted the rollout at every phase based on feedback, including through faculty engagement and the CoCoA — Copilot Co-ordination and Advisory — group. That acronym may sound like committee furniture, but the premise is serious: an AI rollout in a university cannot be treated like a browser update.
Taken at face value, those numbers are a win for the project team. They also reveal something Microsoft’s own marketing tends to blur: Copilot is not self-explanatory. The product may live inside familiar apps, but the work of using it well requires a new literacy. People need to understand what to ask, what not to ask, how to verify outputs, when to avoid using AI altogether, and how institutional rules apply to everyday tasks.
That is especially true in higher education, where the boundary between productivity and pedagogy is unusually porous. A lecturer using Copilot to draft a module outline is not doing the same thing as a finance officer summarizing a spreadsheet. A researcher asking Copilot to help structure literature notes is not facing the same risks as a student using AI to generate assessed work. The same tool can be mundane, transformative, or inappropriate depending on context.
Manchester’s confidence jump therefore should not be read as proof that all concerns have been settled. It is better understood as evidence that structured introduction matters. Users who are left alone with a new AI assistant often discover either the magic trick or the failure mode first, and both can distort judgment. Training can turn first impressions into working habits.
The caveat is that confidence is not competence. A session can make users more comfortable, but the longer test is whether they use Copilot safely, effectively, and with enough skepticism. For sysadmins and IT leaders, that is the uncomfortable truth behind every adoption metric: attendance is easy to count, but judgment is hard to measure.
In universities, ambiguity around AI quickly becomes unfairness. If one course permits AI brainstorming and another bans all AI assistance, students may encounter wildly different expectations under the same institutional banner. If staff members rely on private judgment alone, assessment rules become inconsistent and hard to defend. A common framework does not eliminate discretion, but it gives that discretion a floor.
The policy emphasis also reflects a deeper institutional concern: Microsoft 365 Copilot is not just a productivity product but a cultural accelerant. Once staff become comfortable using AI to draft, summarize, classify, and synthesize, students will reasonably ask why similar affordances are forbidden, restricted, or unevenly available to them. The university cannot roll out Copilot to academics and pretend the classroom implications are separate.
That is why Manchester’s student-facing language is careful. The university says it is working with students through a Copilot Student Advisory Group and broader engagement activity over the summer. It is also developing a “Test, Learn and Adapt” study to generate evidence about responsible and effective student introduction, including support models, communications, academic guidance, and safeguards.
This is slower than the most enthusiastic AI advocates would prefer. It is also more responsible than simply declaring that students must be “AI ready” and throwing a tenant-wide switch. The university appears to understand that equity in access is not the same thing as equity in outcomes. If some students arrive with strong AI literacy and others do not, a nominally universal rollout may still widen gaps.
The real test is whether Copilot changes how knowledge work is organized. In a university, that means teaching preparation, research administration, grant development, ethics paperwork, supervision, student communication, literature handling, committee work, and the endless internal documentation that keeps large institutions moving. Copilot’s promise is not that each task becomes miraculous. It is that enough low-friction assistance accumulates to change the texture of work.
That promise is plausible. Universities are full of highly skilled people who spend too much time translating ideas into institutional formats. An AI assistant that helps draft, summarize, compare, and retrieve can be genuinely useful in that environment. Postgraduate Researchers, in particular, may find value in turning sprawling notes into plans, converting feedback into action lists, or navigating administrative documents.
But the same environment is full of traps. Research work often involves unpublished ideas, sensitive data, third-party materials, and disciplinary norms that do not map cleanly onto corporate productivity assumptions. Teaching work involves students, assessments, accommodations, and academic integrity. Copilot can reduce friction, but friction sometimes exists for a reason.
The question, then, is not whether Copilot can produce fluent text. It plainly can. The question is whether users understand the difference between fluency and reliability, between a helpful draft and an authoritative answer, and between private productivity and accountable academic work. That is where Manchester’s live training and policy framing become more than administrative garnish.
Manchester’s January announcement framed the collaboration as a sector-first effort to provide broad access and training across the university community. Since then, the rollout has progressed through cohorts, with Professional Services earlier in the year and now Teaching, Research, and PGR groups. The sequencing suggests a controlled adoption model rather than a single dramatic launch.
That matters because the risks are distributed unevenly. Professional Services teams may face governance, privacy, records, and operational issues. Teaching and Research colleagues face those too, but they also sit closer to the university’s academic mission. Once Copilot enters lecture planning, feedback workflows, research development, and postgraduate supervision, it becomes harder to separate “digital transformation” from the core business of the institution.
Microsoft can supply product documentation, dashboards, admin controls, and responsible AI language. It cannot decide what counts as appropriate use in a particular seminar, lab, dissertation meeting, or exam context. That burden stays with the university. The vendor sells the platform; the institution inherits the edge cases.
This is why Manchester’s emphasis on feedback is important. The announcement repeatedly signals that the rollout has been adapted based on concerns and practical considerations. That is not merely change-management language. In AI deployments, feedback is a control mechanism. Without it, organizations learn about failure through incidents rather than iteration.
This is the classic AI deployment paradox. Copilot may not create an access-control problem, but it can reveal one at speed. A user who technically had access to an old SharePoint site, forgotten Teams channel, or poorly governed document library may never have found anything sensitive before. An AI assistant designed to retrieve and summarize information changes that equation.
Universities are especially exposed to this kind of entropy. They are large, federated, historically layered organizations with long-lived departments, research groups, committees, projects, and external collaborations. Files accumulate. Teams are created for short-term work and then persist. Permissions are inherited, copied, widened, and rarely reviewed with the discipline a security architect would like.
That does not mean Copilot should be blocked until every permission is perfect. If that were the standard, no large organization would deploy anything. It does mean the rollout has to be accompanied by sober work on information governance. The magic phrase here is not “prompt engineering.” It is least privilege.
Training users to ask better questions is useful. Ensuring they cannot accidentally surface material they should not see is essential. The operational burden falls on Microsoft 365 administrators, records managers, data protection teams, and local IT units that already have too much to do. AI does not replace that work; it makes the backlog harder to ignore.
The university’s summer work with the Copilot Student Advisory Group is therefore more than consultation. It is a recognition that students are not merely downstream users. They are affected by how staff use AI, how assessment rules are communicated, how feedback is generated, and how access is distributed. A student may never touch Copilot and still experience its effects if their course team uses it in preparation or communication.
The phrase “designed with students” is doing important work here. It implies that student rollout cannot be designed solely by IT, procurement, or senior leadership. Students will have practical questions that differ from staff concerns. Will Copilot be allowed for brainstorming? For coding help? For grammar? For summarizing readings? For revision plans? For assessed work if declared? For students with disabilities or language barriers?
Those questions are not solved by a license. They require academic judgment, disciplinary nuance, and clear communication before the new academic year. The worst possible outcome would be an environment where AI use is common, detection is unreliable, rules are inconsistent, and students infer norms from rumors. That is how trust drains out of assessment.
Manchester’s planned Test, Learn and Adapt study is a sensible hedge against that. It admits that the university does not yet know the best way to introduce Copilot to students at scale. That admission is a strength, not a weakness. In 2026, institutional AI certainty is often less credible than institutional humility.
Manchester’s announcement is stronger because it ties responsibility to specific mechanisms: live learning, guidance, advisory groups, student engagement, policy development, feedback forms, and iterative adaptation. None of these guarantees success. Together, they suggest the university understands that responsible use has to be operationalized.
That is the key lesson for other institutions watching Manchester. A Copilot rollout is not responsible because it is slower, nor irresponsible because it is ambitious. It becomes responsible when the organization can explain who gets access, what training they receive, what data protections apply, how policy governs use, how concerns are escalated, and how the deployment changes when reality contradicts the plan.
The uncomfortable part is that responsibility is labor-intensive. It requires meetings, documentation, training design, support channels, evaluation, and ongoing revision. It demands that leaders listen to skeptics without letting skepticism become paralysis. It also demands that enthusiasts accept boundaries without treating every guardrail as fear.
That may be the biggest cultural shift Copilot forces. The product is marketed as a personal assistant, but safe adoption is collective. One person’s convenience can become another person’s exposure, confusion, or unfairness. In a university, where individual autonomy and institutional accountability constantly rub against each other, that tension is unavoidable.
The university should now be looking for evidence in the messy middle. Are staff saving time on low-value administrative work, or merely producing more polished drafts that still require the same review burden? Are PGRs using Copilot to structure work more effectively, or are they becoming more dependent on generic synthesis? Are support tickets rising because users are confused, or falling because training is working?
There is also a need to measure negative space. Are some staff opting out because of principled concerns, accessibility barriers, workload pressure, or lack of perceived relevance? Are certain departments adopting Copilot much faster than others? Are researchers in sensitive fields more cautious, and if so, is the support model meeting them where they are?
The most important metrics may be qualitative. A good rollout should surface stories of both success and discomfort. The success stories show where the tool fits real work. The discomfort shows where policy, training, data governance, or product design has not caught up. If the feedback loop is healthy, both kinds of evidence should shape the next iteration.
Manchester’s own language suggests that it knows access and training are only the start. That is exactly right. The first serious milestone is not the day users receive Copilot. It is the day the institution can say what changed because they did — and what it changed in response.
Manchester Turns Copilot From Pilot Project Into Campus Plumbing
The University of Manchester’s latest Copilot update lands at a telling moment. For the first two years of the generative AI boom, many organizations treated tools like ChatGPT, Copilot, Gemini, and Claude as edge cases: useful to enthusiasts, worrying to compliance teams, and awkward for policy writers. Manchester’s move says that phase is ending.The institution is not merely allowing staff to use Microsoft 365 Copilot. It is giving access to broad categories of academic users — Teaching and Research colleagues and Postgraduate Researchers — while surrounding that access with live learning sessions, policy work, advisory groups, and feedback loops. The shape of the rollout matters because it reflects the product’s actual risk profile. Copilot is not a standalone chatbot sitting outside the workplace; it is an assistant threaded through email, documents, meetings, calendars, files, and collaboration spaces.
That makes it powerful in precisely the ways that make IT departments nervous. A tool that can summarize a Teams meeting, draft a policy note, query a document set, or help structure a grant application is also a tool that depends heavily on identity, permissions, data hygiene, and user judgment. If those foundations are weak, Copilot does not merely automate work. It can automate confusion.
Manchester’s answer is to frame adoption as a shared institutional project rather than a vendor deployment. The university says it has adapted the rollout at every phase based on feedback, including through faculty engagement and the CoCoA — Copilot Co-ordination and Advisory — group. That acronym may sound like committee furniture, but the premise is serious: an AI rollout in a university cannot be treated like a browser update.
The Training Numbers Tell a Story Microsoft Cannot Tell Alone
The most striking figures in Manchester’s announcement are not about licenses or product features. They are about participation and confidence. The university says more than 4,000 colleagues have attended live learning sessions, with 45 sessions delivered across cohorts on topics ranging from prompting to content creation. Those sessions averaged 4.6 out of 5, and reported confidence rose from 24 percent to 80 percent after training.Taken at face value, those numbers are a win for the project team. They also reveal something Microsoft’s own marketing tends to blur: Copilot is not self-explanatory. The product may live inside familiar apps, but the work of using it well requires a new literacy. People need to understand what to ask, what not to ask, how to verify outputs, when to avoid using AI altogether, and how institutional rules apply to everyday tasks.
That is especially true in higher education, where the boundary between productivity and pedagogy is unusually porous. A lecturer using Copilot to draft a module outline is not doing the same thing as a finance officer summarizing a spreadsheet. A researcher asking Copilot to help structure literature notes is not facing the same risks as a student using AI to generate assessed work. The same tool can be mundane, transformative, or inappropriate depending on context.
Manchester’s confidence jump therefore should not be read as proof that all concerns have been settled. It is better understood as evidence that structured introduction matters. Users who are left alone with a new AI assistant often discover either the magic trick or the failure mode first, and both can distort judgment. Training can turn first impressions into working habits.
The caveat is that confidence is not competence. A session can make users more comfortable, but the longer test is whether they use Copilot safely, effectively, and with enough skepticism. For sysadmins and IT leaders, that is the uncomfortable truth behind every adoption metric: attendance is easy to count, but judgment is hard to measure.
The University Is Trying to Govern Use Before Use Governs the University
Manchester’s rollout is notable because it treats policy as part of deployment rather than a cleanup exercise after the fact. The university points staff toward its recently launched AI in Teaching and Learning Policy, which is intended to give a common framework for communicating expectations to students about AI use in assessed work. That is the right order of operations. Access without policy creates ambiguity; policy without access becomes theater.In universities, ambiguity around AI quickly becomes unfairness. If one course permits AI brainstorming and another bans all AI assistance, students may encounter wildly different expectations under the same institutional banner. If staff members rely on private judgment alone, assessment rules become inconsistent and hard to defend. A common framework does not eliminate discretion, but it gives that discretion a floor.
The policy emphasis also reflects a deeper institutional concern: Microsoft 365 Copilot is not just a productivity product but a cultural accelerant. Once staff become comfortable using AI to draft, summarize, classify, and synthesize, students will reasonably ask why similar affordances are forbidden, restricted, or unevenly available to them. The university cannot roll out Copilot to academics and pretend the classroom implications are separate.
That is why Manchester’s student-facing language is careful. The university says it is working with students through a Copilot Student Advisory Group and broader engagement activity over the summer. It is also developing a “Test, Learn and Adapt” study to generate evidence about responsible and effective student introduction, including support models, communications, academic guidance, and safeguards.
This is slower than the most enthusiastic AI advocates would prefer. It is also more responsible than simply declaring that students must be “AI ready” and throwing a tenant-wide switch. The university appears to understand that equity in access is not the same thing as equity in outcomes. If some students arrive with strong AI literacy and others do not, a nominally universal rollout may still widen gaps.
Copilot’s Real Campus Test Is Not Whether It Can Draft a Paragraph
The easiest Copilot demonstrations are also the least important. Draft an email. Summarize a meeting. Turn bullet points into a polished memo. Generate a first pass at a presentation. These are useful tricks, and in aggregate they may save time, but they are not where the institutional stakes sit.The real test is whether Copilot changes how knowledge work is organized. In a university, that means teaching preparation, research administration, grant development, ethics paperwork, supervision, student communication, literature handling, committee work, and the endless internal documentation that keeps large institutions moving. Copilot’s promise is not that each task becomes miraculous. It is that enough low-friction assistance accumulates to change the texture of work.
That promise is plausible. Universities are full of highly skilled people who spend too much time translating ideas into institutional formats. An AI assistant that helps draft, summarize, compare, and retrieve can be genuinely useful in that environment. Postgraduate Researchers, in particular, may find value in turning sprawling notes into plans, converting feedback into action lists, or navigating administrative documents.
But the same environment is full of traps. Research work often involves unpublished ideas, sensitive data, third-party materials, and disciplinary norms that do not map cleanly onto corporate productivity assumptions. Teaching work involves students, assessments, accommodations, and academic integrity. Copilot can reduce friction, but friction sometimes exists for a reason.
The question, then, is not whether Copilot can produce fluent text. It plainly can. The question is whether users understand the difference between fluency and reliability, between a helpful draft and an authoritative answer, and between private productivity and accountable academic work. That is where Manchester’s live training and policy framing become more than administrative garnish.
Microsoft Gets a Showcase, But Manchester Owns the Consequences
For Microsoft, university-wide Copilot deals are strategically valuable. Education is not just another vertical market; it is where habits are formed, future workers are trained, and institutional legitimacy is built. If Copilot becomes normal inside universities, Microsoft gains more than license revenue. It gains a generation of users who see AI assistance as part of the Microsoft 365 workspace.Manchester’s January announcement framed the collaboration as a sector-first effort to provide broad access and training across the university community. Since then, the rollout has progressed through cohorts, with Professional Services earlier in the year and now Teaching, Research, and PGR groups. The sequencing suggests a controlled adoption model rather than a single dramatic launch.
That matters because the risks are distributed unevenly. Professional Services teams may face governance, privacy, records, and operational issues. Teaching and Research colleagues face those too, but they also sit closer to the university’s academic mission. Once Copilot enters lecture planning, feedback workflows, research development, and postgraduate supervision, it becomes harder to separate “digital transformation” from the core business of the institution.
Microsoft can supply product documentation, dashboards, admin controls, and responsible AI language. It cannot decide what counts as appropriate use in a particular seminar, lab, dissertation meeting, or exam context. That burden stays with the university. The vendor sells the platform; the institution inherits the edge cases.
This is why Manchester’s emphasis on feedback is important. The announcement repeatedly signals that the rollout has been adapted based on concerns and practical considerations. That is not merely change-management language. In AI deployments, feedback is a control mechanism. Without it, organizations learn about failure through incidents rather than iteration.
The Security Story Starts With Permissions, Not Prompts
For WindowsForum readers, the Copilot conversation inevitably turns to administration. Microsoft 365 Copilot’s value depends on the Microsoft Graph and the data already available to a user through Microsoft 365. That means it generally respects existing permissions, but it also means bad permissions become more visible, more searchable, and more consequential.This is the classic AI deployment paradox. Copilot may not create an access-control problem, but it can reveal one at speed. A user who technically had access to an old SharePoint site, forgotten Teams channel, or poorly governed document library may never have found anything sensitive before. An AI assistant designed to retrieve and summarize information changes that equation.
Universities are especially exposed to this kind of entropy. They are large, federated, historically layered organizations with long-lived departments, research groups, committees, projects, and external collaborations. Files accumulate. Teams are created for short-term work and then persist. Permissions are inherited, copied, widened, and rarely reviewed with the discipline a security architect would like.
That does not mean Copilot should be blocked until every permission is perfect. If that were the standard, no large organization would deploy anything. It does mean the rollout has to be accompanied by sober work on information governance. The magic phrase here is not “prompt engineering.” It is least privilege.
Training users to ask better questions is useful. Ensuring they cannot accidentally surface material they should not see is essential. The operational burden falls on Microsoft 365 administrators, records managers, data protection teams, and local IT units that already have too much to do. AI does not replace that work; it makes the backlog harder to ignore.
The Student Rollout Is Where the Politics Get Harder
Manchester’s announcement is careful to distinguish the current staff and PGR phase from any future student rollout. That distinction will not hold forever. If staff are being trained to use Copilot responsibly, students will expect clarity about whether similar tools are part of their learning environment, their employability preparation, or their assessment risk.The university’s summer work with the Copilot Student Advisory Group is therefore more than consultation. It is a recognition that students are not merely downstream users. They are affected by how staff use AI, how assessment rules are communicated, how feedback is generated, and how access is distributed. A student may never touch Copilot and still experience its effects if their course team uses it in preparation or communication.
The phrase “designed with students” is doing important work here. It implies that student rollout cannot be designed solely by IT, procurement, or senior leadership. Students will have practical questions that differ from staff concerns. Will Copilot be allowed for brainstorming? For coding help? For grammar? For summarizing readings? For revision plans? For assessed work if declared? For students with disabilities or language barriers?
Those questions are not solved by a license. They require academic judgment, disciplinary nuance, and clear communication before the new academic year. The worst possible outcome would be an environment where AI use is common, detection is unreliable, rules are inconsistent, and students infer norms from rumors. That is how trust drains out of assessment.
Manchester’s planned Test, Learn and Adapt study is a sensible hedge against that. It admits that the university does not yet know the best way to introduce Copilot to students at scale. That admission is a strength, not a weakness. In 2026, institutional AI certainty is often less credible than institutional humility.
“Responsible AI” Is a Process, Not a Slogan
Every major technology vendor now speaks the language of responsible AI. The term appears in product pages, policy documents, procurement decks, and executive speeches. The problem is that “responsible” can become so elastic that it describes almost any rollout with a training page and a warning label.Manchester’s announcement is stronger because it ties responsibility to specific mechanisms: live learning, guidance, advisory groups, student engagement, policy development, feedback forms, and iterative adaptation. None of these guarantees success. Together, they suggest the university understands that responsible use has to be operationalized.
That is the key lesson for other institutions watching Manchester. A Copilot rollout is not responsible because it is slower, nor irresponsible because it is ambitious. It becomes responsible when the organization can explain who gets access, what training they receive, what data protections apply, how policy governs use, how concerns are escalated, and how the deployment changes when reality contradicts the plan.
The uncomfortable part is that responsibility is labor-intensive. It requires meetings, documentation, training design, support channels, evaluation, and ongoing revision. It demands that leaders listen to skeptics without letting skepticism become paralysis. It also demands that enthusiasts accept boundaries without treating every guardrail as fear.
That may be the biggest cultural shift Copilot forces. The product is marketed as a personal assistant, but safe adoption is collective. One person’s convenience can become another person’s exposure, confusion, or unfairness. In a university, where individual autonomy and institutional accountability constantly rub against each other, that tension is unavoidable.
The Numbers Manchester Should Watch Next
Manchester has shared encouraging early training metrics, but the next phase will require harder measurements. Session attendance and confidence are useful starting indicators, especially during a rollout. They do not prove that Copilot is improving work, reducing burden, protecting data, or supporting better teaching and research.The university should now be looking for evidence in the messy middle. Are staff saving time on low-value administrative work, or merely producing more polished drafts that still require the same review burden? Are PGRs using Copilot to structure work more effectively, or are they becoming more dependent on generic synthesis? Are support tickets rising because users are confused, or falling because training is working?
There is also a need to measure negative space. Are some staff opting out because of principled concerns, accessibility barriers, workload pressure, or lack of perceived relevance? Are certain departments adopting Copilot much faster than others? Are researchers in sensitive fields more cautious, and if so, is the support model meeting them where they are?
The most important metrics may be qualitative. A good rollout should surface stories of both success and discomfort. The success stories show where the tool fits real work. The discomfort shows where policy, training, data governance, or product design has not caught up. If the feedback loop is healthy, both kinds of evidence should shape the next iteration.
Manchester’s own language suggests that it knows access and training are only the start. That is exactly right. The first serious milestone is not the day users receive Copilot. It is the day the institution can say what changed because they did — and what it changed in response.
The Campus Copilot Experiment Has Already Moved Past the Demo Stage
Manchester’s latest rollout update gives other universities and enterprise IT teams a useful, concrete picture of AI adoption after the press release. The lesson is not that every organization should copy Manchester’s schedule. The lesson is that broad AI access without governance is reckless, while governance without lived use is abstract.- Manchester has extended Microsoft 365 Copilot access to Teaching and Research colleagues and Postgraduate Researchers as of June 2026.
- The university says more than 4,000 colleagues have attended live learning sessions, with reported confidence rising sharply after training.
- The rollout is being shaped through faculty engagement, the CoCoA advisory group, user feedback, and dedicated support rather than treated as a one-time IT switch.
- The AI in Teaching and Learning Policy is central because Copilot’s effects will reach assessment, student expectations, and academic practice even before every student has access.
- The planned student engagement and Test, Learn and Adapt study show that the hardest part of the rollout is not licensing Copilot, but deciding how it belongs in learning.
- For administrators, the practical risk remains information governance: Copilot can make existing Microsoft 365 permissions and data hygiene problems more visible and more urgent.
References
- Primary source: The University of Manchester
Published: Fri, 19 Jun 2026 09:30:35 GMT
Microsoft 365 Copilot rollout: Teaching, Research and PGRs | StaffNet | The University of Manchester
www.staffnet.manchester.ac.uk
- Official source: microsoft.com
Learn about Copilot in Education | Microsoft Education
Discover how Microsoft 365 Copilot and Copilot Chat enhance teaching, boost productivity, and engage students as AI tools for teachers. Get started for free.www.microsoft.com
- Official source: blogs.microsoft.com
Introducing the First Frontier Suite built on Intelligence + Trust - The Official Microsoft Blog
Today Microsoft is announcing: Wave 3 of Microsoft 365 Copilot Expanded model diversity with Claude and next-gen OpenAI models available today General availability of Agent 365 on May 1 for $15 per user General availability of the new Microsoft 365 E7: The Frontier Suite on May 1 for $99 per...blogs.microsoft.com - Official source: learn.microsoft.com
Manage Microsoft 365 for Education AI Features - M365 Education | Microsoft Learn
Learn how to manage Microsoft 365 for Education AI features.learn.microsoft.com - Related coverage: le.ac.uk
Microsoft collaboration puts University of Leicester at the forefront of AI in education | News | University of Leicester
Leicester has become one of the first universities in the UK to roll out full access to Microsoft 365 Copilot across its entire community.le.ac.uk - Related coverage: windowscentral.com
Microsoft scraps Copilot 365 app auto‑install on Windows 11 | Windows Central
Microsoft won't force the Microsoft 365 Copilot app on Windows 11 for now.www.windowscentral.com
- Related coverage: techradar.com
Microsoft gives students free access to premium AI tools and career resources for an entire year, starting now | TechRadar
Microsoft 365 deal expires soon, so act fastwww.techradar.com - Related coverage: tomshardware.com
Microsoft offers a one-year free Microsoft 365 subscription to college students — eligible users get 50% off the monthly plan after the first year | Tom's Hardware
This promo will save you $100 for the first year of Microsoft 365.www.tomshardware.com - Related coverage: documents.manchester.ac.uk
- Official source: cdn-dynmedia-1.microsoft.com
Slide 1: Copilot in Education: Impact on the Student Learning Experience
PDF documentcdn-dynmedia-1.microsoft.com
- Related coverage: educatorstechnology.com