# JMO|Partners — full site content
> London-based IT consultancy serving small and mid-sized businesses across Greater London and the home counties. Four practices: Managed Services, AI Enablement, Security Solutions, Consulting Services. This file concatenates the homepage, the four service pages (Managed Services, AI Enablement, Security Solutions, Consulting Services), the FAQ, the pricing page, and every published Insights post into a single document for efficient agent ingestion. Generated 2026-05-25.
---
# Homepage
Source: https://jmo.partners/
JMO|Partners — Managed IT Services, AI Enablement, Cyber Security & Consulting · London
Skip to main content
Services
About
Insights
Resources
Get in touch →
01 Services
02 About
03 Insights
04 Resources
Get in touch →
Managed Services · AI Enablement · Security Solutions · Consulting Services
Enterprise
IT,
sized
for
SMEs.
We're a team of IT professionals founded by three lifelong friends — built to give small and medium-sized businesses the same expertise, innovation and personalised service usually reserved for larger corporations.
Start a conversation →
Explore services
0
Lifelong friends.
One mission.
0
Industries our
founders span
0
Specialist services
under one roof
1–0
Team sizes
we serve
// 24 capabilities, one team
Artificial Intelligence
Network Management
IT Strategy & Planning
Hardware & Software Procurement
Data & Information Security
Server Management
Patch Management
Vendor Management
Website Design
Data Backup
Virtualisation
Custom PC Building
Cloud Services
Remote Monitoring
Project Management
IoT Management
Physical Security
Mobile Device Management
Managed Email Services
Managed Print Services
IT Support & Helpdesk
VOIP & Unified Communications
Data Cable Termination
Training & Education
Artificial Intelligence
Network Management
IT Strategy & Planning
Hardware & Software Procurement
Data & Information Security
Server Management
Patch Management
Vendor Management
Website Design
Data Backup
Virtualisation
Custom PC Building
Cloud Services
Remote Monitoring
Project Management
IoT Management
Physical Security
Mobile Device Management
Managed Email Services
Managed Print Services
IT Support & Helpdesk
VOIP & Unified Communications
Data Cable Termination
Training & Education
// Hover any capability to see what it does
01 — Service areas
Four core practices, built around
your business.
From day-to-day support to long-term strategy, we tailor our services to fit teams of any size — whether you're a one-person startup or a 250-person operation.
01 / Managed Services
Managed Services
More than IT support — strategic partners in your success. Whether your team is 1 or 250, we deliver network security, cloud migration, proactive monitoring and rapid response. We keep your systems running smoothly so you can focus on growth, not downtime.
02 / AI Enablement
AI Enablement
Practical AI rollouts of Google Gemini, Anthropic Claude, OpenAI ChatGPT and Microsoft Copilot into the workflows you already run. The kind that saves real hours, with the information security and policy backing to do it properly. No strategy decks.
03 / Security Solutions
Security Solutions
Specialised IT security tailored for SMEs. Cost-effective measures to safeguard your assets and data, aligned with your budget and goals. From essential protocols to ongoing support, we handle your security so you can focus on growth with confidence.
04 / Consulting Services
Consulting Services
Bespoke IT consultancy for SMEs. We integrate networking, client systems, CCTV, on-premise and cloud storage. Whether you're starting out or upgrading, we assess your infrastructure, identify improvements, and align solutions with your goals and budget.
02 — Why JMO|Partners
The standards we hold ourselves to, on
every project.
Four principles that shape how we work, from the first conversation to long-term partnership.
PILLAR 01
Expertise & Experience
A team of seasoned professionals with deep experience across the IT industry — from network security to cloud solutions, equipped to tackle complex IT challenges.
PILLAR 02
Tailored Solutions
Every business is unique. We take the time to understand your specific needs and adapt our services to fit, whether you're a small startup or a larger enterprise.
PILLAR 03
Client Satisfaction
Customer satisfaction is our top priority. From initial consultation through ongoing support, our dedicated team is always available to answer questions and provide assistance.
PILLAR 04
Seamless Integration & Support
We build long-term relationships. Our work doesn't end when a project ships — implementation, training and troubleshooting are part of the partnership.
03 — Who we are
Three friends.
One shared mission.
JMO|Partners was founded by three lifelong friends with a shared passion for technology and a commitment to helping businesses thrive. Our founders' careers span small startups, medium-sized enterprises and large corporations across a range of industries.
We came together to address a common concern: the lack of attention and tailored services available to small and medium-sized enterprises in the IT industry. SMEs are the backbone of the economy — yet they're often overlooked when it comes to accessing the kind of best-in-class IT solutions that can fuel real growth.
That's why we built JMO|Partners, to give SMEs the same expertise, innovation and personalised service typically reserved for larger corporations, and to build genuine long-term relationships rather than just deliver services.
// The 10 most relevant to SMEs — tap any to see how we work
Digital Media
Financial Services
Fintech
Healthcare
Hospitality
Manufacturing
Pharmaceuticals
Professional Services
Property Management
Recruitment
Render queues, terabyte project files, freelancers in and out by the week. 10GbE where it earns its keep, and asset access that closes the moment a contract ends.
FCA reviews, SAR deadlines, no margin for a stray email to the wrong client. Locked-down endpoints, encrypted comms, and audit trails that survive the inspection.
Investors and enterprise buyers ask SOC 2 questions before you've finished your coffee. We build the controls that make the answers easy.
EMIS or SystmOne running alongside a Windows 10 box that nobody dares update. We secure the lot and keep the NHS Spine integrations working.
Legacy POS, kitchen printers, seasonal staff in and out every quarter. We modernise the stack without taking down Friday-night service.
Shop-floor systems, ERP integrations, every minute of downtime billed in lost output. We bridge office IT and the line without making either fragile.
Validated systems, MHRA inspections, every change tracked through CSV. Hardened IT around the GxP estate — without adding a week to every change request.
Client confidentiality is the product, and one leaked draft contract ends the relationship. Secure document management, locked-down laptops, and email that behaves itself.
Block managers chasing Section 20 notices, contractors in and out of buildings, tenant data sat in a shared inbox. We tidy the systems, lock down the access, and keep portfolio data where it should be.
Bullhorn that can't go down on a Tuesday, CVs landing from LinkedIn, email and four job boards, GDPR over the lot. Backups that actually restore, and access that leaves with the leaver.
// Founders
Built for the businesses that big IT firms forget.
SMEs are the backbone of the economy, yet they're often overlooked when it comes to best-in-class IT, and bridging that gap is the reason we exist.
— The JMO|Partners founders
04 — What we do
The full picture of
what we deliver.
Twenty-four services spanning the day-to-day, the cloud, and the strategic. We can handle one or all of them.
Core IT & Support
08 services
Network Management +
Design, monitoring and maintenance of your wired and wireless networks. Keeps everyone connected, fast, and secure across the office or remotely.
IT Support & Helpdesk Services +
A first port of call when something breaks. Tickets, troubleshooting and on-the-spot fixes — handled by people who know your setup.
Server Management +
Configuration, monitoring and upkeep of the servers your business runs on. Includes performance tuning, capacity planning and patching.
Hardware & Software Procurement +
We source the right hardware, software and licences at the right price — and handle the negotiation, contracts and lifecycle for you.
Managed Print Services +
A managed approach to printers, copiers and consumables. Lower per-page costs, fewer outages, predictable monthly billing.
Training & Education +
Onboarding, upskilling and ongoing IT training for your team — tailored to the tools you actually use.
Vendor Management +
One point of contact for every IT vendor in your stack. We chase, escalate and negotiate so your team doesn't have to.
Data Cable Termination +
Professional structured cabling — Cat6, Cat6a and fibre installation, patch panels and terminations. Clean, labelled and certified work that won't need re-doing in two years.
Cloud & Communications
08 services
Managed Email Services +
Setup, security and ongoing management of business email — including spam filtering, archiving and migration between providers.
VOIP & Unified Communications +
Cloud-based phone systems and unified messaging — voice, video, chat and conferencing across one platform.
Cloud Services +
Migration, hosting and management of your apps and data in the cloud — Microsoft 365, Google Workspace, AWS and beyond.
Mobile Device Management (MDM) +
Centralised control over phones, tablets and laptops. Push policies, wipe lost devices, deploy apps remotely.
Remote Monitoring & Management (RMM) +
24/7 oversight of your systems with automated alerts and remote intervention — issues spotted and fixed before you notice them.
Physical Security +
Physical security for your premises — CCTV systems, access control and visitor management. Specified, installed and maintained, with everything tied into your IT estate.
Custom PC Building +
Specification and assembly of high-spec workstations for engineering, design, finance, gaming or any specialist need.
Website Design +
Modern, responsive websites built faster with AI-powered design tools and hands-on craft. From brochure sites to lead-generating funnels — ready to launch in days, easy to update, built to convert.
Strategy & Advanced
08 services
IoT (Internet of Things) Management +
Connecting and managing smart devices — sensors, cameras, environmental controls and beyond — into your existing IT estate.
Artificial Intelligence +
Practical AI integration into business workflows — automating routine work, surfacing insights, and identifying real efficiency gains.
IT Strategy & Planning +
A clear, costed IT roadmap aligned to your business goals — what to invest in, what to retire, and when.
Virtualisation +
Consolidating servers, desktops or storage into virtual environments — reducing hardware costs and improving flexibility.
Patch Management +
Keeping every system up to date with security and stability fixes, scheduled around your operations to avoid downtime.
Project Management +
End-to-end management of IT projects — migrations, rollouts, office moves — delivered on time and within scope.
Data Backup +
Reliable, tested backups of business-critical data with rapid recovery if anything goes wrong. Cloud, on-prem or hybrid.
Data & Information Security +
Delivered by an experienced information security consultant — end-to-end security for your data and systems. Firewalls, endpoint protection, user access controls and permissions, with everything aligned to information security best practice. Defence in depth, sized to an SME budget.
05 — Client voices
What our
clients say.
"
The team vastly improved our remote working capabilities, leading to our small business operating perfectly 24/7.
BF
Ben Fisher Furniture Shop Owner
"
We needed to move cloud service providers. JMO were extremely knowledgeable and quick in devising a solution and executing it.
RM
Robert McFarlane Gas Engineering Company Director
"
We had poor wifi across our site reducing productivity. JMO created a plan to fix it, sourced new hardware, installed and configured it in a short space of time.
RO
Rheece Oscar Construction Site Manager
Insights
Things we've learned running IT for SMEs.
Field notes, decision frames, and the occasional story. Written by the JMO|Partners founders.
Insights
Two years of UniFi rollouts — what we'd keep and what we'd swap
Thirty-odd UniFi sites in two years. The honest retrospective.
Insights
AI tooling for SMEs — where it's earning its keep, where it isn't
A year in. The pattern of what's actually paying back.
Insights
Cyber-insurance underwriting in 2026 — what changed
The questionnaire used to be a formality, and it isn't any more.
Browse all insights →
Download resources →
Let's build something
Ready to hand IT to someone
who's done it before?
Tell us about your business and what you need.
We'll be in touch to start the conversation.
Name *
Company
Email *
How can we help? *
Send enquiry →
Message received
Thanks — we'll be in touch shortly. In the meantime, you can reach us directly at info@jmopartners.co.uk .
Or email us directly at info@jmopartners.co.uk
IT solutions tailored for small and medium-sized businesses.
Services
Managed Services
AI Enablement
Security Solutions
Consulting Services
Company
About
What we do
Insights
Resources
Contact
Get in touch
info@jmopartners.co.uk
LinkedIn
X (Twitter)
Instagram
EST 2024 · LONDON
© 2026 JMO Partners Ltd · Company No. 15592258
Enterprise IT, sized for SMEs.
---
# The four kinds of IT debt every SME carries
Practice: Consulting Services
Author: Oliver
Date: 2026-05-26
Tags: it-debt, scorecard, renewals, documentation, asset-management, resilience, MFA, runbooks, cyber-insurance, sme
URL: https://jmo.partners/insights/four-kinds-of-it-debt/
End of month is when IT debt becomes visible. The certificate that expires on a Saturday. The auditor's request for a network diagram nobody drew. The leaver who took the WiFi password with them. The work isn't dramatic, but the bill always lands somewhere.
## What we mean by IT debt
The phrase is borrowed from finance for a reason. IT debt is the bill that arrives whenever the gap between what an estate runs and what it has documented has to be paid. It isn't theoretical, and it isn't framed as such on the day it lands. It looks like a sales team locked out of their CRM at 09:00 on a Monday because the SSL certificate expired over the weekend and the renewal reminder went to an inbox that was decommissioned eighteen months ago.
I have seen this play out across a dozen SMEs over the last several years. The shape is always the same. Work that could have been done in a planned half-day three months earlier instead consumes two weeks of crisis time, a vendor call-out fee, and a fair amount of standing in the corridor explaining what happened to people who don't care about the explanation, only the disruption.
The scorecard at the end of this post breaks IT debt into four categories. They map to where the work tends to build up. Most SMEs we work with score badly in one category and then somewhere between adequate and bad in the others; the categories feed each other.
## Staffing and time debt
One person knows where everything lives. The MFA seeds for the firewall, the recovery codes for the M365 tenant, the supplier account for the printer fleet. They are good at their job, they hold a great deal in their head, and the firm has been steadily growing for years on the assumption that the situation is stable. The assumption holds until they take a new job, get ill, or retire. The day the IT lead hands in their notice is the day the firm discovers it was running on tribal knowledge rather than documentation.
In one estate I supported, rotating an AD admin password after the office manager left took six weeks of vendor calls because the rotation procedure was a sequence of steps she carried in her head. The handover document existed; it described the wrong systems.
Time debt sits next to staffing debt. If the IT person is spending more than half their week firefighting, the debt is compounding while you read this. Firefighting time is what would otherwise have gone to the runbook, the certificate inventory, the quarterly review of admin accounts. Each hour of crisis time is two hours of debt that didn't get paid down.
## Renewals and cycles debt
Certificates, licences, cyber-insurance, Cyber Essentials Plus, hardware refresh cycles. Each carries a date the business often doesn't know yet. The renewal reminder doesn't go missing because somebody is careless; it goes missing because the renewal email lands in a personal inbox of someone who left two roles ago, or in a shared mailbox that no one has owned since the procurement team restructured.
Cyber-insurance is where renewals debt becomes visible to the board, because the questionnaire arrives with thirty-eight questions about MFA, backup testing, patch cadence, admin account inventories, and supply chain controls. Half of those questions ask for documentation that doesn't exist. The questionnaire deadline is three weeks. The work to actually answer them with evidence is closer to three months. The shortcut everyone is tempted by, ticking what you wish were true, is exactly what voids the policy at claim time.
Hardware cycles drift in a related way. A laptop refresh that was approved in the 2024 budget gets pushed twice, and the helpdesk starts seeing the same five machines come back every fortnight with the same intermittent fault. The refresh would have cost twenty-five thousand pounds once; the deferrals cost eight thousand a year in lost hours, then the twenty-five thousand anyway, two years later.
## Asset-management debt
What devices do you own. What cloud services do you pay for. What rooms do which switches feed. None of those are exotic questions, and yet most SMEs we audit cannot answer all three in writing.
The shape this debt takes is auditors and insurers asking for a register and getting either a spreadsheet that was last edited in 2022 or, more commonly, a long pause followed by a polite request to come back next quarter. It isn't the absence of the register that costs the firm; it's the four weeks of someone's time that gets eaten reconstructing it under deadline pressure.
Account hygiene sits in the same family: leavers should be off the systems by close of business on their final day. In practice, ex-staff still have inbox access six months later because the offboarding procedure is a conversation rather than a checklist. The risk is obvious; the work to fix it is a quarterly review of a small spreadsheet and an hour of disabling accounts. Most teams agree it should happen, and most teams don't have it on a calendar.
## Documentation and resilience debt
The most expensive of the four, because it only becomes visible when something has already gone wrong.
Runbooks for disaster recovery, password recovery, backup restores. If those documents exist at all, they often live on the IT lead's laptop rather than in a shared location, and they describe the system the firm had three years ago. Backup restores that have never been tested aren't actually backups. They look like backups, on paper, until the first time you try to run one against a real outage.
MFA on admin accounts is the canary, because user accounts almost always have it enabled by now. Admin accounts often don't, on the grounds that admins are technical enough not to need it. Admin accounts are also the ones that, when compromised, cost the firm the entire estate. The fix is fifteen minutes per account and a calendar entry to review quarterly. The debt is the months it takes to schedule that fifteen minutes.
## Why these compound
The four categories aren't independent. Staffing debt makes renewals debt worse, because the one person who tracks the dates is also the one whose successor isn't named. Asset debt makes documentation debt worse, because you cannot write a runbook for a system you cannot list. A firm that scores cleanly on one category and badly on the others is rare; in our experience, the score is consistent across all four or it isn't.
That's why the scorecard treats the four categories as one diagnostic. The total tells you how much debt the estate is carrying. The breakdown tells you which corner is bleeding fastest.
## The scorecard
Twenty questions in four categories of five. Five minutes. Each answer scores 0, 1, 2 or 3 points, so the total runs from 0 to 60. A band score and a short list of next actions follow.
[Download the IT Debt Self-Scorecard](/downloads/scorecards/it-debt-self-scorecard.pdf).
If you'd prefer the visual version of the same diagnostic, the [IT Debt Spiral infographic](/downloads/infographics/it-debt-spiral-infographic.pdf) maps the same four categories as a single page showing how each kind of debt feeds the next.
The scorecard is for whoever owns the consequences. If you're the IT person, you already know most of the answers and the scorecard tells you which case to make to the budget holder. If you're the ops director or the CEO and IT has been somebody else's problem until the auditor asks for the network diagram, the scorecard gives you a structured way to find out where the firm actually stands without having to sit through a vendor pitch first.
## What to do with the score
Higher totals mean more basics in place. The scorecard maps to three bands.
Forty-one to 60 is the healthy band. The basics are covered: a named IT lead, a renewal calendar, someone who could pick up the phone if the lead were away. The few questions where you scored low are the punch-list, and they are the cheap wins. Re-run the scorecard quarterly. The work is keeping the score where it is rather than letting it slide back over twelve months.
Twenty-one to 40 is the carrying-debt band, where most of the SMEs we audit actually land. The system is running but it depends on a small number of people remembering things. A leaver, a missed renewal, or a failed restore would hurt. Build one master spreadsheet of devices, licences, and renewal dates this month. Document the top three runbooks. Identify a second pair of hands, internal or external. Run a backup-restore test in the next 90 days with someone other than the IT lead present.
Zero to 20 is the at-risk band. Critical knowledge sits with one person, renewals arrive unannounced, and there is no documented recovery path. A single resignation or a single audit could become a crisis. The priority is removing single points of failure rather than optimising anything else. Stop adding systems, write down what you have, and bring in external help for a four-week handover audit if the IT lead might leave.
In each band, the scorecard PDF lists the next three or four actions to take. Bring the result to whoever owns the budget. The list is harder to argue with than the conversation.
---
*If you ran the scorecard and the result was uncomfortable, that's our [Consulting Services](https://jmo.partners/#services) practice. We'll walk the estate with you, prioritise the worst categories, and either do the documentation work or sit alongside whoever does. Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk) and we'll start the conversation.*
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# You don't write the code, but you carry the risk: SME supply chain attacks after TanStack
Practice: Security Solutions
Author: Matthew
Date: 2026-05-24
Tags: security, supply-chain, npm, tanstack, SBOM, dependencies, browser-extensions, SaaS, OAuth, DNS, NIS2
URL: https://jmo.partners/insights/tanstack-supply-chain-sme/
## What just happened
In the second week of May 2026, a maintainer's compromised npm token was used to publish malicious versions of several @tanstack packages. TanStack is one of those names most non-developers have never heard of. Its tools, including the data-fetching library TanStack Query, sit deep inside a long list of business software: customer-facing web apps, internal dashboards, admin tools, e-commerce front-ends. The malicious versions stayed in the npm registry for a number of hours before being pulled. In that window, anything that ran `npm install` against the affected packages pulled in the bad code. Build pipelines pushed it into production. Browser bundles served it to end users.
It was a small attack by tech-press standards; the wider pattern is what matters.
In late 2025 a worm dubbed "Shai-Hulud" propagated through npm, compromising hundreds of packages by stealing maintainer credentials and using them to publish poisoned updates. Earlier, the polyfill.io domain was sold to a new owner who promptly modified it to serve malware to every site that embedded its script, and many sites did, because polyfill.io had been a Stack Overflow-recommended way to support older browsers. Going back further, the ua-parser-js compromise in 2021 reached an estimated seven million weekly downloads before being caught. The names change, but the shape is the same. A trusted upstream (a package, a library, a CDN, a browser extension) becomes the delivery mechanism for an attacker who can't reach the target directly. The defenders are doing nothing wrong by their own previous standards. The trust model itself has been weaponised.
## "But we don't write code"
The instinct for most SME owners reading this is reasonable: we don't ship software, we don't run npm, this isn't our problem. The instinct is wrong, in three concrete ways.
First, the line-of-business SaaS you pay for is built on npm. When the project-management tool your team uses lists fifteen integrations on its website, any one of those is the way TanStack-style code can land inside the tool. The vendor's secure-development discipline becomes your secure-development discipline, whether you knew that or not. The 2026 cyber-insurance questionnaire is starting to ask SaaS suppliers about exactly this, with the expectation that you'll be able to ask the same questions of yours.
Second, the website your agency built pulls third-party scripts on every page load. Analytics tags, chat widgets, marketing-automation pixels, payment SDKs, recommendation engines, the cookie banner itself. Every one of these is JavaScript that runs in your visitor's browser with the same access to your visitor's data that your own site has. A compromised polyfill is a compromised checkout form.
Third, browser extensions auto-update across your fleet without anyone noticing. The PDF-editor extension a member of your finance team installed two years ago is on its forty-third version by now. If the developer has been bought out, breached, or simply changed direction, the extension can read every page your team views, including the Workspace tab they have open right now.
The exposure isn't "you might get hacked by a developer". The exposure is that the software you've trusted, by paying for it, embedding it, or installing it, is now the attack surface, and you have no direct relationship with the malicious party.
## Four places to look first
There are four practical places to do this work, and most SMEs have done none of them.
**1. Browser extensions across the org.** Both Google Workspace and Microsoft Intune let an admin force an allowlist of approved extensions and block everything else. Most SMEs have neither configured. The starting work: enumerate what's actually installed across your fleet (both admin consoles expose this), trim aggressively, lock the remainder. Treat new extension requests the same way you treat new SaaS requests: a small ticketed review, not a free choice. The founders have shipped this configuration at every IT-leadership posting we've held; the friction is one team conversation followed by a quiet estate.
**2. SaaS OAuth scopes and audit logs.** Every SaaS your team has connected to Workspace or Microsoft 365 has a set of scopes it can use: read calendar, send email, access Drive, modify files. Most SMEs granted these scopes once at sign-up and have never reviewed them since. Open the OAuth-applications list in Workspace or Entra, review what's connected, revoke what's no longer in use, and tighten anything with scopes wider than the job it does. Pair this with a quarterly review of the SaaS vendor list itself: what they hold, where they hold it, what their last security incident was.
**3. Internal or agency-built apps: SBOM, version pinning, dependency scanning.** This is the area most relevant to anyone running custom development work. SBOM (Software Bill of Materials, a structured list of every dependency a piece of software pulls in) is mandated under the EU Cyber Resilience Act, and increasingly expected under NIS2 supply-chain obligations, for anything sold or operated in the EU. For the apps your business runs or commissions: ask your developer or agency for an SBOM, for evidence of version pinning (specific versions in lockfiles, not floating ranges that resolve to whatever-is-latest at install time), and for dependency scanning in their build pipeline. If they can't produce these, that's the start of the conversation about their security posture, not the end of it.
**4. Outbound DNS and network monitoring, the post-compromise tripwire.** Supply chain attacks are designed to evade the perimeter, so the first signal that something has gone wrong is almost always traffic going somewhere it shouldn't: a script calling home to a server you didn't authorise, a laptop sending data to an attacker-controlled endpoint, a server beaconing on an hour-by-hour cycle. DNS-level filtering (Cisco Umbrella, NextDNS, Cloudflare Gateway) blocks known malicious destinations at the network layer and logs the rest. Add it to the SME tech stack, and review the alerts.
## The honest take
You will not prevent every supply chain attack. The TanStack window was hours, and any team running automated builds during it ingested the bad code regardless of how careful their dependency hygiene was on every other day of the year. What changes between the SME that handles this well and the one that doesn't is two things: how much blast radius the attack has when it lands, and how quickly anyone notices.
Blast radius shrinks with the inventory work. An attack that hits your project-management SaaS is a problem. An attack that has OAuth access to your entire Drive estate is a crisis. A compromised browser extension on one user's laptop is recoverable; the same extension running across thirty users for six months is not.
Detection speed shrinks with the monitoring work. An SME that has DNS logs and reviews them weekly notices an anomaly in days. An SME that has neither notices it when a customer phones to ask why their card was charged twice.
## Where this lands for the next ninety days
A reasonable first-ninety-days plan, drawing on the conversations we've been having with SME clients this month:
- **Days 1-30.** Inventory extensions across Workspace or Intune. Force an allowlist, block everything else. Open the OAuth list, revoke the obvious dead apps, document what survives.
- **Days 30-60.** Ask the SBOM question of any agency or in-house developer. Get version-pinning and scanning answers in writing. Add the question to the next supplier onboarding form.
- **Days 60-90.** Pilot DNS-level filtering on one office or one user group. Review the first month of alerts. Make a decision on rolling it across the estate.
None of this prevents the next TanStack, but all of it shrinks the day-after fallout.
If you'd like help working through any of it, that's our [Security Solutions](https://jmo.partners/#services) practice. We'll either run it for you or sit alongside whoever does. Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk).
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# What Mythos changes, and what it doesn't
Practice: Security Solutions
Author: Matthew
Date: 2026-05-19
Tags: AI, security, frontier-AI, mythos, ncsc, patching, vulnerability-management
URL: https://jmo.partners/insights/mythos-moment-sme/
## What just happened
On 7 April, Anthropic announced [Project Glasswing](https://www.anthropic.com/glasswing) and a new frontier model called Claude Mythos Preview. Twelve launch partners (AWS, Apple, Cisco, CrowdStrike, Google, JPMorgan Chase, Linux Foundation, Microsoft, NVIDIA, Palo Alto Networks, Broadcom, and Anthropic itself) got access. Over forty additional vetted organisations followed. The model isn't being made publicly available. Anthropic considers the capability too dangerous to make publicly available.
In the weeks before the announcement, Mythos found thousands of zero-day vulnerabilities (previously unknown flaws in software that attackers can exploit before any patch exists). A 27-year-old bug in OpenBSD, one of the most security-hardened operating systems in the world, the one a lot of firewalls run on. A 16-year-old flaw in FFmpeg sitting in a line of code that automated testing tools had hit five million times without ever catching it. A privilege-escalation chain in the Linux kernel (a way for a low-level user to get full system control). A 17-year-old remote-code-execution flaw in FreeBSD's NFS server that the model both found *and* fully exploited, root access, no human steering after the initial prompt. Mozilla shipped a Firefox release patching 271 vulnerabilities found by the model in a single evaluation pass.
Separately, the UK's [National Cyber Security Centre and AI Security Institute](https://www.ncsc.gov.uk/blogs/why-cyber-defenders-need-to-be-ready-for-frontier-ai) ran a 32-step simulated network attack (estimated at around 14 hours for a human expert) against the seven frontier models released before March 2026. The best one averaged just under sixteen of those thirty-two steps. The generation before that averaged fewer than two. The cost of a single full attempt? Roughly £65.
What does it mean for a 30-person business in South London running Microsoft 365, UniFi, a couple of SaaS tools, and a partner accountant?
## What's actually new for an SME
As an SME you're a consumer of software rather than a writer of it, and the platforms you sit on top of (your operating systems, your browsers, your tenancy, your network kit, your line-of-business SaaS) are the ones with the bugs that just got easier to find.
That's the first thing that's changed. The rate at which vulnerabilities get *discovered* in widely-used software has accelerated. Some of those will be discovered by defenders working with vetted access to models like Mythos and patched through coordinated disclosure before they ever go public. Some will be discovered by attackers using cheaper, less safeguarded models (there are plenty of those) and weaponised before any patch ships. The NCSC's blunt summary is worth quoting: "Defenders should assume that at least some attackers already have access to capable AI tools."
The second thing that's changed is the *window*. CrowdStrike's CTO described it on the day of the Glasswing announcement: "The window between a vulnerability being discovered and being exploited by an adversary has collapsed — what once took months now happens in minutes with AI." The slack that used to sit inside an SME patch cadence has gone, and what was a quarterly rhythm is now the weekly one.
The third thing, and this is the one the headlines won't tell you, is the size of the coming patch wave. NCSC has a [follow-on blog](https://www.ncsc.gov.uk/blogs/prepare-for-vulnerability-patch-wave) flagging it explicitly. Decades of accumulated technical debt across operating systems, browsers, and infrastructure software is about to come out in patches in a sustained wave that NCSC are urging organisations to prepare for now. If your patching is monthly with no measured time-to-deploy, you're already behind, and the gap won't close this quarter because the new baseline is permanent.
## Three things to be sceptical of
Now the bit that needs scepticism. Within weeks of any frontier capability story, the marketing follows it out the door. Three things you'll hear in the coming months that we'd push back on.
First: "AI-resistant" product SKUs are mostly marketing. There's no defensive product you can buy that immunises you against AI-augmented attackers. The strong defences are still the boring ones.
Second: most breaches in 2026 are still going to look like 2024 breaches. Business email compromise (an attacker impersonating you or one of your team to redirect a payment or extract information), credential theft, phishing leading to ransomware via lateral movement (the attacker landing on one machine and then moving across your network to bigger targets). AI is a quality multiplier and a cost reducer on those attacks, with better-written phishing, faster reconnaissance, and cheaper attempts, rather than a wholesale transformation of the threat model. The Mythos-class threat is upstream, in the supply chain you depend on. Your day-to-day exposure looks the same as last year, but with phishing emails that read like the real sender wrote them.
Third: panic-buying tools doesn't help. The firms selling "AI-powered" defensive products are largely the same firms whose products you already have, rebadged. Tools matter less than posture.
## What an SME should be doing, now and going forward
There's a one-off audit, and there's a permanent posture shift. Both matter.
**The one-off audit, this month.** Do you have an accurate, current inventory of what you actually run? Operating systems, browsers, network kit, SaaS, line-of-business apps, anything internet-facing. Most SMEs don't. If you can't list it, you can't patch it. Second: what's your real time-to-patch, not "we apply updates monthly" but the measured median number of days between vendor release and your fleet being updated? Most teams that haven't measured this are surprised. Third: which of your suppliers have given you a clear answer on their own AI-era security posture? Cyber-insurance underwriters and CE+ (Cyber Essentials Plus, the UK government-backed certification) assessors are starting to ask.
**The permanent posture shifts.** Patching velocity becomes a KPI, not an event. Identity hygiene (MFA, multi-factor authentication, on everything; no shared credentials; clean offboarding) matters more, not less; credential theft is what AI-augmented attackers are best at scaling. Defence in depth (multiple overlapping layers so no single failure is fatal) assumes the upstream gets popped eventually; you want logs, alerts, segmentation, and a tested recovery plan so a single bad day doesn't become a six-month business event. Staff awareness training has to be updated for the era of phishing that *doesn't* have spelling mistakes. And vendor due diligence becomes a continuous question, not a one-off at procurement.
The NCSC's framing is the right one to internalise: AI won't compensate for weak security foundations, but it will amplify both strengths and weaknesses. The work to do is mostly the work you already knew to do, done more rigorously, measured more honestly, and treated as posture rather than project.
## The defender's structural advantage
There's a reason for optimism in NCSC's analysis that often gets lost in the scary headlines. Defenders have a structural advantage attackers don't: they shape the environment. They know what's installed, who should be logged in, what normal traffic looks like, where the data lives. AI used defensively exploits that advantage at scale. The same capabilities that make Mythos-class models dangerous in the wrong hands make them invaluable for finding flaws in your stack before someone else does. The firms that come out of the next two years well are the ones who treated the fundamentals as continuous discipline rather than tick-box compliance, and used the new tooling, defensively, to extend their reach. The cost of waiting for the next NCSC bulletin to start the work is a year of compounding exposure you don't get back.
If you're working through what your stack actually looks like and where the soft edges are, that's our [Security Solutions](https://jmo.partners/#services) and [Consulting Services](https://jmo.partners/#services) practices. We'll either do the work or sit alongside whoever does. Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk) and we'll set up a conversation.
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# Cyber-insurance underwriting in 2026: what changed and what's coming next
Practice: Security Solutions
Author: Oliver
Date: 2026-05-17
Tags: cyber-insurance, underwriting, security, MFA, MDR, compliance
URL: https://jmo.partners/insights/cyber-insurance-2026/
Three years ago a cyber-insurance renewal for an SME looked a lot like a motor renewal. A two-page form, a tick-box section on backups, a premium that moved a few percent either way. We had clients who genuinely didn't know what their cyber cover paid out for, because nobody had ever needed to find out.
That world is gone. We've sat in on around forty renewal conversations across the last eighteen months, some as the IT firm answering the technical sections, some as the people asked to explain why the previous answer wouldn't fly any more, and the shift has been steady and one-directional. Underwriters have got serious, the questionnaires have got longer, and the answers that were acceptable in 2023 are now the reason a premium doubles or a quote doesn't come back at all.
## Where the questionnaire is now
The current generation of underwriter questionnaires asks about seven or eight technical controls in real detail. The big ones, in roughly the order they cause trouble:
**multi-factor authentication (MFA, needing a code as well as a password) on every external service.** Email, VPN (virtual private network, the encrypted tunnel staff use to reach office systems from outside), remote desktop, the lot. "Most users" doesn't pass any more. Underwriters want to know what enforces it, what the exceptions are, and how exceptions get reviewed.
**Privileged access separation.** Admin accounts shouldn't be the same accounts people read email with. Two years ago this was a nice-to-have; now it's a yes/no question with consequences.
**Endpoint detection.** Traditional antivirus isn't enough. Underwriters want extended detection and response (XDR, a category of security tool that watches your endpoints, network and cloud for suspicious behaviour) or managed detection and response (MDR, the same thing run as a service by a security firm). If the answer is "we have Defender and we hope", the premium reflects it.
**Backups, with a wrinkle.** It isn't enough to have backups; they need to be tested, immutable or air-gapped (kept on a system the rest of the network can't reach), and recoverable inside a window the underwriter believes. The wrinkle is the recovery-time question, and it's a hard one to answer honestly without having done a restore.
**Patching cadence.** Specifically for internet-facing systems. Underwriters now ask how long between a critical CVE (common vulnerabilities and exposures, the public ID assigned to a specific software flaw) landing and the patch being applied. Anything over fourteen days gets pushed back on.
**Email security stack.** Domain authentication (SPF, DKIM, DMARC, the three email-authentication settings that tell other mail servers your messages are genuine), inbound filtering, and now increasingly something that flags impersonation.
**Incident response plan.** Not just "we have one", but tested, dated, with contact lists that have been refreshed inside the last twelve months.
The volume isn't the problem so much as that any of those answers being weak now flows directly into the premium, and a couple of weak answers flowing together gets the renewal declined.
## What changed
Two things, mostly. The first is that insurers paid out a lot of money between 2021 and 2024, ransomware claims in particular, and the actuarial side of the house caught up with the marketing side. The second is that there's now enough public reporting on how breaches actually happen for underwriters to know which controls matter. They've stopped asking about firewalls and started asking about MFA enforcement gaps, because that's what the post-mortem reports keep saying.
The other shift is who's writing the questionnaires. Three years ago it was an underwriter with a glossary. Now it's an underwriter with a security advisor on speed-dial, and the questions are good enough that you can tell. We've had questionnaires this year that probe for the specific failure mode, "describe how a compromised admin credential would be detected within 24 hours", rather than the control name, which is a different conversation.
## What's coming next
A few patterns we think are about to become standard, based on what the bigger broker conversations are starting to surface:
**Evidence, not attestation.** The current model is still mostly "we attest that we do X". The next model wants screenshots, config exports, or a third-party assessment. For SMEs this is going to be uncomfortable; the answer to "show us your conditional access policy" (the rules in Microsoft 365 that decide who can sign in from where) is a real piece of work if you haven't documented it.
**Continuous validation.** A handful of insurers are piloting external scanning that runs through the policy period, not just at renewal. If your perimeter develops a new exposed service in October, the insurer knows in October, and the renewal in March reflects it.
**Tiering of MDR providers.** Underwriters are starting to differentiate between MDR services. Some get a discount, some don't move the needle. The "we have an MDR" answer alone isn't going to be enough by 2027.
**AI exposure questions.** Brand new this year — a few questionnaires now ask about AI tooling, which models, what data goes into them, whether prompts can leak customer data. Most SMEs don't have a clean answer. We expect this to harden fast.
## What we see on the ground
The clients who renew smoothly aren't the ones with the biggest security stack. They're the ones who treated the questionnaire as a planning document twelve months before the renewal, not a form to fill in three days before.
The ones who get caught out share two patterns. The first is having a control "in principle" but not in evidence: MFA is on, but six executive mailboxes have it disabled because the executives complained. The second is having no view of what their external footprint looks like: a forgotten test VPN on a router that hasn't been touched in two years, a remote-desktop port left open after a one-off support call in 2022.
Both of those are findable in a morning; they just need somebody to look.
## Practical implication for SMEs
If your renewal is more than three months out, treat the questionnaire as a project, not an admin task. Pull last year's answers, walk through each one with somebody who knows what current underwriters expect, and triage. The expensive failures aren't in the questions you got wrong; they're in the questions where the honest answer is "we don't know".
If renewal is sooner than that, the priority is reducing surprises. An external footprint scan, an MFA-coverage audit, and a fresh look at the backup-restore answer will catch most of what's about to embarrass somebody.
That's our Security Solutions practice. We sit on the technical side of the renewal conversation, help with the questionnaire, and close the gaps that would otherwise show up as a premium hike or a declined quote.
The clients who leave this until the last fortnight end up with the worst of both outcomes: a premium that's gone up because the answers are weak, and no time to fix the answers before the policy expires. A declined renewal is harder to come back from than a higher one, because the next broker wants to know why the last one walked away. Three months of preparation is the difference between renewing on your terms and renewing on the underwriter's, and the clock is the part of this you can't buy back.
---
*Renewal coming up and the questionnaire looks different to last year's? Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk). One of us will read it.*
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# Cloud-first AD: where SME estates are actually landing in 2026
Practice: Managed Services
Author: Matthew
Date: 2026-05-17
Tags: Active Directory, Entra, M365, identity, cloud, managed-services
URL: https://jmo.partners/insights/cloud-first-ad-2026/
Identity has been the slowest-moving piece of the SME IT estate. Servers got virtualised, files moved to the cloud, email moved to Microsoft 365 (M365, the Microsoft cloud bundle: email, Word, Excel, Teams, file storage), but a lot of 30-to-100-seat businesses still had a domain controller (the server that holds your staff logins and permissions) sitting in a comms cupboard humming away, running Active Directory (AD, Microsoft's identity-and-permissions system, the thing that knows who can log in to what) the way it had since 2015.
That's changing, and 2026 is the year we've seen the centre of gravity actually shift, not because anyone's running a big cloud-first marketing push (that ship sailed years ago) but because the remaining reasons to keep an on-prem domain controller are running out.
Here's where the typical SME estate is landing this year, what's driving the move, and the bit nobody mentions in the migration deck.
## The three patterns we see
Across our managed-services book, call it eighty clients in the 20-to-200-seat range, there are basically three identity patterns in 2026.
**Pattern 1: Entra-only (cloud-native).** No on-prem domain controller. Joins are Entra-joined laptops (Microsoft Entra ID, formerly Azure AD, the cloud version of Active Directory). Sign-in is M365. Conditional access does the work group policy used to do. We see this on every greenfield SME we onboard, and on most companies under 50 seats by their second cloud-first review.
**Pattern 2: Hybrid with a token DC.** There's still an on-prem domain controller, but it's there for one or two specific things: a line-of-business application that won't authenticate any other way, a print server that needs Kerberos (an older sign-in protocol some apps still require), a legacy file share that hasn't been migrated. Everything else is cloud-managed. This is the majority of our 50-to-150-seat clients right now.
**Pattern 3: Full on-prem AD with M365 layered on top.** Domain controller doing the heavy lifting, M365 federated via Entra Connect. Five years ago this was every SME. Now it's the smallest of our three buckets and shrinking.
The interesting move is Pattern 3 to Pattern 2. We've done about a dozen of those in the last eighteen months. Pattern 2 to Pattern 1 is rarer and harder, usually a longer project because somebody, somewhere, is using the on-prem authentication for something nobody documented.
## What's actually driving the shift
It isn't the marketing pushing the change, it's three concrete things.
**Hardware end-of-life.** The 2018-vintage Windows Server box running the domain is hitting end of support, the host hardware is older than that, and replacing the lot to keep doing the same job feels, correctly, like throwing good money after old patterns. The renewal moment forces the decision.
**Conditional access has actually got good.** Five years ago, cloud-only meant losing the granularity of group policy (the Windows tool that controls what users can and can't do on a domain), and that's no longer the case. The Entra conditional-access policies that used to require an enterprise licence are accessible to SMEs, and they do the things SMEs actually need: block sign-ins from unexpected countries, require multi-factor authentication (MFA, needing a code as well as a password) for risky sessions, restrict access to managed devices.
**Cyber-insurance and Cyber Essentials Plus.** Both push toward the same controls (MFA on everything, conditional access, endpoint compliance) and both are easier to demonstrate on a cloud-managed estate. We've watched clients fail a Cyber Essentials Plus renewal on a control that was theoretically configured on the domain but couldn't be evidenced. Same control in Entra produces a screenshot in thirty seconds.
## What's coming next
A few things we think will be commonplace by 2027.
**Passwordless as default for new estates.** Windows Hello for Business and FIDO2 keys (a passwordless sign-in standard using hardware keys or built-in biometrics) are starting to move from "the security-conscious 5%" to "the new-laptop-onboarding default" for SMEs. The cost has dropped, the management story is now in Intune (Microsoft's device-management tool, the thing that pushes configuration to laptops and phones) rather than a separate console, and the user experience is genuinely better than typing a password into a sign-in page.
**Intune as the management layer.** Group policy on the way out, Intune in for new device estates. This one's been promised for years, but the tooling has finally caught up. We're now setting up Intune policies on greenfield clients in a day, where the on-prem equivalent used to take a week.
**File-server retirement gathering pace.** SharePoint and OneDrive aren't a perfect file-server replacement, but they're now closer than they were, and most of the holdouts are running on a file server that's about to need a hardware refresh. The replacement conversation is increasingly "do we migrate, or do we just turn this off".
## What we see on the ground
Three patterns worth flagging because they're where projects go sideways.
**The application that won't move.** Every SME has at least one: a bespoke CRM, a finance package on an old version, a job-management system written in 2009. It needs a domain controller because the vendor said so in 2014. The honest question is whether the vendor's "needs AD" answer still holds, or whether they just never tested anything else. About half the time, when we actually push the vendor, the answer is "modern auth has been supported since v6". The other half, the application is the project blocker and the migration plan needs to account for it.
**The print situation.** Print servers and domain joins are still entangled in ways that make migrations untidy. Universal Print is good now, but it's another moving piece.
**Group nesting nobody documented.** Hybrid migrations stumble on inherited permissions: the shared drive that's accessible to three groups, one of which is nested inside another, one of which has a service account in it. None of this is hard to migrate; it just takes finding it first.
## Practical implication for SMEs
If you're running Pattern 3 today and your domain controller has more than a year of life on the hardware, you've got time to plan a proper move. Don't wait for the hardware to die, because that's the worst possible moment to design a migration, when the only question on the table is "how fast can we replace it".
The cleanest sequence we've run is: audit what's actually authenticating against the DC (it's usually less than people think), pick the application or share that's the biggest single blocker, find out whether that blocker is real or assumed, and then design the migration around the answer. Most SMEs are six to nine months out from being able to retire their domain controller, but they don't know it because nobody's done the audit.
That's our Managed Services practice. We run the audit, plan the migration, and sit alongside the in-house IT team (or do the work directly) through the transition.
If your DC dies before you've planned the move, the migration becomes an emergency, with all the cost and risk that comes with that: extended-hours rebuild, staff locked out of files, a Cyber Essentials renewal you can't evidence, and a board asking why nobody saw this coming. Six months of planning is a different project from six days of firefighting. The hardware doesn't give you much notice when it goes.
---
*Looking at a domain controller refresh and wondering whether to replace or retire? Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk). One of us will read it.*
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# Two years of UniFi rollouts: what we'd keep and what we'd swap
Practice: Managed Services
Author: Jamie
Date: 2026-05-17
Tags: UniFi, networking, WiFi, hardware, managed-services
URL: https://jmo.partners/insights/two-years-of-unifi/
We bet on UniFi (Ubiquiti's networking line, the WiFi access points and switches sitting in the comms cupboard) as our default SME network stack about two years ago. The pitch was always the same: enterprise feature set, sensible price point, single controller for the lot, decent enough hardware that we wouldn't be back to swap it in 18 months. For the most part that's held up. We've deployed it in offices from 8 seats to about 180, retail sites, a couple of warehouses, and one rather entertaining listed-building project where every cable run had to be approved by a conservation officer.
## What we'd keep
**The U6 and U7 access point (AP, the WiFi box on the wall or ceiling) line on most office floors.** WiFi 6 was the sweet spot for the SME budget when we started, and the U7 generation since has been a clean upgrade: better client density, sensible roaming behaviour, no surprises on the firmware side. Where we've gone back to a U6 site to upgrade, the swap-out has been about as boring as a network upgrade ever gets, which is what you want.
**The PoE switches** (PoE, power-over-Ethernet, the standard that lets a single network cable carry both data and power). The 24-port and 48-port models with full PoE+ have done what they say on the tin. We've had two switches fail in two years across all sites; both arrived dead-on-arrival, neither went bad in service — better than we expected, frankly.
**The controller model.** A single UniFi Cloud Gateway (the small box that runs the network's brain and lets us see all the kit in one place), or a Dream Machine Pro on bigger sites, running the controller for a building is straightforward, gives us decent remote visibility, and means we're not paying a separate licence fee per AP. Compared to running an on-prem controller for a competitor product, the operational overhead is much lower.
**Adopting on the first day, not the last.** This sounds basic, but every site where we adopted devices into the controller as soon as they came out of the box went smoothly. The two sites where we deferred adoption to the end of the install, for reasons that seemed sensible at the time, were the ones where we ended up debugging things at 9 PM on a Friday.
## What we'd swap
**The early-generation gateway choices on bigger sites.** We put a Dream Machine Pro into one client at the 120-seat mark and it's been working hard ever since: not failing, but never quite breathing easy either. With hindsight, anything north of 100 seats wants the bigger gateway from day one. The price difference is real but the headroom matters, and "real-time threat management" features eat CPU more than the spec sheet implies.
**The cameras, mostly.** UniFi Protect is a nice product, but in most cases it isn't the right one for an SME that takes physical security seriously, particularly anything with regulatory or insurance dimensions. We've deployed Protect at a few sites and it does the job for general-purpose monitoring. We don't put it in any more where the client has compliance needs around retention, audit trails, or third-party monitoring, because the integration story isn't there yet.
**Mixing too many AP generations on one site.** This was a deployment mistake on our side more than a product issue. We had one site that grew over 14 months and ended up with U6 Pro, U6 Lite, and one U7 Pro on the same controller. The behaviour was fine but the troubleshooting got harder than it needed to. Now we standardise within a site, and only mix generations across sites.
**The doorbell and access products.** We've tested them and wouldn't put them in client estates yet: too much management overhead, not enough integration with the things SMEs actually use for access control.
## What's coming next
A few things we're tracking.
**WiFi 7.** The U7 line is shipping at sensible prices and the chipset story has matured. For sites doing a refresh from WiFi 5, we're skipping the WiFi 6 generation and going straight to WiFi 7. For WiFi 6 sites under three years old, there's no compelling reason to swap yet.
**UISP and the cellular failover side.** Useful for the increasing number of clients running hybrid offices or multi-site setups. The integration with the main UniFi controller is still rougher than it should be, but it's improving.
**Identity-driven SSIDs.** The capability has been there for a while, but the deployment story is getting cleaner. Connecting WiFi access to Entra-joined laptops (Microsoft cloud-managed devices) without separate certificates is a real workflow improvement for SMEs.
## What we see on the ground
Three patterns worth calling out because they catch people.
**Switch port budgeting is always too tight.** Nobody plans for the third printer that arrives six months in, the meeting-room AV refresh that adds four ports, or the structured cabling somebody forgot to spec for the storage cupboard. We now spec switches with a 30% headroom by default, not 10%. That's saved us at least three back-pocket switch orders.
**Cable-run quality matters more than the AP model.** A U7 Pro fed by a 15-year-old Cat 5e run through a damp riser will underperform a U6 fed by a clean Cat 6 run. We've started insisting on cable certification before the AP install, because the failure mode otherwise is "WiFi is still slow after the upgrade" and a long, awkward investigation.
**Firmware discipline.** UniFi firmware has been mostly good but it has off days, so we don't auto-update production sites. We test on our own lab gear, hold for a couple of weeks, then roll forward. Twice in the last two years that discipline has saved a client from a bad release.
## Practical implication for SMEs
If you're sitting on a 5-to-7-year-old network and looking at a refresh, UniFi is still our recommended default for most SMEs. It isn't the right answer in every case (heavy regulated environments, very large estates, anywhere with unusual segmentation requirements may want a different vendor) but for the typical 20-to-200-seat office, the value-to-capability ratio is hard to beat.
The thing we'd say to anyone planning the move themselves: spec the cabling properly, spec the gateway one tier up from what feels right, and standardise generations within a site. The product is good; the deployment discipline is what makes the difference between a network that just works and a network that's an active project for two years.
That's our Managed Services practice. We design the refresh, do the install, and run the network on an ongoing basis where that's helpful.
The networks we walk into where the previous installer cut corners have a predictable shape: under-specced switch in a hot cupboard, two failing APs starving the rest, a controller nobody can log into because the previous admin left, and a staff team who've stopped raising tickets because "the WiFi is rubbish" is just the climate. That's a longer rip-and-replace than the original install would have been if it had been done properly. The refresh is your chance to set the next seven years up to be boring. Get the spec right while it's a fresh sheet of paper.
---
*Thinking about a network refresh and not sure whether to stick or twist? Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk). One of us will read it.*
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# AI tooling for SMEs: where it's earning its keep, where it isn't
Practice: AI Enablement
Author: Oliver
Date: 2026-05-17
Tags: AI, Copilot, automation, productivity, AI-enablement
URL: https://jmo.partners/insights/ai-tooling-smes/
Every client conversation in 2026 includes AI somewhere. Sometimes it's the headline question, "should we be doing Copilot?", and sometimes it's the third or fourth item on the list, but it's always there. After eighteen months of helping SMEs work out which AI conversations are worth having and which aren't, we've got a fairly clear pattern of where this stuff is genuinely paying for itself and where it's costing money for very little return.
This isn't a pitch for AI or against it; it's what we see on the ground.
## Where it's earning its keep
Three categories, in roughly decreasing order of how predictably they pay back.
**Transcription, summarisation, and meeting follow-up.** This is the clearest win we see, with the endpoint (the laptops, phones and tablets people work on) running a meeting-transcription tool that produces a usable summary and action list inside ten minutes of the meeting ending is genuinely useful. We've seen SMEs cut the time their senior people spend writing up meetings by something close to half. The licence cost is small. The behaviour change is fast: people either use it from the first week or they don't, and they almost always do.
**Drafting first passes of customer-facing copy.** Sales emails, proposals, product descriptions, internal comms, not the final version but a first draft that's 70% there. The pattern that works is "AI for the boring middle, human for the opener and the close". Where this falls down is when somebody tries to use it for highly technical or regulated copy and doesn't realise the output is plausibly wrong in ways that look right.
**Searching across internal documents.** Microsoft 365 (M365, the Microsoft cloud bundle: email, Word, Excel, Teams, file storage) Copilot's "find me the thing we wrote about X" capability, when it's set up properly, does something the file-search bar never did. The condition is that the documents have to be in the places Copilot can see them, which in practice means SharePoint and OneDrive, properly organised, with sensible permissions. The SMEs who had their file storage in good shape get value from this fast. The ones who didn't are getting value from the cleanup the Copilot rollout forced more than from the Copilot itself.
## Where it's not earning its keep, yet
**Full Copilot rollouts on day one.** The biggest mistake we see SMEs make is buying Copilot for everyone in month one and expecting productivity gains to land by month three, when they don't. The licence cost is real, the behaviour change is uneven, and the ROI conversation gets awkward fast. The clients who got value did pilots: five to ten power users, three months, then a structured review, and only rolled wider when the pilot users couldn't imagine life without it.
**Customer service chatbots without a human escalation path.** We've seen a handful of SMEs try to put a chatbot on their website that handles tier-one queries autonomously. None of them have stuck with it for more than six months. The technology is closer than it was, but the failure mode (sounding confidently wrong to an actual customer) is expensive in ways that don't show up in the productivity-gain spreadsheet.
**Wholesale finance or HR automation.** AI tools that promise to read invoices, categorise them, post the entries, and reconcile against the bank are a real product category, but the integration overhead for an SME with one bookkeeper is rarely worth it. The 80% case works. The 20% edge cases (credit notes, foreign currency, multi-line splits) eat the time the automation was meant to save.
**"AI strategy" engagements that don't ship anything.** Some SMEs are spending six-figure sums with consultancies on AI strategy documents. We've read a few of these. The good ones identify two or three specific workflows worth automating. The bad ones produce a 40-page deck that talks about "competitive advantage" and recommends another phase of strategy work.
## What's coming next
A few things we're watching.
**Agentic workflows that span more than one tool.** The pattern where an AI does the meeting summary, then drafts the follow-up email, then adds the action items to the project tracker, then schedules the next meeting, this exists in demos and it's getting closer to working reliably outside them. By 2027 we expect at least one or two of these to be solid enough to recommend.
**On-device AI for confidential work.** The data-leakage anxiety SMEs have around prompting cloud models with sensitive customer data is real, and it's slowing some legitimate use cases. Smaller models running on a laptop's neural processor (the dedicated AI chip in newer laptops) are starting to be good enough for things like drafting and summarisation. This will matter more than it currently looks like it will.
**Verticalised tools beating horizontal ones.** Generic Copilot is fine, but the vertical tools, AI built specifically for accountants, for property managers, for recruiters, are starting to outperform it for the specific workflows of those professions. We expect this to accelerate.
**The compliance question.** Cyber-insurance questionnaires now ask about AI exposure. By 2027 we expect them to ask in detail, the way they ask about backups now. SMEs that have a clear answer to "what data goes into which model, and where does the output land" will be in better shape than those who don't.
## What we see on the ground
The most common pattern: an SME has bought one or two AI products, isn't quite sure which of their team are actually using them, and isn't sure whether to expand the licences or cut them. The honest answer is usually "you can't tell yet, because you don't have visibility on usage". A two-week visibility exercise, pulling usage data, asking the users directly, identifying the workflows where AI is actually changing the work, answers the question.
The second pattern: an SME hasn't done anything with AI and feels they should have. The right answer is rarely "buy the platform"; it's "identify two workflows where this might matter, run a four-week pilot with three people, see what happens". Most pilots tell you something useful within a month, either way.
## Practical implication for SMEs
The framework we've ended up using internally is three questions:
1. Is there a specific workflow this is meant to change, or is the goal "we should be doing AI"?
2. Who in the business will be the first three users, and are they engaged?
3. What does success look like in twelve weeks, in a measurable form?
If those three questions get good answers, the project is worth running. If they don't, the project is worth deferring until they do.
That's our AI Enablement practice. We sit alongside SMEs working out where AI actually pays back, run the pilots, set up the visibility, and pull the plug honestly when something isn't working.
The cost of waiting another quarter to think about this isn't dramatic until suddenly it is. Competitors who got their pilot right twelve months ago are now ten or fifteen per cent faster on the work that matters: proposal turnaround, client reporting, internal comms. That gap compounds, and "we'll look at AI next year" stops being a neutral position. The cheap, low-risk move is a small pilot now; the expensive move is a panicked platform purchase in eighteen months when the board asks why everybody else is using it.
---
*Looking at AI tooling and not sure where it actually fits in your business? Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk). One of us will read it.*
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# WiFi vs Ethernet for the modern office: a 2026 take
Practice: Managed Services
Author: Matthew
Date: 2026-05-17
Tags: WiFi, Ethernet, networking, cabling, managed-services
URL: https://jmo.partners/insights/wifi-vs-ethernet-2026/
Every office fit-out conversation we have eventually lands on the same question. The architect's drawings show a structured cabling plan with a port at every desk. Somebody in the room, usually the finance lead, looks at the line item and asks the obvious question: "do we still need that, given the WiFi?" The answer in 2026 is more interesting than "yes" or "no", and it's worth taking the time to get right because the decision lasts ten years.
We've been part of a dozen-odd office fit-outs in the last two years where this question got debated properly. Here's where we've landed.
## What changed
The honest case for "WiFi is good enough now" is real and worth acknowledging. WiFi 6, and now 7, do things that WiFi 5 didn't. Client density is higher. Roaming between access points is smoother. Latency is genuinely better. For a typical office worker on a laptop doing M365 (Microsoft 365, the Microsoft cloud bundle: email, Word, Excel, Teams, file storage), video calls, web apps, Ethernet (the wired cable network, the alternative to WiFi) is no longer a measurably better experience.
The numbers most people quote for raw WiFi throughput are usually theoretical. Real-world WiFi 6 throughput at desk distance is more like 400-600 Mbps on a good day, which is fine for almost everything an SME does. The argument that "Ethernet is faster" is technically true and operationally irrelevant for most users.
That's the half of the conversation people focus on; the other half is what actually matters.
## What's actually still wired
Even in the most WiFi-first office we've fitted out, the following are still on cable:
**The access points themselves.** Every WiFi access point (AP, the WiFi box on the wall or ceiling) needs power and a cable run to a switch. PoE (power-over-Ethernet, the standard that runs power down the network cable) means it's one cable, but it's still a cable. A 1,500-square-foot floor wants somewhere between four and six APs for sensible coverage, and each one of those needs structured cabling to the comms cupboard.
**Printers and MFDs (multi-function device, the office printer-scanner-copier).** Wired every time, because WiFi printers are a constant low-grade support call generator and fail in ways that take time to diagnose. The cable cost on a printer is small, and we've made it a default and never regretted it.
**Meeting room AV.** Video bars, room PCs, displays, sometimes a control panel. WiFi works for some of this, but the room codecs and the always-on systems should be wired. The user experience of a meeting room where the video bar drops off the network mid-call is bad enough that the cable cost, modest compared to the alternative, is the easiest decision in the design.
**Servers and storage, where they exist.** If there's any kit in the comms cupboard, it's wired to the switch, every time.
**Desk phones, where they exist.** Less common than they were, but where they're in use, wired by default for call quality.
**The reception PC, the warehouse barcode scanners, the kiosk machines.** Anything that absolutely has to work, where a WiFi drop would be visible to a customer or break a workflow.
## What can sensibly move to WiFi
Most of the office, in practice, because the desk-based knowledge worker on a laptop doing M365 and video calls is the dominant office user, and WiFi handles that workload well. Hot-desking and flexible-seating layouts effectively require it; you can't pre-cable a desk you don't know who's sitting at.
The honest framing isn't "wired or wireless" but "what's wired, and how much extra wired capacity do we provision for the future", and the answer to that second question is "more than feels obvious".
## Where the cost is
A structured cabling install in an office fit-out is a meaningful cost: typically a low-three-figure sum per port installed, varying with the building. The temptation to save money by reducing port counts is real, and worth pushing back on.
The cost of installing cabling during a fit-out is the cheap moment. The cost of running cabling after the fit-out, through a finished ceiling, around occupied desks, while the business is running, is two to three times higher per port. And the moments when you discover you need more ports (a new printer, an extra AP because coverage is poor, a wired connection for a workstation that turns out to need the throughput) happen often enough that retrofit is a real cost.
The discipline we've ended up with: for any office of more than 15 seats, install cabling at twice the number of ports you think you need today. Pull it through the ceiling now. Terminate the panel side. Leave the floor side as a stubbed cable for the first refurb. The marginal cost is a fraction of the retrofit cost three years later.
## What's coming next
A few things we're tracking.
**WiFi 7 in practice.** The 6GHz band genuinely helps in dense offices. Real-world throughput improvements are noticeable. For greenfield fit-outs in 2026 we're spec'ing WiFi 7 access points. The client devices that can use it are still the minority but rising fast.
**Power-over-Ethernet expansion.** Increasingly we're seeing kit that runs off PoE: meeting room screens, sensors, smart lighting controllers, even some monitors. The implication for cabling design is that "data ports" and "power outlets" are starting to merge, and the cabling plan should anticipate that.
**Wired-by-default for hybrid workers' home offices.** This is the unexpected one in the list. We've watched enough video calls drop on home WiFi that we're now recommending senior remote workers wire their primary workstation. The cabling is trivial at home, and the user experience improvement on a long call is real.
**The death of the dedicated VoIP cable.** Where VoIP (voice over IP, desk phones that run over the data network rather than the old phone wiring) is still in use, the move is toward soft phones on the laptop or a single cable shared with the workstation. The two-cables-to-every-desk standard is fading fast.
## What we see on the ground
Three patterns worth flagging.
**The reception zone.** Almost every office under-cables reception. Then a guest WiFi system gets added, then a digital display, then a tablet check-in, then a delivery-management system. Cable the reception zone like it's a server room, not a desk.
**The "we'll do that wirelessly" room that ends up wired anyway.** Almost every meeting room follows the same arc: the first install is WiFi-only, then within twelve months every video bar has a wired uplink because the wireless one keeps dropping. Save the second visit and wire the rooms during the fit-out.
**The board room that needs to be very wired.** Whatever your default cabling density is, double it for the room where the most important external meetings happen. The cost of a dropped call in that room is higher than anywhere else in the building.
## Practical implication for SMEs
The 2026 framing isn't "wired versus wireless" but "default to wireless, but cable the things that have to work, and over-cable the cabling itself". For most SMEs that means a thoughtful AP plan, wired drops to printers, meeting rooms, reception and the comms cupboard, and structured cabling at twice the density that feels obvious during the design phase.
That's our Managed Services practice. We design the network during fit-out, install or oversee the cabling, and run it afterwards.
The under-cabled fit-out is the gift that keeps on giving for the next decade. Every new printer, every extra meeting-room display, every workstation that turns out to need wired throughput, becomes a quote from a contractor cutting holes in your finished ceiling at evening rates. Boardroom calls drop in front of clients. The reception display goes black during a tour. Three years of patches add up to more than the cabling would have cost during the build, the design phase is the one cheap window, and once the ceiling tiles go up every fix is the expensive version.
---
*Planning a fit-out or refurb and wondering how much to cable? Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk). One of us will read it.*
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# Web filtering in 2026: what to stop paying for
Practice: Security Solutions
Author: Jamie
Date: 2026-05-17
Tags: web-filtering, DNS, security, endpoint, security-solutions
URL: https://jmo.partners/insights/web-filtering-2026/
The web-filtering category had its heyday somewhere around 2010 to 2018. Every SME we onboarded in that era had something: Barracuda, Forcepoint, an on-prem appliance, a category-based filter sitting on the firewall, a productivity-monitoring plugin somebody had bought after a board meeting. Most of them are still paying for it in 2026, and a surprising number shouldn't be.
This isn't an argument against web filtering as a category, it's an argument for looking at the line item, asking what problem it's actually solving, and either retiring it or replacing it with something that does the modern version of the job.
## What web filtering used to do
The classic web-filtering pitch had four jobs:
1. Stop people visiting genuinely malicious sites: drive-by malware, phishing pages, exploit kits.
2. Stop people visiting categories of site the business didn't want them on: gambling, adult, illegal.
3. Stop people wasting time on social media, news sites, shopping.
4. Generate a productivity report somebody at executive level could look at.
In 2010 those four jobs were all real, the technology stack to do them was specialist, and you needed a dedicated product to get any of it. The market grew accordingly.
What's happened since is that three of those four jobs have either become commodity features in something the SME already pays for, or stopped being a job anyone actually wants done.
## What the modern stack does for free
The first job, blocking genuinely malicious sites, is now done in multiple places, most of which the SME is already paying for. Microsoft Defender SmartScreen, baked into Edge and Office, blocks known phishing and malware sites at the browser level. Microsoft 365 (M365, the Microsoft cloud bundle: email, Word, Excel, Teams, file storage) Defender for Endpoint, where it's deployed, blocks at the network level. Most modern firewalls do reputation-based blocking out of the box. A decent DNS-layer filter, DNS (domain name system, the address book that turns a website name like jmopartners.co.uk into the numeric address browsers actually use) filtered at that lookup step, by Cloudflare's free tier, Quad9, or a paid product like DNSFilter, does it at a layer above all of that.
If you're paying separately for "stop people visiting malicious sites" in 2026, you're paying for something the rest of the stack is already doing. The question isn't whether you need that capability (you do); it's whether you're paying for it twice.
The second job, category-based blocking of gambling, adult, illegal content, is still real for some industries (regulated, education, certain HR-sensitive environments) but cheap. DNS-layer filtering does this for £2-3 per user per month, often less. The £15-per-user-per-month enterprise filtering product isn't doing this job ten times better than the cheap option.
The third job, productivity-monitoring blocking of social media and news, is the one that's genuinely shifted, and not in the direction the vendor marketing suggested. Most SMEs we work with have moved away from this entirely. The reasons:
- The pandemic accelerated trust-based working. Blocking news sites on a workplace network reads as performative.
- Remote and hybrid working make in-network filtering nearly meaningless. The user on their phone, hotspotting, or on a home connection isn't filtered. The category-blocking budget protects only the in-office laptop, which isn't where the work is happening.
- Browser-based productivity-monitoring has reputational and HR consequences SMEs increasingly don't want.
The fourth job, productivity reports for executive review, has historically produced reports nobody reads.
## What's actually worth paying for in 2026
We've ended up recommending a fairly minimal stack, layered:
**DNS-layer filtering, applied everywhere.** Block known malicious domains, block the categories the business has a defensible reason to block, log enough to investigate an incident. Apply it to the office network and to the endpoint (the laptops, phones and tablets people work on) so it follows the user off-network. Cost is low and value is high, which is why this is the layer most SMEs should still be paying for.
**Browser-level safe-browsing protection.** Edge SmartScreen for SMEs in M365, Chrome's safe browsing for the rest. Free, on by default, blocks the most common phishing and malware sites, with nothing to procure.
**Email link rewriting and detonation** (the security check that opens a suspicious link in an isolated sandbox before deciding if it's safe). Where the genuinely dangerous links arrive in 2026, it's via email or messaging. The investment is in email-side protection (link rewriting, sandboxing, time-of-click checking), not in the perimeter web filter (the appliance or service that sits between your office and the open internet, blocking dodgy URLs). This is a Defender for M365 or third-party email-security spend, and it does more for an SME's actual risk than a category-based web filter ever will.
**Endpoint security with web protection.** Modern endpoint security agents include some level of web protection. Where they do, it's an additional layer at zero marginal cost.
The combined cost of the modern stack is often lower than the legacy web-filter line item it replaces, and the risk coverage is higher.
## What's coming next
A few things we're tracking.
**Browser-based security platforms.** Specifically-built secure browsers (Island, Talon, the enterprise capabilities arriving in Edge) are starting to do something interesting. They put the security perimeter at the browser itself, where the actual work is happening. For SMEs this is two or three years from being mainstream, but it's worth knowing it's coming.
**DNS-over-HTTPS bypass.** Increasingly, browsers and apps use DNS-over-HTTPS (DoH, DNS lookups encrypted inside web traffic so they can't be inspected by an outside filter), which bypasses traditional DNS-layer filtering. The DNS-filter vendors have responded; most now offer an agent that intercepts before the bypass happens. But if your filter is the old "set the DNS server on the router" approach, it's filtering less than it used to.
**AI-driven phishing.** The volume and quality of phishing emails are both going up. The defensive layer that matters is email-side, and the case for serious email security keeps strengthening. The case for traditional web filtering keeps weakening relatively.
## What we see on the ground
Three patterns.
**Renewal that nobody questions.** The £8,000-a-year web-filter renewal gets approved in March because it always gets approved in March. Nobody's asked in five years what it's actually doing. We've helped clients cut this line item entirely on more than one occasion, replaced with a DNS-layer product at a fraction of the cost.
**Filter that filters nobody.** The web filter applies to the office network. Half the staff are hybrid. The filter is covering the smaller half of the user base for less than half their working hours.
**Legacy categories blocking modern tools.** The "social media" category in the legacy filter blocks LinkedIn, which the sales team needs to do their jobs, so the sales team are exempted, which means the filter is doing nothing for the people most likely to be targeted by social-engineering attacks.
## Practical implication for SMEs
Look at the line item. Ask what problem it's solving. Check whether the rest of the stack is already solving it. If the answer is "yes, mostly", the right move is to replace it with a DNS-layer filter, redirect the budget to email security, and stop paying for the legacy product.
This isn't a project so much as an afternoon. The savings tend to be real and the security posture improves rather than degrades.
That's our Security Solutions practice. We look at the existing stack, identify what's still earning its keep, and replace what isn't.
Every quarter that renewal rolls through unchallenged is money lighting itself on fire for a layer that's covering the smaller half of your team, missing the channel attackers actually use (email), and leaving you exposed where it matters. Meanwhile the email security spend that would have caught the AI-generated phishing run targeting your finance lead next month doesn't get funded, because the budget is tied up in the filter nobody questions. One afternoon of looking changes both sides of that picture.
---
*Got a security renewal coming up and not sure what's actually doing anything? Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk). One of us will read it.*
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# SSL renewals that don't surprise anyone: the five-touchpoint checklist
Practice: Managed Services
Author: Jamie
Date: 2026-05-17
Tags: SSL, certificates, renewals, managed-services, checklist
URL: https://jmo.partners/insights/ssl-renewals-checklist/
The phone call lands on a Friday afternoon. The website's serving a red browser warning, the booking form has stopped taking payments, and the office manager has just realised the marketing email she sent that morning is now bouncing because the mail domain's certificate also expired. Three things, one root cause: an SSL certificate (the digital padlock that proves a website is real, and what makes the browser show the lock icon next to the URL) lapsed at 02:14 that morning and nobody saw the warning emails because they went to an inbox the original developer set up four years ago.
We've watched versions of this play out across small businesses for years. The mechanics are simple, but the reason it keeps happening is that SSL renewals live in a strange ownership gap. The website hosting company assumes IT handles it, IT assumes the web developer handles it, the web developer left in 2023, and the bill is on a personal credit card that's been cancelled. The certificate expires unnoticed and the trading day breaks.
What follows is the frame we use to take that risk off the table. Five touchpoints, one calendar, no surprises.
## Why this matters more in 2026 than it did in 2020
Two things have shifted in recent years. First, certificate lifetimes have shrunk. Browser vendors agreed back in 2020 to cap maximum SSL validity at 13 months, and the industry's moving toward 90-day and even 47-day lifetimes by 2027. That means renewals stop being annual and start being quarterly, or monthly. You can't lean on a single calendar reminder anymore.
Second, the ripple effect when a certificate fails is wider than it used to be. A modern SME's website is usually wired into payments, email authentication, customer portals, booking systems, and a CRM (your customer database). One expired certificate can take all of those down at once. The blast radius is bigger; the warning window is shorter.
## Common failure modes
Before the checklist, the patterns we see most often:
- **Orphan certificates.** Someone left the business, took the renewal notifications with them. Nobody noticed until expiry.
- **Renewal emails to a generic inbox.** `info@` or `admin@` that nobody actively monitors. Warnings sit there for months.
- **Auto-renewal that didn't.** The card on file expired. The auto-renewal failed without notice. The certificate didn't renew.
- **Subdomain blind spots.** The main domain renews fine. The `checkout.` or `app.` subdomain has its own certificate and its own renewal cycle that nobody tracked.
- **Internal certificates ignored.** Internal portals, VPN gateways (your remote-access door), mail servers all have certificates too, and they fail differently. Users get a scary warning, click through, and now they're trained to ignore certificate warnings.
The common thread: nobody owns it. The five-touchpoint checklist puts an owner on each stage.
## The five-touchpoint checklist
### Touchpoint 1: Inventory, know what you actually have
What this means in practice: list every certificate that's currently live, where it's hosted, who's paying for it, and what it covers.
Most SMEs we work with discover they have between three and twelve certificates when they thought they had one. The website domain, the email mail-server, the staff VPN, the internal SharePoint (the file-and-document side of Microsoft 365) portal, the customer-facing booking subdomain, the API endpoint the warehouse uses, each can have its own certificate, its own issuer, and its own renewal cycle. You can't manage what you can't see, so the first job is a clean inventory: domain, issuer, expiry date, registered admin email, billing source, what would break if it lapsed.
### Touchpoint 2: Ownership, name a person, not a role
What this means in practice: every certificate has a named human accountable for it, with a backup. Not "IT", not "the agency", but a named person, in writing, with their contact details up to date.
Roles are slippery: "the web team handles it" works until the web team is one freelancer who quit. Names are sticky by contrast. If the person leaves, the gap is visible. We keep a single spreadsheet (the printable version of this checklist gives you the template) with primary owner, backup owner, last-verified date. When somebody leaves, the spreadsheet tells you exactly what needs reassigning.
### Touchpoint 3: Calendar, three reminders, not one
What this means in practice: every certificate gets reminders at 60 days, 30 days, and 7 days before expiry, hitting at least two inboxes.
One reminder is a single point of failure, whereas three reminders across two inboxes gives you redundancy without becoming noise. The 60-day touch is the planning trigger; that's when the renewal goes onto someone's task list. The 30-day touch is the action trigger; if it isn't done, escalate. The 7-day touch is the emergency trigger. By that point something's wrong and a person needs to pick up the phone.
### Touchpoint 4: Renewal test, verify before the swap
What this means in practice: before the new certificate goes live, test it on a staging environment or during a low-traffic window, and check every dependent service still works.
Most certificate renewals are clean, but only most. The ones that aren't fail in ways where the certificate itself looks fine but a downstream service can't use it: wrong intermediate chain, missing subject-alternative-name for a subdomain, a service that pinned the old certificate's fingerprint. The five minutes you spend verifying the new certificate against every dependent service is the five minutes that saves you the Friday-afternoon phone call. Check the website loads, check email authentication still passes (SPF, DKIM, DMARC, the three email-authentication settings that tell other mail servers your messages are genuine), check the VPN connects, check the booking form takes a test payment.
### Touchpoint 5: Post-renewal log, close the loop
What this means in practice: when a renewal completes, write down what was renewed, when, by whom, and the new expiry date.
The log is what makes next year's renewal easy. It tells the new IT person who took over from the old one what's been done and what's next. It tells the auditor or insurer that yes, you have a process. And it catches the slow drift. If the same certificate has been renewed three years in a row by three different people with three different issuers, that's a signal to consolidate.
## Where SMEs trip
The two failures we see most often, even with a checklist in hand:
The first is treating the inventory as a one-time exercise. New subdomains get spun up, new services get launched, new certificates get issued, and the inventory drifts within months. The inventory needs a quarterly refresh, minimum. We build that refresh into the managed-service calendar so it happens without anybody needing to remember.
The second is letting the renewal slip from a scheduled job to an emergency. The 60-day reminder hits, somebody marks it "I'll do it next week", next week becomes next month, and now you're at 14 days with a renewal that needs three approvals you don't have. The discipline is treating the 60-day touch as the deadline, not the warning.
## What good looks like
When this is working, certificate renewals are boring. Sixty days before expiry the calendar pings, the named owner books a 30-minute slot, the renewal goes through, the verification passes, the log gets updated, and the next reminder is automatically scheduled for the new expiry. No drama, no Friday phone calls, no red browser warnings in front of a customer.
Across the SMEs we manage, certificates aren't a thing anyone thinks about, because the process thinks about them on everyone's behalf, which is the goal.
## Where this lands with us
Certificate management sits inside our Managed Services practice. For clients on a managed contract we run the inventory, hold the calendar, own the renewals, and keep the log; it's part of the service, not an add-on. For clients who'd rather run it themselves, we'll hand over the template and the calendar and check in twice a year to make sure nothing's drifted.
Either way the goal's the same. The Friday-afternoon call where a padlock turned red costs you the booking system, the customer trust that took years to build, and a weekend of cleanup. None of that is the certificate's fault, it's the gap nobody owned. Close the gap and the call doesn't happen.
---
*Working through a certificate inventory and not sure what's actually out there? Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk) and we'll do a free initial sweep.*
*Want the printable version of this checklist? Drop us a note at info@jmopartners.co.uk and we'll send it through.*
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# Cyber Essentials Plus renewal: the prep-window calendar
Practice: Security Solutions
Author: Matthew
Date: 2026-05-17
Tags: Cyber Essentials Plus, CE+, certification, security, compliance, checklist
URL: https://jmo.partners/insights/ce-plus-prep-calendar/
It's late February, the certificate expires on 31 March, and the call comes through on a Wednesday. "Our assessor's booked us in for next Tuesday, can you make sure everything's ready?" There are seventeen laptops to check, three of them with personal admin accounts that shouldn't exist, a server that hasn't had its patch cycle reviewed since November, and a multi-factor authentication (MFA, needing a code as well as a password, usually a number from an app on your phone) rollout that's at about 80% adoption, all with six working days to go.
We've worked clients through a Cyber Essentials Plus (CE+, the UK government's annual cyber-hygiene certification, audited by an external assessor) renewal under that kind of pressure more than once. It's possible, and we've never failed one for a client we've prepared, but the cost of doing it in six days versus 90 is roughly five times the consultancy hours. None of that needs to happen. The certification is annual, the expiry date is known a year in advance, and the fix is a prep-window calendar that starts the clock with 90 days to spare.
## Why CE+ renewal is harder than people expect
Cyber Essentials (the self-assessment level) and Cyber Essentials Plus look similar on paper. They cover the same five technical controls: boundary firewalls, secure configuration, user access control, malware protection, patch management. The difference is that CE+ is externally audited. An assessor connects to a sample of your devices, runs technical tests, and checks that what you said you were doing is what's actually configured.
That's where the cost of last-minute prep hits. A self-assessment can be tidied up on paper in an afternoon, whereas an audit cannot. If your patching cadence has slipped, the assessor sees the slipped patches. If a user has local admin rights they shouldn't have, the assessor sees it. If MFA isn't on every cloud account, the assessor's tooling flags it. There's no narrative you can put around the technical evidence; it either passes or it doesn't.
A 90-day window gives you time to find and fix the gaps before the assessor's tools land on them.
## Common failure modes
The patterns we see when prep starts too late:
- **Patch backlog.** The patching policy (your routine for installing security updates) says "within 14 days for high-severity". The actual lag is six weeks because the patching window keeps getting rescheduled around month-end close.
- **Local admin accounts.** Set up years ago for someone who left, never cleaned up. They show up in the audit as a user with admin rights and no MFA.
- **Unmanaged devices.** The new starter who's using a personal laptop "just for now", three months ago. The director who's syncing email to an iPad nobody's enrolled in mobile device management (the tool that lets you wipe a lost phone remotely).
- **MFA gaps.** MFA's on the email accounts. It isn't on the accounting system, the CRM, or the file-share. The audit scope's wider than people remember.
- **Out-of-support software.** That one machine running an old version of Sage because the new version costs £1,200. It's been flagged in the inventory for two years and nobody's owned the conversation about replacing it.
Each of these takes weeks to fix properly, not days.
## The 90-day prep calendar
The calendar runs backwards from the audit date. Five milestones, each with a clear deliverable.
### Day 90 to 75: Scoping and inventory
What this means in practice: confirm what's in scope for the audit, list every device and account, and book the assessor.
The scope is the foundation. CE+ covers everything that handles your business data: every endpoint (the laptops, phones and tablets people work on), every server, every cloud service, every user account. We've watched scope arguments stretch to week three of a 90-day plan; better to settle it on day one. Pull the full asset list. Cross-reference it against payroll (everyone employed should have a device or know why they don't), against your Microsoft 365 (M365, the Microsoft cloud bundle: email, Word, Excel, Teams, file storage) admin centre (every account should match an employee), against your mobile device management console (every phone with company email should be enrolled). Anything that doesn't reconcile gets investigated this week.
Book the assessor at the end of day-90-to-75, which fixes the audit date and means everything else hangs off it.
### Day 75 to 60: Gap test against the five controls
What this means in practice: run through each of the five CE+ controls and write down where you currently stand against each. This is the dress rehearsal stage. We use a simplified version of the assessor's own checklist and walk through it like an audit. Boundary firewalls: is every endpoint behind a software firewall, with default-deny on inbound? Secure configuration: default passwords changed everywhere, no unused services running? User access: are there any standing admin accounts, is MFA on every cloud service, is there an offboarding process and is it being followed? Malware protection: is the endpoint protection live on every device, with current signatures? Patch management: are high-severity patches applied within 14 days?
For each control, a RAG status: green (clean), amber (one or two findings), red (systemic). The red items get owners and remediation plans this week.
### Day 60 to 30: Remediation
What this means in practice: fix the gaps you found in the dress rehearsal, in priority order.
Thirty days is enough to do most CE+ remediation work without burning out the team. MFA rollouts, local admin cleanups, patch catch-up, software replacement, mobile device management enrolment, all doable inside the window if they were identified clean in the previous step. The discipline is sequencing: do the changes that touch the most users first, because those are the ones that surface the unexpected pushback. The accountant who can't log in after MFA goes live; the director who wants to keep their personal laptop. Better to surface those in week six than week twelve.
### Day 30 to 14: Verification pass
What this means in practice: re-run the gap test, confirm every previously-red and previously-amber item is now green, and lock down change.
The verification pass is the rehearsal of the rehearsal. Same checklist, same RAG, fresh eyes, ideally somebody who wasn't involved in the remediation work, because they'll catch what the implementer thinks they fixed. From day 30 onward, a change freeze applies: nothing new gets installed, no admin rights get handed out, scope stops growing. The estate needs to be stable for the audit window so the auditor sees what you tested.
### Day 14 to audit: Light touch and evidence pack
What this means in practice: prepare the documentation the assessor needs, communicate the audit to the team, and avoid making changes.
The last two weeks aren't a sprint; they're a hold. Pull together the evidence pack: asset register, user list, MFA proof, patch reports, anti-malware deployment proof, leaver process documentation. Brief the team that the assessor will be in touch and may need 10 minutes of their time. If a critical patch lands during this window it still gets applied (security beats process), but log it carefully and tell the assessor up front.
## Where SMEs trip
Two things, repeatedly:
The first is conflating Cyber Essentials with Cyber Essentials Plus. The self-assessment level can be done in a day if the estate is in reasonable shape, whereas CE+ cannot. We've had clients book a CE+ assessor expecting a paperwork exercise and then realise on day one that the assessor is going to actually plug a laptop in. The 90-day window is built around CE+ specifically.
The second is treating it as a once-a-year tax. The whole point of an annual certification is that it's an annual checkpoint on a continuous process. If you do nothing between renewals, the gap test in month two of the next prep cycle is going to look like the gap test from the year before. Bake the five controls into the operating rhythm: monthly patch reviews, quarterly admin-account audits, semi-annual MFA verification. The prep window then becomes a verification exercise, not a remediation exercise.
## What good looks like
When this is working, the 90-day window is comfortable. The day-75 gap test comes back mostly green with two or three amber items that get fixed inside two weeks. The day-30 verification confirms it. The auditor arrives, runs their tooling, asks for the evidence pack, and signs the certificate within two weeks of the assessment date. The team barely notices it happened.
That's the goal: a renewal that feels like a check-up, not an exam.
## Where this lands with us
CE+ renewal sits inside our Security Solutions practice. For most managed clients we run the calendar from day 90 through to certification: we do the gap test, manage the remediation, prepare the evidence pack, and coordinate with the assessor. For clients who want to drive it internally, we'll do the gap test and remediation plan and hand it over.
A failed CE+ audit isn't an internal embarrassment, it's a contract you lose the next time a customer asks for proof of certification, a cyber-insurance premium that jumps at renewal, and a public mark that takes 12 months to fix. The 90-day window is the cheap version and six days is the expensive one. Choose which call you'd rather be making.
---
*Renewal date sneaking up on you? Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk) and we'll book a scoping call.*
*Want the printable version of this checklist? Drop us a note at info@jmopartners.co.uk and we'll send it through.*
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# Hardware refresh cycles: a 3-5-7 year decision frame
Practice: Managed Services
Author: Oliver
Date: 2026-05-17
Tags: hardware, refresh, lifecycle, capex, managed-services, checklist
URL: https://jmo.partners/insights/hardware-refresh-cycles/
The finance director asks the question every March, and it's almost always phrased the same way. "How much should we be budgeting for IT hardware next year?" The honest answer, the one nobody enjoys hearing, is that it depends entirely on when you last bought what, and there isn't a single annual figure that works. The number swings between £4,000 and £40,000 depending on which year of the cycle you're in. That swing is what makes hardware refresh feel chaotic, and it's also what makes it the easiest part of the IT budget to plan once you commit to a frame.
The 3-5-7 frame is what we've landed on after years of running this conversation: three years for the things that get worked hard by humans, five years for the things that sit in a rack and run without complaint, and seven years for the long-life infrastructure that, if specified right, ought to outlast two laptop generations. Different lifespans for different jobs, all on the same calendar.
## Why a frame matters more than a policy
Most SMEs we work with don't have a hardware refresh policy. They have a habit: replace things when they break, or when somebody complains loudly enough. That works in the short term, since nothing gets bought that wasn't strictly needed, and it falls apart in the medium term because everything ends up being bought at once.
It's a pattern the founders saw repeatedly running IT for SMEs before JMO existed. A 25-person business that hasn't refreshed laptops in five years suddenly needs to replace 19 of them inside six months because the warranties all ran out, batteries are failing, and Windows 11 won't install on the older models. The bill lands at £28,000 in a single quarter. The same business, on a rolling three-year cycle, would have been spending £9,000 to £10,000 a year smoothly, the same total but a vastly different cash-flow shape.
The frame turns hardware from an unpredictable shock into a planned monthly cost.
## Common failure modes
Before the frame, what we usually find:
- **One vintage of everything.** All the laptops bought in 2021, all the servers bought in 2020, all the switches bought in 2019. Every cycle hits as a wave.
- **No write-off discipline.** Old equipment sits in a cupboard because "we might need it for a temp". Five years later there's £8,000 of unsellable kit blocking storage.
- **Warranty drift.** Devices out of warranty get used until they fail. Failures are unplanned, expensive, and almost always happen on a Monday morning.
- **Spec inflation.** Each refresh, somebody spec's the new laptops three notches above what's needed because "they need to last". The result is over-spec'd, expensive, and the cycle still happens at the same interval.
- **Mixed estate.** Some users on three-year-old kit, some on six-year-old kit, with no logic to which. Productivity differences become a hidden cost the business never quantifies.
The 3-5-7 frame addresses all of these without needing a heavy policy document.
## The 3-5-7 decision frame
Three lifespans, three categories, with every device the business owns assigned to one of them.
### Track 3: laptops, mobile phones, frontline workstations
What this means in practice: anything an employee picks up, carries around, or uses for several hours a day, on a 36-month refresh.
Three years is the sweet spot for endpoint (the laptops, phones and tablets people work on) hardware. Battery life starts to degrade meaningfully at year three. The component-failure rate climbs after year three: keyboards, hinges, ports, fans. Standard business warranties run 36 months, so year-four devices are unsupported. And the productivity loss from a slow or unreliable laptop is real and measurable, even if it doesn't show up on a P&L. Replacing the laptop costs about £1,200; one lost day for the user costs more.
The refresh doesn't need to be all-at-once. Stagger purchases across the year so cash-flow is even: buy a third in spring, a third in autumn, a third the following spring. After the first cycle, the estate is permanently rolling.
### Track 5: on-premises servers, network switches, WAPs (wireless access points, the WiFi boxes on walls and ceilings), peripherals
What this means in practice: the kit that lives in a rack or on a wall, mostly doesn't get touched, but matters when it fails.
Five years works for infrastructure because the failure curve is different. A server that's been running well for five years will probably keep running well for another two, but the manufacturer's support window ends at five, replacement parts get scarce, and the firmware stops getting security updates. The risk shape changes around year five even though the device still works. Switches and access points (the boxes on the wall that broadcast WiFi) follow the same logic.
We refresh on a 60-month cycle for these, but we usually plan the replacement at month 48 so there's a year of head-room, because server migrations are not afternoon jobs.
### Track 7: long-life infrastructure, cabling, racks, UPS, CCTV
What this means in practice: the physical layer that, if specified right at install, should outlast multiple cycles of the kit it supports.
Some infrastructure isn't meant to be replaced on a fast cycle. Cat6a cabling (the data cable in the walls) in the walls. The 19-inch rack the servers sit in. The uninterruptible power supply (UPS, the battery-and-electronics box that keeps the network running for a few minutes when the mains drops) chassis, with its batteries on a separate cycle (covered in the separate UPS post). CCTV camera bodies, if installed cleanly. These should be on a 7-year-plus horizon, with maintenance and minor refreshes in between but no full replacement until the technology shifts beneath them.
The discipline here is at the install: over-spec slightly, buy the rack with two more U than you think you need, run two cables to every desk rather than one. The marginal cost at install is small; the saving over seven years is significant.
## How to apply the frame
A simple sequence to get the estate onto the frame:
1. **Inventory everything with a date.** Every device, when it was bought, when it goes off warranty, which track it sits on.
2. **Plot the next 36 months.** Each device gets a replacement date based on its track. Lay them out on a single timeline.
3. **Flatten the peaks.** If 18 laptops all hit refresh in Q2 2027, move six to Q4 2026 and six to Q4 2027. Slightly early or slightly late is fine; smoothing cash flow is worth it.
4. **Set a monthly budget.** The total cost across the 36-month plan, divided by 36, gives the monthly accrual; finance puts it in the model and hardware ceases to be a shock.
5. **Review annually.** New people, new roles, technology shifts. The plan needs a yearly refresh, usually a 30-minute session with the IT lead and finance.
## Where SMEs trip
The two we see most often:
The first is treating the frame as a hard rule when it's really a default. If a laptop is genuinely fine at year four (light user, battery healthy, no failures), extend it by 12 months and put the saving against next year. If a server is showing fan failures at year three, replace it early. The frame's job is to make the conversation easy, not to dictate the answer.
The second is forgetting the disposal side, because old kit needs to leave the building. WEEE-compliant disposal (the UK rule for getting rid of electronics safely), data destruction certificates, asset register updated. In years of inventory walks the founders have seen storerooms full of decade-old laptops because nobody had a process for getting them out, and that's a hidden risk, because old kit with old data on it is a breach waiting to happen.
## What good looks like
When this is working, the finance director's March question has an immediate answer. "Next year is £14,000 for laptops and £6,000 for one server. £20,000 total, £1,667 a month, on plan." The IT team isn't firefighting failed kit on a Monday morning. Users aren't carrying around laptops that take three minutes to boot. The disposal process is clean, the warranties line up with the lifecycle, and nobody's writing a £28,000 cheque at the end of a year-five wave.
That's what the frame buys you: a hardware estate that's predictable, in cash and in performance.
## Where this lands with us
Hardware lifecycle planning sits inside our Managed Services practice. For managed clients we run the inventory, hold the refresh calendar, plan the procurement, and handle disposal, it rolls into the monthly service. For clients who'd rather drive it themselves, we'll do the initial inventory and 36-month plan and check in annually.
Either way, the wave costs money you didn't plan for, productivity you didn't measure, and a Monday morning where three laptops fail at once and nobody has spares. A flat budget line is cheaper than that, every year, and the only question is when you start.
---
*Trying to flatten a refresh wave that's bunched into one year? Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk) and we'll do an initial timeline review.*
*Want the printable version of this checklist? Drop us a note at info@jmopartners.co.uk and we'll send it through.*
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# SharePoint archiving without losing what matters: a four-step plan
Practice: Managed Services
Author: Jamie
Date: 2026-05-17
Tags: SharePoint, archiving, M365, retention, managed-services, checklist
URL: https://jmo.partners/insights/sharepoint-archiving/
The Microsoft 365 (M365, the Microsoft cloud bundle: email, Word, Excel, Teams, file storage) bill came in at £680 a month last quarter, up from £420 the year before. Most of the increase was storage. The IT lead pulled the usage report and found that SharePoint (the file-and-document side of Microsoft 365) had ballooned to 4.2 terabytes, about 30% of which was a single sub-site called "Old finance archive" that hadn't been touched since 2022. Nobody was confident about deleting any of it. The contracts inside might still matter, the board minutes definitely did, and the 19,000 PDFs of supplier invoices from 2018 to 2020 probably didn't, but who's making that call?
We get versions of this conversation a lot. SharePoint grows and storage costs grow with it. The question of what to archive, what to delete, and what to keep gets pushed down the list every quarter because nobody wants to be the person who deletes the wrong thing. Meanwhile the bill keeps climbing and the search experience gets slower because there's too much noise in the index.
The four-step plan below is what we use to take that decision off the floor and put it into a structure. It works for tenancies (the Microsoft 365 setup that holds all your users, files and settings) of any size, and it doesn't require deleting anything until everyone's comfortable.
## Why this matters
Three reasons it's worth doing properly, in order of how often they bite.
The first is cost. Microsoft 365 storage isn't free past the included allowance. For Microsoft 365 the included SharePoint pool is the 1 TB base plus 10 GB per licensed user, so a 25-seat tenancy lands around 1.25 TB; once you're past that, additional storage runs at roughly £0.18 per GB per month. A site that's grown to 4 TB out of laziness is costing roughly £700 a month it doesn't need to.
The second is search and findability. SharePoint's search index works better when there's less in it. When a user types "current expenses policy" and gets six different versions from 2017, 2019, 2021, and 2024, the answer they need is buried. Archiving the old versions properly makes the live document findable.
The third is compliance. UK retention requirements vary by document type: seven years for HMRC records, six years for contracts, two years for some HR documents, indefinite for some regulatory records. A SharePoint estate that hasn't been retention-tagged is one that can neither prove it kept the right things long enough nor prove it disposed of the right things on time. Both fail the same audit.
## Common failure modes
The patterns we see when SharePoint archiving hasn't been done deliberately:
- **One sub-site per decision.** Every reorganisation spun up a new top-level area. The old ones sit there with nobody owning them.
- **Finance dictating the layout.** The site structure mirrors the chart of accounts because that's what the head of finance pictured when SharePoint was first set up. The operations team can't find anything because they don't think in cost-centre codes (we wrote about this stakeholder mismatch in [an earlier post](https://jmo.partners/insights/cctv-wrong-spec/)).
- **Personal drives full of company data.** Half the contracts live in someone's OneDrive (their personal file space in Microsoft 365) because they were drafted there and never moved. When that person leaves, the contracts leave with them unless someone caught it.
- **Versioning chaos.** "Contract_FINAL_v2_revised_jb.docx" sits alongside seventeen other near-identical files. The actual current version is the one nobody can find.
- **No retention labels.** Everything's treated as keep-forever because nobody set the policies. Storage grows linearly with time.
The four-step plan addresses each of these in order.
## The four-step plan
### Step 1: Inventory and classify
What this means in practice: list every SharePoint site and document library, note who owns it, how active it is, and what kind of content sits inside.
You can't archive what you can't see, so start by pulling a usage report from the M365 admin centre. It'll tell you every site, its size, its last-modified date, and how many users have touched it in the last 90 days. Anything that's bigger than 50 GB and hasn't been touched in 12 months is a candidate. Anything that has no listed owner is a candidate. For each one, name the owner today, even if it's an educated guess, and book a 15-minute conversation with them about what's inside.
The classification matters too. There are roughly four buckets: live (in active use), reference (rarely touched but needs to be findable), archive (legally required to keep but not searched), and disposable (no business or legal reason to retain). Every site, every library, slots into one of those.
### Step 2: Set retention labels
What this means in practice: tag each content type with how long it needs to be kept and what happens at the end of that period.
Retention labels are M365's way of doing this properly, but most tenancies we look at have them either not configured or configured once in 2021 and never revisited. The labels you need are simpler than they look. Five or six is enough for most SMEs: HMRC-7-years, Contracts-6-years, HR-2-years, Board-indefinite, General-3-years, Disposable-immediate. Tag the document libraries, not individual files. Files inherit the library's label by default, and the few exceptions can be re-tagged manually.
This is where the finance-led layout we mentioned causes problems. If the site structure follows the chart of accounts, the retention labels have to follow the document type, and the two don't line up. Sometimes the right answer is a partial restructure before labels go on. Sometimes it's easier to live with the friction and over-tag at the library level. Either approach is defensible; the only wrong answer is no labels at all.
### Step 3: Move the disposable, archive the reference
What this means in practice: physically separate the live content from the reference content, and clean out the disposable content with a clear audit trail. Don't delete on day one, move first. Create an archive site (or a dedicated archive library inside each major site, depending on volume) and move anything that's classified reference or archive into it. The live sites get smaller, faster, and easier to navigate. The archive content is still searchable for users who need it, but it's out of the daily flow.
Disposable content gets a 60-day grace period: move it to a hold area, notify the owner, give them the chance to flag anything that shouldn't go. After 60 days with no flags, delete with a logged record of what went and when. That record matters because if someone asks in two years where a 2020 supplier invoice went, you can show that it was reviewed, tagged disposable, given a grace period, and removed.
### Step 4: Set up the rhythm
What this means in practice: schedule the same review on a recurring basis so the estate doesn't drift back.
Archiving isn't a one-off project, it's a rhythm. Quarterly review of new sites that have appeared. Annual review of which sites have shifted from live to reference and need to be moved. Six-monthly check that the retention labels are still right; if regulation changes, the labels follow. The rhythm is what stops the same conversation happening in three years' time.
For most managed clients we hold this rhythm on their behalf. It's about 90 minutes of work a quarter once the initial cleanup is done.
## Where SMEs trip
Two big ones recur.
The first is starting with deletion instead of starting with classification. Somebody decides to "have a clear-out", picks a site that looks old, and deletes it. Three months later, an HR claim surfaces and the records from that era are needed and gone. The discipline is to move first, then classify, then decide, not the other way round.
The second is letting the structure ossify. SharePoint's good at letting you build a structure that worked five years ago and is still in place today, even though the business has changed. The owner of the "Old projects" sub-site is the person who joined in 2019 and left in 2023. New people have built parallel structures because the old one didn't reflect how they worked. The fix is to fold structural review into the quarterly rhythm: not a big-bang reorganisation, but small, ongoing adjustments.
## What good looks like
When this is working, the SharePoint estate is roughly half the size it would otherwise be. Search returns the right document on the first hit. Users know where to put new content because the structure reflects current work. Retention labels are applied at the library level and inherited by default. Storage costs are flat or declining. The compliance answer to "show us your retention policy" is a screenshot of the labels and the dates.
The audit trail is the boring win, but it's the one that matters most when something gets contested.
## Where this lands with us
SharePoint archiving sits inside our Managed Services practice. For managed clients we run the inventory, write the retention labels, drive the cleanup, and hold the quarterly rhythm, it's part of the M365 administration we do anyway. For clients on a self-managed footing we'll do the initial inventory and retention design and hand it over with a scoping sheet.
Either way, the cost of doing nothing keeps rising. The bill goes up every quarter. The audit you can't pass costs you a customer contract. The HR claim you can't defend because the records went missing costs more. And the contracts walking out the door inside someone's OneDrive don't show up until the person's already gone, so tidy beats the alternative every time.
---
*SharePoint usage report looking heavier than it should? Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk) and we'll run an initial scoping pass.*
*Want the printable version of this checklist? Drop us a note at info@jmopartners.co.uk and we'll send it through.*
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# Email security in 2026: the four layers and where SMEs trip
Practice: Security Solutions
Author: Matthew
Date: 2026-05-17
Tags: email security, phishing, DMARC, MFA, security, checklist
URL: https://jmo.partners/insights/email-security-four-layers/
The invoice looked real. It came from the right supplier, referenced the right project, had the right purchase order number, and asked to update the bank details for the next payment. The accounts assistant did what she'd been trained to do, checked the email address, which matched the one in the system, and updated the record. Three weeks later, when the actual supplier called asking where their £14,000 had gone, we walked through what had happened. The sender's address had been spoofed. The real supplier's domain had no email-authentication record published. The invoice itself was a near-perfect copy of a previous one because the attacker had been reading the mailbox for two months via a session token (a temporary login key) they'd phished back in February.
That's a 2026-style email attack. Every layer of defence was either missing or misconfigured. None of the layers individually would have stopped it; together, they would have. Email security splits cleanly into four layers, and defence at any one of them is not enough on its own.
The frame below maps what each layer does, what it doesn't, and where most SMEs we look at have a gap.
## Why a layered model matters in 2026
Two things have changed enough to force the rethink.
The first is that attackers have shifted from one-off spam to long-lived account takeovers. Once an attacker has session-token access to a mailbox they can read everything, learn the writing style, identify pending payments, and time their move. A single layer of defence (spam filtering, say) does nothing once the attacker is already inside.
The second is that the regulatory and underwriting environment has hardened. Cyber-insurance underwriters now expect multi-factor authentication (MFA, needing a code as well as a password, usually a number from an app on your phone) on every account, DMARC enforcement on every outbound domain, and a working incident response process. A policy without these is either getting declined or quoting at multiples of last year's premium.
Layered means each layer assumes the one outside it might fail, and that is the design principle to hold onto.
## The four layers
### Layer 1: Authentication, proving the sender is real
What this means in practice: every email leaving your domain is cryptographically signed and validated so other mail servers can verify it really came from you.
This is the SPF, DKIM, DMARC layer: the three email-authentication settings that tell other mail servers your messages are genuine. SPF says which servers are allowed to send for your domain. DKIM signs each message with a key only your domain holds. DMARC tells the receiving server what to do if SPF or DKIM fail: quarantine, reject, or just report.
The 2026 standard is DMARC at `p=reject`, not `p=none` and not `p=quarantine`. That's what stops spoofed emails using your domain landing in your customers' inboxes. About 65% of SMEs we audit have SPF and DKIM set up; about 20% have DMARC published at `p=none` (monitoring only); fewer than 10% are at `p=reject`. Moving from "no DMARC" to `p=reject` is the single highest-impact email-security change most SMEs can make.
It's also the one most likely to break things if it's done badly. There's always some legitimate mail-sender (the booking system, the email-marketing tool, the accounting platform) that isn't included in the SPF record. Move to reject in a hurry and that sender's mail starts bouncing. The right way is to publish at `p=none` for 30 days, read the reports, fix the misalignments, then escalate to quarantine, then to reject.
### Layer 2: Inbound filtering, blocking what shouldn't reach the inbox
What this means in practice: a filter sitting between the internet and your mailbox that scores incoming messages and blocks the obvious malicious ones.
Microsoft 365 (M365, the Microsoft cloud bundle: email, Word, Excel, Teams, file storage) and Google Workspace both ship with inbound filtering. Both have a free tier and a paid tier; the paid tier (Microsoft Defender for Office 365 or Google's equivalent) is what you actually want, not because it catches significantly more spam, but because it does the sandboxing (opening the link or attachment in a safe test environment first) that catches modern phishing (an email pretending to be from someone trustworthy, asking you to click or hand over credentials).
The phishing emails that get through basic filters in 2026 look almost identical to legitimate emails. Same logos, same writing style, same plausible context. The thing that catches them is sandbox analysis: the filter opens the attachment in a virtual environment, or follows the link to see where it lands, and blocks on the basis of behaviour rather than content.
This layer also covers business-email-compromise detection: the filter notices when an external sender is claiming to be the CEO and flags the message even though it's technically clean.
### Layer 3: Account security, protecting the credentials
What this means in practice: every mailbox is protected by MFA, with session-token revocation in place and impossible-travel detection (login from London at 9am, then Manchester at 9:15) running.
This is where the modern attack lives. The attacker doesn't break encryption, they phish a password, then steal a session token that bypasses MFA for the next 30 days, then sit in the mailbox reading at their leisure.
The 2026 standard is three things: MFA on every account (no exceptions, including the executive assistant and the part-time bookkeeper); conditional access policies that block sign-ins from unusual locations or unusual devices; and session-token lifetimes capped at 24 hours or less for high-risk accounts. The "no exceptions" is the bit that trips SMEs. There's always the director who travels and finds MFA inconvenient, or the finance manager who's exempted from conditional access because of a legacy app. Exemptions are how attackers get in.
If MFA is the single most important access-control on the layer, conditional access is the most underrated. It's what catches the login attempt at 03:00 from a residential IP in Lisbon when the user is in London.
### Layer 4: User awareness, the last line
What this means in practice: every user has been trained to recognise the patterns of modern phishing, knows how to report a suspicious message, and isn't punished for reporting false positives.
The first three layers will stop most attacks. The ones that get through are designed specifically to defeat the technical controls, which means the user is the last line. Awareness training in 2026 is not a 45-minute video once a year; that's a tick-box exercise that doesn't change behaviour. What works is short, frequent, scenario-based training (5 minutes a month), combined with regular simulated phishing exercises that test actual response.
The reporting culture matters as much as the training. If users are afraid of looking stupid for reporting a real email, they won't report the real phishing either. The IT team needs to be able to say "thanks for reporting, this one was legitimate" and walk them through the reason without making the user feel stupid. That's how you build the reflex that catches the next attack.
## Where SMEs trip
Three patterns repeatedly:
The first is treating the layers as alternatives. "We have MFA, so we're fine on email security." MFA without DMARC means your domain can be spoofed at someone else. DMARC without inbound filtering means malicious emails from third-party domains still land. Inbound filtering without user training means the one that beats the filter still wins. The layers compound; they don't substitute.
The second is exempting the executive layer. Founders and directors get MFA-fatigue exemptions, get to use personal devices, get to bypass conditional access. They're also the highest-value targets in the business. The right answer is the opposite: tighter controls on the accounts with the most authority, not looser.
The third is buying the paid filter and never tuning it. The default policies are good but not great. Quarterly review of what's been blocked, what's been released, and which rules need adjusting is what turns a £6-per-user-month spend into a £6-per-user-month spend that actually works.
## What good looks like
When this is working, the email security posture is layered and verifiable. DMARC published at `p=reject` with quarterly reports being read. Inbound filtering paid-tier, tuned, and catching the modern threats. MFA on every account with no exemptions, conditional access live, session tokens limited. Users trained monthly, simulated phishing run quarterly, reporting rate climbing. Cyber-insurance questionnaire fills itself.
The measurable outcome we hold ourselves to is zero successful business-email-compromise incidents per year, and that is the bar we expect a working email-security posture to clear.
## Where this lands with us
Email security sits inside our Security Solutions practice. For managed clients we hold every layer, we publish and tune DMARC, configure the paid filter, set conditional access policies, run the training programme, and handle incident response if something does land. For self-managed clients we'll do the assessment and the layer-1 and layer-3 configuration work and hand over the training programme.
Either way, the £14,000 invoice fraud at the top of this post is a real shape of loss, and it's the small one. The bigger one is the months of mailbox access an attacker had before the fraud landed, the customer data they walked off with, and the cyber-insurance claim that gets queried because the questionnaire said one thing and the reality said another. Four layers, configured and tuned and verifiable, is what keeps that conversation off your calendar.
If a renewal questionnaire is asking about DMARC and MFA and you're not sure where you stand, that's our [Security Solutions](https://jmo.partners/#services) practice. Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk) and we'll do an initial scorecard.
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# UPS refresh: when "still works" isn't the right question
Practice: Managed Services
Author: Oliver
Date: 2026-05-17
Tags: UPS, power, infrastructure, managed-services, refresh, checklist
URL: https://jmo.partners/insights/ups-refresh/
The unit had been sitting in the comms cupboard for eleven years. Beige plastic, two amber LEDs lit, one occasional beep that everybody had learned to ignore. The IT contact pointed at it during the site walk and said the line we hear constantly: "Still works, hasn't given us any trouble." We pulled the front panel off, looked at the date code on the battery (original install, never replaced), and asked when he'd last simulated a mains drop. Nobody had, in his eleven years or before. The next Friday at lunchtime, with the office quiet and a planned five-minute outage notified, we pulled the mains plug. The uninterruptible power supply (UPS, the battery-and-electronics box that keeps the network running for a few minutes when the mains drops) held for 41 seconds before the inverter shut down and the network died.
41 seconds isn't a UPS, it's a placebo, and the unit had been claiming to do its job for half a decade while the batteries invisibly lost capacity. "Still works" was true at the level of the LEDs and false at the level of what the device was for.
This is the most common UPS conversation we have. The frame below is what to ask instead.
## Why this matters more than it looks
Three reasons a tired UPS is worse than no UPS.
The first is false confidence. A working UPS lets the business assume the network is protected, which means the rest of the resilience plan (generators, failover, runbooks) doesn't get attention. A tired UPS gives the same confidence with none of the protection.
The second is graceful shutdown. The real job of a UPS isn't to keep the office running through a power cut. It's to give the kit enough time to shut down cleanly so storage doesn't corrupt. A UPS that holds for 30 seconds instead of the rated 10 minutes can't do that. Servers crash mid-write, file systems need a fsck on reboot (an emergency check that can take hours), and what was meant to be a 20-minute power cut becomes a four-hour recovery.
The third is the invisible risk. UPS batteries degrade predictably: capacity drops to about 80% by year three, 50% by year five, and below useful by year seven. The device doesn't know. The LEDs don't change. The unit reports "online and healthy" right up until the moment the mains drops and there's nothing in the battery to deliver.
## Common failure modes
The patterns we see when UPS estates haven't been managed:
- **Original batteries, never tested.** The most common single failure. Install once, forget for a decade.
- **Wrong-size load.** The UPS was specced for two servers and a switch in 2018. The rack now has six servers, two switches, and a SAN (a shared storage unit). The runtime is a third of what's labelled.
- **No graceful-shutdown trigger.** The UPS holds the load when the mains drops, but nothing tells the servers to shut down. When the battery dies, the servers crash hard.
- **No remote monitoring.** Nobody knows the battery's been at 40% capacity for the last 18 months because nobody's checking.
- **Mixed-age estate.** Two UPSs in two different cupboards, installed in different decades, with different management interfaces and different battery cycles. Nobody owns the schedule.
Each of these turns a piece of resilience infrastructure into a liability.
## The four questions to ask
Forget "still works". The four questions that matter:
### Question 1: When did the batteries last get tested under real load?
What this means in practice: when did somebody actually pull the mains and confirm the UPS held for the time it's meant to?
Self-test cycles inside the unit are useful but not enough. They check the charging circuit. They don't simulate a sustained load draw on the cells. A proper test is to schedule the swap into a quiet window, pull the mains feed, and time how long the unit holds the actual load (not the rated load, the live load). We do this annually on every managed UPS. If the result is less than 70% of rated runtime, the batteries are due.
### Question 2: What load is the UPS actually carrying?
What this means in practice: how many watts of equipment are plugged into it, and what runtime does that imply at the current battery capacity?
UPSs are specified in volt-amps (VA) and watts (W). A 1500VA / 1000W unit will give roughly 10 minutes of runtime at half load and roughly 4 minutes at full load; those are headline numbers from a fresh battery. If the rack has crept up to 90% load over the years, the runtime collapses. The check is to measure: most managed UPSs report current draw in the management interface. If you don't have visibility, plug a clamp-meter on the input for a working day and read the peaks.
A UPS at 90% load is on its way to overload trips. A UPS at 30% load is wasting your money. The sweet spot is 40-60%.
### Question 3: What happens at the end of the battery window?
What this means in practice: does the kit on the UPS get shut down gracefully, or does it crash?
This is the question most often missed. The UPS holds the load for as long as it can; at end-of-battery, the inverter cuts. What's plugged in either has its own UPS-shutdown agent (server connected via USB or network, runs a "save state and shut down" command 30 seconds before the cut) or it doesn't (kit just dies).
For every server on a UPS, there should be a shutdown agent installed and tested. For network kit there usually isn't, since the switches just crash, which is acceptable as long as the recovery is fast. The differentiator is whether anything writeable is on the protected estate without a shutdown agent, that's where the file-system corruption risk lives.
### Question 4: Who's notified when the UPS does something?
What this means in practice: when the mains drops, when the battery goes self-test-failed, when the runtime estimate drops below threshold, does anyone find out in time?
A UPS with no remote monitoring is a UPS that fails without anyone noticing. Modern units have network management interfaces that can email or SNMP-alert when something happens. Setting it up takes 30 minutes and turns the device from a passive box to an active part of the monitoring estate. The alert needs to go to a watched inbox or a monitoring platform, not the same generic `info@` that nobody reads, the same trap we covered in the [SSL post](https://jmo.partners/insights/ssl-renewals-checklist/).
If the answer to all four questions is "yes", the UPS is fit for purpose. If any answer is "no" or "I don't know", it's not, regardless of whether the LEDs say it's fine.
## The decision frame
Run the four questions and the answer falls into one of three lanes.
1. **Refresh the batteries.** Unit is otherwise sound, load is appropriate, monitoring is in place, but the batteries are over three years old or have failed a load test. Batteries are typically £200-£600 for an SME-class unit. Half-day swap, no chassis replacement.
2. **Replace the unit.** Either the unit is over seven years old (capacitors degrade, inverters wear), or the load has outgrown the chassis, or the management interface is too old to do what's needed today. Full replacement, planned outage, typically £800-£2,500 plus install.
3. **Restructure the protection.** The single point-of-failure UPS isn't fit for what the business now is. A second unit in N+1 configuration (one extra, so if one dies the others still cover the load), or a generator behind the UPS, or a move of critical workloads to cloud where the UPS question disappears. This is the conversation when business continuity has outgrown what a single box can deliver.
Most refreshes are option 1 or 2. Option 3 is a longer scoping conversation.
## Where SMEs trip
Two big ones come up repeatedly. The first is delaying the refresh because the UPS "still works". The whole point of this post is that "still works" isn't measurable. The annual load test is what tells you whether the UPS works. If you've never done one, you don't know.
The second is treating UPS as part of the seven-year infrastructure cycle (which we covered in the [hardware refresh post](https://jmo.partners/insights/hardware-refresh-cycles/)) without separating the battery cycle from the chassis cycle. The chassis can run for ten years. The batteries can't run for five. Mix them up and you either replace too often or too rarely.
## What good looks like
When this is working, every UPS in the estate has a known age, a known battery date, a known load percentage, a known runtime under that load, a working shutdown agent on every connected server, and a monitoring alert going to a watched destination. The annual test confirms it. The replacement schedule is on the same 36-month rolling calendar as the rest of the hardware refresh. Nobody describes the UPS as "still working"; they describe it by its measured holdover time, which they know because somebody tested it.
That's the goal: no placebo boxes in the comms cupboard.
## Where this lands with us
UPS management sits inside our Managed Services practice. For managed clients we hold the inventory, run the annual load test, schedule the battery refresh, monitor the alerts, and replace the units when they reach end-of-life. For self-managed clients we'll do the four-question audit and a refresh plan and hand it over.
Either way, the placebo UPS isn't a saved cost. It's a four-hour recovery the next time the mains drops, a corrupted file systemon a server that didn't shut down cleanly, and a board conversation about why the kit you'd paid for didn't do the one job it was bought to do. The four-question audit takes an afternoon, and the replacement plan takes a week.
If you're worried the UPS in the cupboard might be on a placebo run, that's our [Managed Services](https://jmo.partners/#services) practice. Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk) and we'll do the four-question audit.
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# Meeting room tech that actually gets used: the four-question test
Practice: Consulting Services
Author: Jamie
Date: 2026-05-17
Tags: meeting rooms, AV, Teams, hybrid, consulting, checklist
URL: https://jmo.partners/insights/meeting-room-tech/
The room had cost £18,000 to fit out. Wall-mounted screen, ceiling microphones, far-end camera with auto-framing, dedicated meeting-room PC, two HDMI inputs, a touch panel on the table. Six months later we walked in for a kickoff with the same client and watched the operations director set up his laptop, mirror to the wall screen via Chromecast (a small dongle that streams from a phone or laptop), dial Teams on his phone, and prop the phone against a mug because the room mic wasn't picking him up. We asked why he wasn't using the room system. He shrugged. "Nobody ever showed us how, and the last time someone tried, the call dropped twice."
The £18,000 was a sunk cost. The actual meeting was running on a phone and a mug.
This is the meeting-room story we see most often: the technology works on paper but nobody uses it in practice. The four-question test below is what we ask before any meeting-room spec gets approved, because the cost of getting it wrong isn't the equipment, it's a year of meetings that don't quite work and a slow erosion of trust in the room.
## Why meeting rooms are different from other IT spend
Most IT spend lives in the background. A user logs into a laptop, opens email, gets on with their day. The infrastructure doesn't need to be loved; it needs to work.
Meeting rooms are the opposite. They're an interface, a stage that people actually stand on. If the cable doesn't work the first time, the user remembers. If the call drops mid-presentation, the user remembers harder. If the room is awkward to join, people just won't book it; they'll fall back to whatever workaround they've already got. The cost isn't in the dropped calls but in the slow shift where the room becomes the room nobody uses.
Across years of office fit-out work we've seen £25,000 boardrooms that get used for tea meetings because nobody trusts the AV, and £4,000 setups that get booked solid because they're easy. The price isn't the predictor; the four-question test is what tells you which way it goes.
## Common failure modes
The patterns we see when meeting rooms get scoped badly:
- **The IT-spec'd room.** Maximum capability, complex touch panel, three different inputs, nine different scenarios. Demonstrates beautifully, and nobody can drive it without training.
- **The cheap-fix room.** A 65-inch TV, a long HDMI cable, an off-the-shelf webcam clipped to the top of the screen. Joining a call means moving furniture. Audio is hit-and-miss.
- **The single-platform lock-in.** Built for Teams, runs Teams beautifully, falls apart when a customer wants to join on Zoom or Google Meet.
- **The wireless casting that doesn't.** Three different casting protocols (Miracast, AirPlay, Chromecast), none of them reliable, all of them broken when the WiFi is busy.
- **The orphan room.** Installed by the agency that left, never inducted to the team, never serviced, slowly drifts out of working order over 18 months.
Most of these come back to the same root cause: the room was specced for a feature list, not for the actual meeting flow.
## The four-question test
Run these four questions before approving any meeting-room spec: refit, new build, or replacement.
### Question 1: How does the meeting start?
What this means in practice: from the moment someone walks into the room, what are the steps to get a hybrid call up and running with the right people on the screen?
This is the question most often skipped. We've watched meeting-room demos where the consultant takes 90 seconds to start the call (touch panel, select platform, log in, pick the meeting, accept the audio prompt) and the client says "that looks easy". Real meetings start under time pressure. The host is finishing a previous meeting, the remote participant is already on the bridge waiting, two of the in-room attendees are still at the door. The start needs to be under 30 seconds, no logins, no choosing platforms.
The right answer in 2026 is usually a calendar-aware room PC that's already authenticated, the meeting tile on the touch panel one-tap away, and one input source: the room's own. The wrong answer is anything that requires choosing.
### Question 2: Can the remote person hear and see what matters?
What this means in practice: when there are four people in the room and two on a call, does the remote participant hear all four equally well and see who's speaking?
This is the question that justifies the equipment. A good room mic picks up everyone in the room at conversational volume. A good far-end camera frames the speaker. A bad version of either means the remote participant either misses things or has to keep asking people to repeat themselves, and they disengage. We've watched remote participants give up on rooms after the third "sorry, can you say that again?" and never come back.
The test is to sit in the remote seat. Dial the room from a laptop in another room, then have four people hold a normal conversation inside. Can you follow it without effort? If you have to lean in, it's not enough. If you can follow it relaxed, it's fit for purpose.
### Question 3: What happens when someone uses a different platform?
What this means in practice: when a customer sends a Zoom link, or a partner uses Google Meet, can the room still host that meeting cleanly?
Most rooms get specced for the platform the company standardised on, which is fine for internal meetings. External meetings happen on whatever the other party uses, and there are only three platforms anyone uses in the SME space (Teams, Zoom, Google Meet), so the room needs to handle all three. The 2026 answer is a BYOM (bring-your-own-meeting, where the user's laptop runs the call and the room just provides the camera, mic and screen) setup: a USB-C cable on the table that connects the user's laptop to the room's microphones, speakers, and screen. Whatever platform's on the laptop, the room's hardware drives it, with no platform lock-in and no choosing.
This single design choice extends a room's useful life from "Teams-only" to "any meeting", and it's not significantly more expensive than a single-platform room.
### Question 4: Who owns it after install?
What this means in practice: when the touch panel stops responding, the camera firmware needs updating, or the cable in the table well gets bent and stops carrying signal, who's named on the maintenance plan?
This is the question that decides whether the room still works in year three. Most of the rooms we walk into that have failed weren't badly specced; they were unmaintained. The installation agency left. The internal IT lead got busy with other things. The cables in the table well got bent two centimetres too far. Nobody owned the upkeep.
A working room has a named owner on a 12-month maintenance contract: quarterly walk-through, firmware updates, cable check, mic check, far-end test call. Twenty minutes a quarter, and the room stays in the state it was when it was new. Skip it, and it'll be a phone-against-a-mug situation inside two years.
## Applying the four questions
The test isn't pass-or-fail but a structured conversation. Walk through each question with the client, the user representative (somebody who'll actually be running the meetings), and the AV designer. Where answers are weak, push back on the spec before purchase, not after.
A useful sequence:
1. **Walk the room blank.** Before any equipment is named, walk the physical space and map how a meeting actually starts in it.
2. **Run the four questions against the proposed spec.** Each gets a green, amber, or red.
3. **Fix the reds first.** A spec with any red on the four questions isn't ready to order. The whole point is to surface the problem before the £18,000 is spent, not after.
4. **Test before sign-off.** When the room is installed, run the four questions for real. Make a real call. Use a real laptop. Time the start. Sit in the remote seat.
## Where SMEs trip
Two patterns come up repeatedly. The first is letting the AV agency drive the spec. The agency knows their kit but doesn't know your meetings. The kit list comes back as a maximum-capability list, the room ends up over-spec'd and complex, and the people who'll actually use it weren't asked the four questions. The right voices to be in the room are the user, the IT-side designer, and somebody who knows how the business actually runs hybrid meetings, three voices, same pattern we wrote about in our [CCTV scoping post](https://jmo.partners/insights/cctv-wrong-spec/).
The second is the cheap-fix override. Finance looks at the £18,000 quote and asks why a £4,000 setup wouldn't do. Sometimes it would. Often it wouldn't, because the cheap-fix room fails questions 1 and 2, and the cost of an unused room is higher than the cost of a working one. The honest answer is to put numbers against the four questions and decide deliberately.
## What good looks like
When this is working, the room gets booked. People walk in, tap one tile on the touch panel, and they're in the meeting under 30 seconds. The remote attendees stay engaged because the audio and video are good enough that they forget about the room. External customers join cleanly on whatever platform they're on. The quarterly maintenance log shows no surprises. The investment paid back not in dropped calls avoided but in meetings that actually happened the way they were meant to.
That's the goal: a room that disappears into the background, like good infrastructure should.
## Where this lands with us
Meeting-room scoping sits inside our Consulting Services practice. We don't sell AV kit — we sit with the client, the user representative, and whichever AV partner is doing the install, and make sure the four questions are answered before the spec gets signed. For clients without an AV partner we'll bring one in.
Either way, the room you can't trust costs more than the room you can. Every dropped customer call is a deal at risk. Every meeting that runs late because nobody could get the screen to share is a meeting that doesn't end on a clean decision. Spec it once, properly, with the right voices in the room, and the kit fades into the background where it belongs.
If you're specifying a meeting room and not sure the kit list answers the four questions, that's our [Consulting Services](https://jmo.partners/#services) practice. Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk) and we'll sit in on the spec call.
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# Tenancy migration: the unknowns that surfaced in week three
Practice: Consulting Services
Author: Matthew
Date: 2026-05-17
Tags: tenancy-migration, Microsoft-365, consulting, scoping, project-management
URL: https://jmo.partners/insights/tenancy-migration-week-three/
The brief looked clean on paper. A professional-services firm of about 60 people, two offices in the south of England, post-merger, sitting on two Microsoft 365 tenancies (the tenancy is your Microsoft 365 environment, the setup that holds accounts, files, mailboxes and settings; one company, one tenancy is the goal). One tenancy was inherited from the acquired side; one was the acquirer's. The plan was the obvious one: consolidate everyone into the acquirer's tenancy, decommission the other, and move on.
We scoped it as a six-week project. Four weeks of preparation, one week of cutover across a weekend, one week of stabilisation. The kit-list was modest. The user count was modest. The two tenancies looked similar from the outside.
Week three is when most of what we'd planned for stopped being the actual job.
## What we'd scoped for
The plan covered the things tenancy migrations usually cover. Mail flow, OneDrive content, SharePoint sites, Teams, licensing, security policies, conditional access (the rules that decide who can sign in from where), and the SSO links (single sign-on, one set of credentials for the apps people use day-to-day) into the major business apps. We'd pulled inventories from both tenancies, mapped the licence counts, and identified the SharePoint sites that would need to come over versus the ones we'd archive.
We'd also done what we always do, a stakeholder workshop with the office managers and the heads of each practice group, to flag the things that don't show up in an admin console. Shared mailboxes nobody owns. Power Automate flows that somebody set up in 2022 and forgot about. Guest users from old client engagements. Calendar permissions delegated to PAs.
The workshop surfaced a usable list. We thought we had the long tail.
## What actually surfaced
The first real surprise turned up on day three of week three, when the lead from the acquired side mentioned, in passing, that "the legal team uses a separate sign-in for the document review platform — that's still fine, isn't it?" It wasn't on any list we'd seen. The platform had been provisioned against the acquired tenancy two years ago, with SAML (security assertion markup language, an older single-sign-on standard) linked to the old domain. Decommissioning the tenancy would have killed it on cutover weekend.
That conversation triggered a wider sweep. By the end of week three we'd found:
- Three more SaaS tools with SAML links to the old tenancy that nobody had flagged, because the people who provisioned them had left.
- A shared mailbox the marketing team had been using as the inbound for an event series, with two years of replies in it, that wasn't owned by anyone in the current org chart.
- A set of automated workflows pushing files from a client portal into a SharePoint site that was on our archive list. Killing the site would have broken the workflow with no warning.
- Two physical multifunction printers configured to send scans to a mailbox in the old tenancy. One of them had a paper-based handover note next to it from 2023 that said "do not change this".
- A team of six in one of the offices who had built a parallel set of Power Automate flows on their own initiative, depending on the old tenancy's permissions model. The flows worked, and nobody in IT knew they existed.
None of it was anybody's fault. Three years of normal operating turns into a pile of decisions and shortcuts that nobody documents because they're working. A merger surfaces it because every link gets stress-tested.
## How we handled it
We stopped the cutover. The original plan had us cutting over at the end of week four. We told the client we were extending the prep window by two weeks, pushing the cutover to the end of week six and stabilisation into week seven, and we'd absorb the extra preparation time against our original quote rather than re-negotiate it. The cost of cutting over with known unknowns was going to be much higher than the cost of two extra weeks of discovery.
Then we ran a sweep we should probably have run in week one. We pulled every SAML and OAuth (a newer single-sign-on standard used by most cloud apps) integration off both tenancies. We pulled every Power Automate flow, every shared mailbox, every printer-to-mailbox relay. We cross-referenced against the active user list. Anything orphaned got a triage tag: keep, migrate, retire, ask.
The "ask" pile, about 30 items, was the interesting one. We took them to the office managers in batches over a week and got a decision on each. Three were live and important. The rest were genuinely dead and could be retired.
Cutover weekend ran cleanly after that. There were three small issues in the week after, none of them blocking, and they came from places the discovery sweep had flagged.
## What we'd do differently next time
The discovery sweep should have been week one, not a panicked week-three reaction. We'd front-loaded the stakeholder workshop and assumed it would surface most of the long tail. It surfaced about 40% of it.
The other 60% was the stuff nobody currently in the org chart could name, because the people who set it up had moved on. You can't workshop that out of people who don't know it exists. You have to pull it out of the tenancy itself.
So our updated case-study template now has a hard rule: before any cutover date gets quoted, we pull the full integration and automation inventory off both tenancies and reconcile it against the active user list. Orphaned items get triaged before week two. It costs a few extra days at the start and saves a lot of phone calls at the end.
## Practical lessons
A few things worth carrying into any tenancy consolidation project:
- **Treat the workshop as a starting point, not a complete list.** The people in the room can only flag what they know about. Three years of operating creates a long tail of things nobody in the room remembers.
- **The technical inventory is the second source of truth.** SAML integrations, OAuth grants, Power Automate flows, shared mailboxes without owners, printer relays, conditional-access exceptions; pull them all and reconcile.
- **Anything that's been working for two years and isn't owned by anyone is a high-risk item.** It's almost always doing something useful for somebody who hasn't thought about it in a while.
- **Pad the schedule before the cutover, not after.** Stabilisation weeks fill up with rework if discovery was thin. Better to add the time at the front.
- **Communicate the extension early.** Clients tolerate a re-baselined schedule far better than a chaotic cutover.
## Where Consulting Services sits
This is the kind of project where the practice earns its keep. Not because the cutover itself is hard (most of the technical work on a tenancy migration is well-understood) but because the discovery work upstream of the cutover is what determines whether it lands well. That's what our Consulting Services practice does. We'll run the migration end-to-end, or we'll sit alongside your in-house team and make sure the discovery work is doing its job before the cutover date gets fixed.
If you're carrying two tenancies after a merger, or staring down a migration date with a stakeholder workshop that feels too thin, that's our [Consulting Services](https://jmo.partners/#services) practice. We'll either run the migration end-to-end, or sit alongside the in-house team and make sure the discovery work surfaces the long tail before the cutover date gets fixed. Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk) and we'll set up a conversation.
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# People-count: the system that had been counting differently the whole time
Practice: Consulting Services
Author: Oliver
Date: 2026-05-17
Tags: people-count, scoping, occupancy, access-control, consulting
URL: https://jmo.partners/insights/people-count-counting-differently/
We touched on a version of this in our piece on wrong-stakeholder spec writing, the bit where a brief lands from the function that asked the question, and the system that already half-answers it sits in a different function down the corridor.
The brief was three lines. A hospitality group running about a dozen sites across south London wanted a people-count system for their flagship venue. They needed accurate hourly headcount per floor for capacity reporting and staff scheduling. Off-the-shelf occupancy sensors (PIR or ceiling-mounted cameras that count people moving through a zone), tied into a dashboard, with a monthly report.
We quoted it as a four-week install. Hardware, network drops, dashboard configuration, two weeks of bedding-in. The number we landed on was sensible, the technology was proven, and we started the install.
Nine months in, we were in a meeting we did not see coming.
## What looked like the scope
The HR director had set the requirement. She'd been clear about what she needed: a number per floor, per hour, that she could trust for scheduling and for the capacity reports she was filing with the group's operations board. She'd specified an accuracy band of within 5%, and a reporting cadence. The brief was clean, and the kit list followed easily.
We installed eight occupancy sensors across two floors. We commissioned them. We built the dashboard. The numbers came out within the accuracy band on every test we ran. We trained the operations team on how to read the dashboard and handed it over.
For six months the system ran. The operations team used the numbers. The HR director used the reports. We'd moved on to other work for the same group.
## What actually showed up
Month seven, somebody on the finance side started cross-checking the occupancy numbers against the access-control system (the badge-readers on the doors that record who came in, set up four years before our install) for a labour-cost reconciliation. The two systems gave different answers, and not by a few percent but by a meaningful chunk on most days, in the same direction: the access-control system consistently said there were fewer people in the building than the occupancy sensors did.
Both systems had been operating correctly; they were just counting different things.
The access-control system counted unique badge-ins per door per day, with an exit credit if somebody badged out. It treated the building as a single zone and counted heads.
The occupancy sensors counted people moving through a sensor's field of view, by floor, by hour. They counted movements, not unique people. Somebody walking from the kitchen to the bar and back was two movements. Somebody who visited three floors during a shift was a person at every floor.
Both numbers were correct and neither was wrong; they were measuring different phenomena, and the difference between them wasn't a calibration issue but a definition issue.
Worse, and this is the bit that still bothers me, nobody had told us the access-control system existed. It hadn't come up in the brief. Nobody we spoke to in scoping had connected the existing badge data to the new requirement, because the access-control system belonged to facilities and the people-count brief had come from HR. The two departments worked on opposite sides of the same building and didn't talk about counting.
## How we handled it
We sat down with HR, facilities, finance and operations in the same room. It took about an hour. We laid out what each system measured, in plain language, and asked which of the two numbers the group actually wanted to make decisions from.
The honest answer was: a third number that didn't exist yet. They wanted unique-person counts per floor per hour. The access-control system had unique persons but no floor granularity. The occupancy sensors had floor and hour granularity but counted movements, not persons.
We built a reconciliation layer. The badge-in events from the access-control system became the anchor; they gave us a confident unique-person count per day. The occupancy sensor data became the distribution layer, telling us, of those known persons, where they spent their time and at what hours. The dashboard kept the same look, but the numbers behind it were now two systems triangulated.
The accuracy got better and the reports got more useful. The labour-cost reconciliation that had triggered the whole conversation now closed within a percent.
But it was nine months later than it should have been.
## What we'd do differently
The mistake was treating the people-count requirement as a greenfield problem. HR had asked for a system; we'd designed and installed one. We hadn't asked the question we now ask on every scoping call: "what's already counting something like this, even if it's counting it differently?"
That question would have surfaced the access-control system on day one. We'd have built the reconciliation in from the start. The dashboard would have launched with two data sources from the beginning. The numbers would have been right the whole time.
Instead we built a system that was internally consistent and externally orphaned. Six months of decisions got made off numbers that didn't reconcile to the other system in the same building.
We've changed our scoping template since. For any measurement project, whether people-count, asset-tracking, energy monitoring, dwell-time, or anything similar, we now run a "what already measures this?" pass before the kit list goes near a customer. Facilities, security, finance, operations, HR. Five conversations. They take an afternoon. They surface the existing systems that the original requester didn't think about, because they don't sit in the original requester's part of the business.
## Practical lessons
A few things worth carrying into any project that involves measuring something:
- **Two systems measuring "the same thing" almost never measure the same thing.** Access-control counts badges. Occupancy sensors count movements. Wi-Fi association counts devices. CCTV analytics counts detections. They produce different numbers. Surface the definitional difference before the install, not nine months later.
- **The requester is often blind to the other systems in the same building.** HR didn't know facilities had badge data. Facilities didn't know HR had asked for headcount. Operations sat between them and assumed they were talking.
- **Run a cross-departmental scope pass before the kit list.** Five conversations across the function silos. It's the cheapest hour of the project and it pays back many times.
- **If two systems exist, the dashboard should reconcile them, not pick one.** Reconciliation usually means triangulating both, not picking one.
- **A clean kit list isn't the same as a clean spec.** If you've got the right cameras pointed at the right places but you're answering the wrong question, the install is still wrong.
## Where Consulting Services sits
This is the kind of work the Consulting Services practice exists for. Not the install itself (the install was fine) but the upstream scoping pass that surfaces the existing systems and reconciles the definitions before any kit ships. We'll do that work directly, or we'll sit alongside the in-house team writing the spec and make sure the question that didn't get asked, gets asked.
If you've got a measurement project in flight, or a capacity report that doesn't quite tie out to another system in the same building, that's our [Consulting Services](https://jmo.partners/#services) practice. We'll do the upstream scoping pass that reconciles the definitions and surfaces the existing systems before any kit ships. Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk) and we'll talk it through.
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# From four supplier contracts to one: a unified-internet story
Practice: Managed Services
Author: Jamie
Date: 2026-05-17
Tags: internet, suppliers, contracts, managed-services, networking
URL: https://jmo.partners/insights/one-throat-to-choke/
When we picked up the managed-services contract, the first hour I spent in the comms cupboard was the most informative hour of the engagement. The client, a financial-services firm of about 90 people across two adjoining buildings in central London, had four separate internet supplier contracts. Two were primary lines into the main building. One was a dedicated leased line going to a single trading desk on the third floor. The fourth was a fibre going into the smaller building next door, with its own router and its own firewall (the firewall is the device that filters network traffic going in and out).
Each contract had been signed in a different year by a different person responding to a different problem. Each had renewed itself. None had been reviewed against the others. The total monthly spend across the four was somewhere between £3,400 and £3,800, depending on which month you looked at.
## What looked like the scope
The brief from the new operations director was simple. "Cut the suppliers. We've got four bills, four support numbers, and when something breaks nobody owns it." He'd been in post for three months and had spent the first one chasing a phantom outage that turned out to be a routing issue between two of the four suppliers, neither of whom would accept ownership of the problem.
We agreed the headline goal: consolidate to a primary supplier with a backup line, one router, one firewall, one number to call when something breaks. The phrase he used was "one throat to choke." The phrase we used internally was less colourful but meant the same thing.
We scoped six weeks. Audit the four contracts, surface the actual usage on each line, design the consolidated topology, procure, install, cut over, decommission. We assumed the trading-desk leased line would probably stay (those things exist for a reason) and that the rest could collapse into a single primary plus a 4G or sub-fibre backup.
## What actually showed up
At the audit pass the story changed. The two "primary" lines into the main building were both load-balanced, sort of. The load-balancer was a piece of hardware that had been installed in 2019 by a contractor and never reconfigured. One of the two lines was actually dormant. It was costing about £600 a month and carrying almost no traffic. The other was doing all the real work.
The trading-desk leased line was the one that genuinely needed to stay. It had a 99.99% SLA and a four-hour fix commitment. The trading desk's compliance requirements were specific about latency and dedicated bandwidth. We weren't going to touch it.
The fibre into the smaller building turned out to be doing two jobs: providing internet to about a dozen people in that building, and acting as the inter-building link for a set of shared file servers that nobody had documented as living in the smaller building. The shared servers were on a separate VLAN (a way of slicing one physical network into separate logical ones) that crossed between the buildings via the fibre. If we'd cut the fibre and replaced it with a wireless point-to-point or a back-route through the main building, we'd have broken the shared file access for both sides.
There was also a fifth supplier we hadn't been told about. A 4G failover dongle sitting on a cabinet in reception, plugged into the firewall, with a SIM contract someone in finance was paying about £40 a month for. It turned out to be a leftover from an office move in 2022 that had been "temporary" for nearly four years.
## How we handled it
We re-baselined the design. One primary leased line with a 99.9% SLA and four-hour fix, sized for combined peak load plus 30% headroom. One 4G failover built into the new edge router (the legacy dongle went in the bin). The trading-desk leased line stayed, contractually and physically separate, because compliance wanted it that way. A new wired link between the two buildings was ordered on the same primary contract, and the inter-building VLAN moved onto it.
Procurement took longer than the technical work. The leased-line install was eleven weeks from order to handover. We ran the four legacy contracts in parallel until the new line was stable, then decommissioned them in sequence over a fortnight. The trading desk barely noticed. The rest of the office noticed the cutover weekend and a slightly different captive-portal page on Monday.
## What changed and what didn't
The bill came down. Combined monthly spend across the consolidated estate dropped to roughly £1,800-£2,000, depending on usage. That's a meaningful saving, call it 40-45%, but it wasn't the main reason to do the work.
The main reason was the thing the operations director had asked for. One supplier to call. One firewall to configure. One set of monitoring credentials. When something went wrong over the following twelve months, and things went wrong twice, both times for under an hour, there was no question of who owned it.
What didn't change, interestingly, was perceived speed. The legacy estate had been mostly fine on day-to-day throughput. The new line was technically faster on the test rig, but most users didn't notice, and the win was never going to be speed; it was clarity.
## What we'd do differently
The audit pass should have been more thorough on undocumented hardware. The 4G dongle in reception was a small thing, but it was a small thing nobody knew about, plugged into the production firewall. We've extended our onboarding checklist for managed-services takeovers to include a physical walk of every comms cupboard, reception desk, and cabinet, with a photo and a label.
We should also have surfaced the inter-building VLAN earlier. Catching it in week three pushed the leased-line order back a fortnight, and that fortnight stretched the project by three weeks at the back end. Assume any second site is doing more than it looks like, and check.
## Practical lessons
A few things worth carrying into any supplier-consolidation project:
- **Count the suppliers physically, not contractually.** Walk every cupboard. Photograph every router, dongle, modem, and unlabelled box with a blinking light. Reconcile against the contract list. There will be at least one item that doesn't match.
- **Audit usage before you cut.** A primary line that turns out to be dormant is common. So is a backup that's been carrying the load for years because the primary died and nobody noticed.
- **Some lines genuinely need to stay separate.** Trading desks, healthcare links, point-of-sale, building-management systems. Don't roll them up just because the spreadsheet looks cleaner.
- **The headline saving isn't usually the point.** Cost reduction is the easy number to put in the case for change. The real benefit is operational: one supplier, one number, one accountable party when something breaks.
- **Procurement timelines dominate the project plan.** The technical work is days. The leased-line lead time is months. Order early.
## Where Managed Services sits
Consolidation projects are where Managed Services earns the relationship. Once the estate's tidy, with one supplier, one firewall, one monitoring view, the day-to-day support is dramatically easier. We can see what's going on, we know who to call, and we can spot a problem before the client does, which is the practice doing its job in steady state.
If you've inherited a tangle of legacy contracts and you're tired of nobody owning the problem when it lands, that's our [Managed Services](https://jmo.partners/#services) practice. We'll unwind the supplier sprawl, consolidate to a single accountable view of the estate, and stay in the relationship so the day-to-day support gets dramatically easier. Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk) and we'll start the conversation.
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# XDR rollout for a 50-seat SME: what changed and what didn't
Practice: Security Solutions
Author: Matthew
Date: 2026-05-17
Tags: XDR, MDR, security, endpoint, SME, rollout
URL: https://jmo.partners/insights/xdr-rollout-50-seat-sme/
The client had been a managed-services customer of ours for about two years when the cyber-insurance renewal landed. A creative agency of just under 50 people across one office in south-east London, mostly Mac-led with a Windows fleet on the finance and ops side. The renewal questionnaire had grown by about a page versus the previous year, and one of the new questions was direct: do you have an XDR or MDR solution deployed across all endpoints?
XDR is extended detection and response, the modern security platform that watches laptops, network and cloud for suspicious behaviour, with the ability to isolate a machine if something looks bad. MDR (managed detection and response) is the same capability run as a service. The client had neither. They had a well-patched Mac and Windows estate with some endpoint anti-virus (the older "scan files for known bad stuff" tool) left over from the previous IT contractor. The insurer wasn't going to renew on those terms.
## What looked like the scope
The brief was time-boxed by the renewal date, ten weeks before the existing policy lapsed. The client needed deployment across all 50 endpoints (the laptops, desktops and a small number of phones the team actually worked on), written evidence for the insurer, and a sustainable operating model. Somebody had to be looking at the alerts.
We scoped a six-week rollout with two weeks of monitoring tuning afterwards. Vendor selection had been narrowed by the client's preference for a stack that played well with Microsoft 365, and by our preference for a vendor with a usable Mac agent. We ran a two-week pilot with the shortlisted product on a dozen endpoints across design, finance, account management, and leadership. The agent was unobtrusive, the dashboard was readable, the pricing landed inside the renewal-driven budget. We placed the order and started the wider rollout.
## What actually showed up
Three things surfaced in the rollout that we hadn't fully scoped for.
**First, the Mac fleet was less standardised than we'd thought.** About 80% of the Macs were on the current OS with the agent deploying cleanly. The remaining 20% were on older versions. One designer was still on macOS Monterey because of a plug-in that hadn't been updated. The agent ran on the older versions, but with reduced telemetry. We landed on a hybrid: most older Macs got upgraded with the user's consent; three were left on the older OS with the gap documented for the insurer.
**Second, the agent surfaced things on day one that the existing AV had no visibility on.** Not malware: behavioural signals. A finance laptop running an unauthorised remote-access tool the user had installed themselves. A creative director's machine with a browser extension exfiltrating clipboard data (copying what users had on their clipboard out to a third party in the background) to an unapproved analytics service. Two laptops with cached credentials for systems the users had no business accessing. None were urgent in the "we're being attacked right now" sense, but every one was a real finding the previous AV had no way of seeing. We triaged them with the client over a week, documented and resolved each item, and none required a full incident response.
**Third, the alert volume in the first month was higher than we'd budgeted for.** Every XDR deployment generates noise in the first 30-60 days while the baseline of normal gets established. We knew this in the abstract. We hadn't fully translated it into "you'll need to spend about six hours a week on alerts for the first month, then it drops off." The client's in-house ops person was sandbagged for a fortnight while we tuned the baseline. We absorbed the tuning as part of the project. By week eight the daily volume was sustainable, with us in the loop for anything escalated.
## How we handled it
The framing we landed on with the client was: this is two projects, not one. Project one is the rollout: agent on every endpoint, insurer's evidence in writing, renewal date hit. Project two is the operating model: who's looking at what, on what cadence, with what escalation path to us.
We delivered both. The rollout closed on week six with documentation signed off. The operating model came together over the following four weeks, settling into a rhythm where the in-house ops person triaged daily alerts, we got a weekly summary, and anything classified high-severity routed to us in real time. The insurer accepted the evidence. Renewal landed at a roughly comparable premium to the previous year, which, given how much that market has hardened, counted as a win.
## What changed and what didn't
What changed: visibility. The client now sees what's happening on their endpoints in a way they previously didn't. They've caught two phishing-triggered credential events in the months since, both contained within minutes by the agent isolating the machine. Neither would have been caught by the previous AV. The in-house ops person has built a working understanding of what normal looks like and when to raise the flag.
What didn't change: the work the agency does or, for most of the team, how their laptop feels. The agent is, as advertised, unobtrusive. The one exception was the design team. A few people noticed a brief slowdown during the daily scan in the first fortnight. We moved the scan to a different time of day and the complaints stopped.
What also didn't change: their need to keep doing the basics. XDR doesn't replace patching, MFA (multi-factor authentication, a code as well as a password), backups, training, or a sensible password manager. It catches the things that get past those layers. XDR is not a silver bullet, and the client needed to hear that explicitly before signing.
## What we'd do differently
Two things stand out in hindsight. First, the operating model should have been scoped from week one, not bolted on at week six. We treated the rollout as the project and the alert-handling as the follow-up. In practice the two are inseparable. A deployed XDR that nobody's looking at is more dangerous than no XDR, because it gives the impression of cover without delivering it. Next time we'll scope the operating model alongside the rollout and bring the alert-handling owner into the project from day one.
Second, the OS standardisation pass should have happened before the rollout, not during. Catching the older macOS instances during deployment created some friction we could have removed by running a one-week patch-and-version sweep two weeks before the agent install. We've added that step to our XDR rollout template.
## Practical lessons
A few things worth carrying into any XDR or MDR rollout in an SME:
- **The insurance question is increasingly direct.** "Do you have XDR or MDR" appeared in roughly two-thirds of the SME cyber-insurance renewals we saw in the last 12 months. Plan for it.
- **Mac fleets aren't as homogeneous as they look.** Run an OS audit before the agent install. The older outliers will need a decision.
- **Day-one findings are normal, and useful.** Don't panic. Triage them, document them, fix them. The insurer cares more that you can see them than that they exist.
- **First-month alert volume needs explicit budget.** Six hours a week for the first month, dropping to one or two thereafter, is a reasonable rule of thumb.
- **Operating model and deployment are the same project, not consecutive ones.** A deployed agent with no human watching it is a worse outcome than a tighter deployment with clear ownership.
- **XDR doesn't replace the basics.** Patching, MFA, backups, training, password manager. The order of operations matters.
## Where Security Solutions sits
XDR rollouts are a representative chunk of what Security Solutions does for SMEs. The deployment is the visible part. The operating-model design and the ongoing alert-triage relationship are the parts that make the deployment worth doing. We'll deliver both, and we'll co-pilot with an in-house team where one exists.
If you're working through an XDR or MDR decision and not sure where to start, that's our [Security Solutions](https://jmo.partners/#services) practice. Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk) and we'll walk through the operating-model questions before the procurement questions.
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# Rogue access points, unlabelled clients, and the audit that couldn't be "complete"
Practice: Security Solutions
Author: Jamie
Date: 2026-05-17
Tags: network-audit, wifi, access-points, security, rogue-devices, audit
URL: https://jmo.partners/insights/rogue-aps-unlabelled-clients/
The brief came from the IT manager of a shared workspace operator, about 350 desks across three London buildings, with around 80 client tenant companies on the floors. The network had grown organically over a decade. Three different IT managers had come and gone. The current one had been in post for six months and had inherited a topology diagram that, in his own words, "is more of a suggestion than a record."
He asked for a security audit. What he wanted on paper was a clean inventory: every access point (AP, the WiFi unit on the wall or ceiling), every switch (the network box in the comms cupboard that wires everything together), every device connected to the corporate VLAN (virtual LAN, a way of slicing one physical network into separate logical ones), every device on the tenant VLANs. We told him up front that a "complete" audit of an environment like this was probably impossible. He laughed and said "I know, give me the best version of impossible you can."
## What looked like the scope
We scoped four weeks. Discovery sweep across all three buildings, port-by-port physical labelling of every switch (the port is the socket on the switch where a cable plugs in), AP inventory with location and ownership tagged, a client-device fingerprint pass across each VLAN, written report with prioritised findings.
Tooling was standard: network discovery scans on each VLAN, MAC address (the unique hardware identifier built into every network card) and DHCP (the system that hands out IP addresses to devices that connect to the network) correlation, controller dump from the UniFi infrastructure, physical walks of each comms cupboard, weekly sit-down with the IT manager. The wired estate was what we'd expected, sprawling, partially documented, three switch generations from three different installers. The interesting things showed up in the wireless and the unlabelled client devices.
## What actually showed up
Three categories of finding dominated the report.
**Rogue access points.** Six APs across the estate that weren't on the operator's UniFi controller. Three were old units from a previous install, left on the ceiling, broadcasting on four-year-old firmware. The other three were more interesting: APs that client tenants had brought in themselves, plugged into the operator's switch ports, and configured with their own SSIDs (the WiFi network name users see when they pick a network on their phone). A small Netgear unit in a corner office, a TP-Link mesh node on a windowsill, and a UniFi unit a tenant's own IT contractor had installed without asking. From the operator's perspective, all three were rogue. From the tenant's perspective, they were just "our WiFi."
**Unlabelled clients.** About 40 devices across the corporate VLAN that we couldn't pin to a known owner. Most turned out to be benign: a PA's old iPad still associated, printers configured by previous staff with no record of who owned them, a CCTV recorder plugged in by facilities in 2022 with no documentation. A handful were less benign: two tenant-owned laptops connected to the corporate network rather than the tenant guest network, one by accident, one by deliberate choice because "the corporate WiFi was faster."
**Clients going around policy.** Some tenants were operating in ways that bypassed the operator's rules. Two were paying for a smaller bandwidth tier than they were actually using, because they'd connected their own APs to switch ports they shouldn't have been on. One tenant was using a port that had been disabled three years ago and then physically re-patched by somebody since. We couldn't tell who, and neither could the IT manager. Two were running their own VLANs piggybacking off the operator's switches through tags that hadn't been removed when the previous occupant left.
None of it was malicious in the headline sense. There was no obvious data exfiltration (no signs of data being copied out to an attacker). But the operator's network wasn't operating the way the operator's policy said it should, and the audit surfaced exactly how.
## How we handled it
The honest first move was telling the IT manager the audit could not be "complete" in the way the brief had implied. A network with 350 desks, 80 tenants, ten years of layered installs, and physical access to switch cupboards by multiple parties isn't auditable to the standard of a closed corporate environment. Anything we called "complete" today would be stale next month.
What we delivered instead was a "known state" report in three sections: what we found and verified (the labelled inventory, rogue APs, unlabelled clients, policy bypasses); what we found but couldn't verify (port activity and MAC addresses we couldn't tie to a definite source); and what we know we didn't look at (cupboards in tenant-controlled suites, devices powered off during discovery, anything behind tenant-owned firewalls). We told the IT manager section three needed to be explicit in his report to leadership. The alternative, pretending the audit was complete, would create a worse problem the first time something went wrong in an area we hadn't looked at.
Then we worked through the remediation. Old rogue APs got removed. Tenant-installed APs got a conversation: either move onto the operator's WiFi, or formally provision an isolated VLAN on a dedicated port with appropriate billing. The re-patching got addressed with physical port locks on the switches and a sign-off process for any new patching. Unlabelled clients got triaged into known-and-acceptable, known-and-needs-removing, and unknown-and-investigate.
The "ongoing audit" recommendation became the central output. Not a one-off audit, but a recurring discipline: a quarterly walk of cupboards, a monthly controller-vs-physical reconciliation, and a clear process for tenant onboarding and offboarding that closed the door behind them.
## What we'd do differently
The mistake, partly ours and partly inherent to the brief, was accepting "audit the network" as a complete deliverable. Networks of this kind aren't audited; they're managed. A point-in-time snapshot starts going stale the moment the report is signed. If we ran this brief again, we'd reframe the deliverable as "baseline plus operating model": the audit creates the baseline, the operating model keeps it accurate.
The other thing we'd do differently is the tenant conversation. We left those to the IT manager. Six months in post, he didn't have the institutional authority to have them cleanly with tenants who'd been there for years. Some stalled. Two months later we ended up running them alongside him, but by then the tenants had had time to dig in.
## Practical lessons
A few things worth carrying into any network audit in a shared or fast-growing environment:
- **"Complete" is the wrong word.** Frame the deliverable as known-state with explicit unknowns. Tell the truth about the gap.
- **Walk every cupboard, label every port.** It sounds tedious. It's the single most useful thing we did on this engagement.
- **The unlabelled clients pile is always larger than you expect.** Plan for it, and budget the triage time at the start of the engagement.
- **Rogue APs are almost always there.** Old installs left behind, tenant-installed units, sometimes a sales-engineer demo from years ago. Find them with a wireless survey, not just a controller dump.
- **Switch-port physical security matters.** If tenants can re-patch ports themselves, the logical policy doesn't matter; the physical layer overrides it.
- **The audit is the easy bit. The operating model is the work.** Build the recurring discipline into the engagement, not after it.
## Where Security Solutions sits
Network audits in shared, sprawling, partially-documented environments are some of the most useful work the Security Solutions practice does, and some of the most uncomfortable, because the findings are rarely what the brief asked for. We'll run the audit, we'll build the baseline, and we'll stay in the relationship to keep the baseline accurate, because that ongoing relationship is where the real value sits.
If your topology diagram is "more of a suggestion than a record," that gap is already costing you. The next incident will land in an area the diagram doesn't cover, and the recovery cost will be a multiple of what a baseline audit would have been.
If you've inherited a network you don't quite trust and need somebody to help you draw a baseline, that's our [Security Solutions](https://jmo.partners/#services) practice. Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk) and we'll set up a conversation.
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# When the wrong people write the spec: a story from a CCTV install
Practice: Consulting Services
Author: Oliver
Date: 2026-05-16
Tags: CCTV, scoping, project-management, security, consulting
URL: https://jmo.partners/insights/cctv-wrong-spec/
It was the third walk-around of the day. The corridor ran the length of the first floor, fire doors at both ends, a kink where it joined the stairwell, and one of those flat ceilings you get in a 1980s office where the lights are sitting slightly the wrong height. The operator from the existing security firm was pointing at the ceiling tiles.
"Cameras here, here, and one above the door at the end. Should give us full coverage."
He'd spent six years watching feeds from buildings like this one. He knew what a useful image looked like when somebody tailgated a fire door. He knew which faces the existing cameras struggled with, and he'd built his own mental map of where the previous install had let them down. When the client looked at who to send to scope the upgrade, he'd been a sound choice.
He wasn't the right person to spec where the cameras went.
## Why the operator wasn't the right pick
The cameras he'd picked positions for were lensed for a different distance to the one he was looking at. The corridor would clip out at 8 metres; the camera he'd chosen was good for around 4. The cable run he'd assumed available went through a fire compartment we'd be cutting holes in. The first camera's field of view (FOV, the angle of what a camera actually sees) would lose half a metre every time the fire door opened against the wall, which in that building was almost every five minutes during the day.
None of this is something an operator gets exposed to. They watch the feed. They don't pull cable. They don't read FOV diagrams. They don't argue with a fire officer about compartmentation. Asking them to spec the install is asking somebody fluent in the result to design the system that produces it. It's not the same skill, and it's not unkind to say so.
We pushed back. Politely. Got the operator and the building's operations manager in the same room (the second person had door-flow data we hadn't seen) and walked the site again. Different cameras, different positions, two added, one dropped. The spec changed in about an hour.
## The wider pattern
This isn't a security-firm problem so much as a wrong-stakeholder problem, and we see versions of it on most projects.
**Finance picking the SharePoint structure.** The team that lives in the spreadsheets every day doesn't get asked. Six months later, somebody's asking why the site map looks like a chart of accounts and where the contracts have gone.
**HR specifying a people-count requirement.** The brief comes back as "headcount per floor per hour". Nobody asked whether the existing access-control system already counted that, slightly differently. It did. The reconciliation conversation surfaces nine months in and runs for the rest of the year.
**Procurement scoring an internet-supplier RFI.** Cost columns front and centre, SLA (service-level agreement, the supplier's uptime commitment) and throughput in a footnote. The procurement process worked but the network didn't.
**An IT manager spec'ing their own replacement system.** Easy to be charitable about who they think the next admin should be, and easy to under-spec for somebody less senior than them. The new admin walks in and the system makes no sense.
In each case the person writing the spec isn't malicious or careless. They're the wrong voice for the question.
## Three voices for a usable spec
After enough of these, we've ended up with a rule of thumb. A spec needs three voices in the room:
1. **The user.** Whoever uses the system day-to-day, not "somebody from their team" but the people on it. They know what's missing, what's annoying, what the current system fails at. They write the use-case half of the spec.
2. **The system designer.** Somebody who knows the cabling, the lensing, the FOV, the licensing model, the failure modes. They translate the use-case into a set of choices the install will land on. They write the implementation half.
3. **The building / data flow voice.** Operations, facilities, IT, whoever knows the things that aren't on the user's mind and aren't in the designer's catalogue. Door behaviour. Existing systems that already measure something similar. Network paths. Fire compartments. Power.
When one of those voices is missing, the spec lands somewhere that looks right on paper and goes wrong somewhere on site.
It's not always three different people, and it doesn't always need a formal meeting. On a small project the operations manager might cover voice 3 in two emails. On a bigger one you'll want a workshop. The discipline is recognising the three voices and making sure they're all represented before the kit list goes out.
## Where this lands with us
We push back early when this pattern shows up. Not because the stakeholder is wrong about what they need (they're usually right about that) but because a spec needs all three voices before it's safe to sign off.
That's our Consulting Services practice. We'll do the spec work directly if it helps, or sit alongside whoever's writing it and make sure the third voice is in the room. Either works. What doesn't work is letting a one-voice spec ship.
## A short checklist for next time
Before signing off any spec, whether CCTV, network, SharePoint, people-count, internet supplier or anything else, three quick questions:
- **Who's the user?** Are they in the room? Not their manager, not a representative. Them.
- **Who knows the system?** If the use-case is clear but the system-side is hand-wavy, find somebody who can speak to lensing, throughput, licensing, failure modes.
- **Who knows the building?** What's already there that this needs to coexist with? What's the data already saying? What runs through the wall behind the camera?
If the answer to one of those is "nobody", stop. Find the voice before the spec goes any further. It's a much cheaper hour than the rework that follows.
---
That CCTV install landed cleanly in the end. The kit list was different from the original spec by about four lines. The cost was within £400 of where we started. The corridor coverage actually works.
What changed wasn't the cameras, but who was in the room.
The cost of a one-voice spec isn't a line item but the rework four months in, the second mobilisation fee, the security director explaining to the board why coverage doesn't reach the back stairwell, the install that has to be ripped out before the building insurer signs off the policy. Across the founders' careers we've watched all of that land in real projects. The hour you spend finding the third voice now is the hour that saves you the project later.
---
*Working through a project where you suspect the wrong voices are in the room? Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk). One of us will read it.*
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# Three projects we should have split into six
Practice: Consulting Services
Author: Matthew
Date: 2026-05-16
Tags: project-management, scoping, consulting, discovery
URL: https://jmo.partners/insights/three-projects-six/
The project was a tenancy migration, moving everyone from one Microsoft 365 setup (accounts, mailboxes, files, settings) to another. We'd scoped it to six weeks, signed the statement of work, agreed the cutover weekend. Week three, doing the user-mailbox audit, somebody on the client side mentioned the shared inbox the warehouse team used. Nobody had hidden it; we just hadn't been told, and it hadn't surfaced when we'd asked who used what.
Two days later, we found a Microsoft 365 group (a shared workspace tying a mailbox, calendar and files together) nobody was tracking that owned half the project files. The week after that, a third-party booking tool we'd been told was "going away" turned out to be very much not going away, and the calendars it wrote into were being read by the operations team without anyone realising it.
The migration still happened. It happened three weeks late and £6,000 over, and the client was generous about it. That's what you get when you've signed a fixed scope and the discovery work has to keep pretending the scope is fixed.
## The shape of the problem
You meet the client. You agree what's in. You write the statement. You sign it. You start work. Then you find things.
You find a feature in the existing system nobody mentioned. An area of the network that doesn't appear on the diagram. A connection between two apps that wasn't on the integration list. A place where the existing setup is doing something useful by accident, and "useful by accident" is the most dangerous kind of useful, because nobody can tell you what it's for until it stops working.
This isn't a fault. The client doesn't know what they don't know. Half the time the person you're scoping with has only been at the company eighteen months, and the system was built by somebody who left in 2021. The diagram on the whiteboard is the diagram somebody drew the last time they tried to map it, not the diagram of what's actually running.
So you find things. And then you have a choice. You can absorb them into the project, take the time and cost hit, and hope you don't find too many more. Or you can stop, restate the scope, and split the project.
Most of the time, neither side wants to split. The client's already approved the budget. We've already mobilised. Splitting feels like admitting failure. So we plough on, and three weeks later we find another thing, and another, and the project that should have been six weeks is fourteen.
## What we should have done
The three projects in the title were all like this: one tenancy migration, one network rebuild, one CCTV-and-access-control consolidation. In each, the discovery phase surfaced enough unknowns in the first fortnight that we should have stopped, written a second statement of work for the things we'd found, and run them in series. Phase 1 was what we knew about. Phase 2 was what we'd discovered.
Instead we ran each as one project. Each ran long. Each ran over. Each landed, but the journey was uglier than it needed to be, and in two of the three cases the client's internal team got worn down by it in a way that hurts the relationship for months after.
The six would have been: tenancy migration plus AD cutover; network rebuild plus WiFi survey; CCTV head-end refresh plus access-control re-keying. Different teams, different vendors, different sign-offs, but the same client and the same overall scope. The work doesn't shrink when you split it; the surface area for surprise does, because each phase has a tighter brief and a shorter discovery tail.
If we'd split, the maths would have been kinder. Phase 1 ships on time. Phase 2 starts with a proper scope (the unknowns from Phase 1 are now known) and lands cleanly. Total elapsed time is roughly the same; sometimes a bit longer. But the budget conversation happens once, up front for each phase, not as a running argument across one ballooning engagement.
We don't split mostly out of inertia. Restating scope mid-flight feels like bad project management, but the real bad project management is pretending the scope is fixed when the ground keeps moving.
## A two-week stop-check
We've started building a stop-check into the front end of projects that look like they have discovery risk. At the end of week two, or week three on a longer engagement, we hold a structured review. Three questions:
- **What have we found that wasn't in the original scope?** Listed, not waved away.
- **How big is each item?** Hours, not handwaves. If we can't size it, we say so.
- **Does the original scope still make sense, or do we need a Phase 2?**
If the answer to the third question is "yes", we restate. We write a Phase 2 brief, sometimes a paragraph, sometimes a page, and the client decides whether to approve it now, defer it, or roll some of it into Phase 1 and accept a revised timeline for the rest.
The hardest part of this isn't the meeting but giving ourselves permission to have it. We're trained to be the firm that delivers what we said we'd deliver, in the time we said we'd deliver it. The discipline is recognising that what we said we'd deliver was based on the picture we had at the time, and the picture changed.
## Where this lands with us
This is where our Consulting Services practice does its most useful work, sitting alongside the project, not inside it. A consulting voice that can call a stop-check and restate scope without the political weight of being the delivery team is worth more than its day rate. We'll do that as a standalone engagement, or build it into a larger project as a named checkpoint.
The principle's small. If you find things mid-project (and you will), the right answer is usually to split, not to absorb. Two clean projects beat one messy one. The client gets a deliverable on the date you promised. The unknowns get their own scope, their own budget, their own air.
We're trying to make "let's split this" a less awkward sentence to say.
If you're three weeks into a project that's been running for six and the unknowns are still arriving, the meter is already running against you. Every extra week of absorbed scope costs in three places at once: the budget you've already agreed, the team morale on both sides, and the next project the same client was going to give you. The choice isn't whether to have the conversation, but whether you have it now, while there's still a clean cut available, or later, when there isn't.
---
*Working through a project where the unknowns keep stacking up? Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk). One of us will read it.*
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# Why we end up rebuilding networks we didn't design
Practice: Managed Services
Author: Jamie
Date: 2026-05-16
Tags: networking, UniFi, managed-services, infrastructure
URL: https://jmo.partners/insights/rebuilding-networks-we-didnt-design/
The cabinet in the comms room had eleven switches in it. Three brands. Two of them daisy-chained off a fourth switch sitting on top of a filing cabinet outside the room, on a desk extension lead. The patching was tidy in the front. The back was a mess of grey leads that all looked the same, no labels, and a single VLAN (virtual LAN, the way you carve one physical network into separate logical ones) that everything sat on, including the guest WiFi and the till system.
The client had inherited it. The previous IT supplier had bolted on what the business asked for, one quarter at a time, for about seven years. Each bolt-on was reasonable in isolation. Stacked up, the network had become something nobody could safely touch.
We were called in to "fix the WiFi". Eight weeks later we'd replaced sixty per cent of the cabling, retired four switches, reconfigured every access point (AP, the WiFi box on the wall or ceiling), and built a VLAN structure that separated guest from staff from till from CCTV. The WiFi was fine, and the WiFi had never really been the problem.
## How networks get like this
Nobody designs a network like this; they evolve into one, and the pattern's almost always the same.
Year one, a small business buys a router and a switch and a couple of APs. Somebody plugs it in. It works. Year two, they add a till system, and somebody runs a cable to it. Year three, the office grows by ten desks, and another switch goes in to handle them. Year four, somebody installs CCTV and the installer asks for a network drop, which gets dropped wherever there's a free port. Year five, the WiFi gets flaky in the back office, so an extra AP gets fitted. By year seven, nobody alive in the building can draw the network.
Each step was sensible, each was the cheapest available option at the time, and none of them involved going back and rethinking the whole.
The cost shows up later. Throughput problems that nobody can diagnose because the network has no shape. Security exposure because the till system shares a broadcast domain (one flat segment where every device can talk to every other) with the guest WiFi. Renewals that get harder every year because the kit is from four eras and three vendors. A new tenant who can't move into the upstairs floor because the cabling won't reach.
## Why we end up rebuilding rather than patching
When we get called in, the temptation is to do the small fix: replace the dodgy AP, run a new cable, get the WiFi stable. We've done it, and it works for about six months. Then the next thing breaks, and the next, and we end up doing the rebuild anyway, but in pieces, more expensively, with the client paying for the same site visits twice.
So we've changed how we respond. If the network is past a certain threshold of accumulated decisions, we'll quote the small fix, but we'll also tell the client what's underneath. The cabinet photo helps. So does walking them through the VLAN structure, or the lack of one. Most of the time, once they've seen it, they'd rather do the rebuild than keep paying for sticking plasters.
Not always; sometimes the answer is "we'll live with it for another two years, then refresh as a project". That's a fine answer if it's made with eyes open. The wrong answer is "we'll keep patching and hope nothing breaks".
## What we'd have done from the start
This is the part that's harder to say without sounding clever in hindsight. But if we'd been the firm in year one, the network we'd have built doesn't look like the one we end up rebuilding. The difference isn't kit; it's three small disciplines:
**Patch panel, every drop labelled, both ends.** Every cable goes to a panel, every panel port has a number, and the number gets written down. Takes an extra hour at install, saves a day every year afterwards.
**VLANs from day one, even when you don't need them.** A till system on its own VLAN costs nothing to set up when the network is being built, but costs three days when you're retrofitting. Same for CCTV, guest WiFi, and anything that talks to a payment system.
**A diagram you can actually trust.** Drawn once at install, kept on a single page, updated every time a switch or AP changes. It doesn't need to be pretty, it needs to be true. A networks-of-Theseus problem is what happens when nobody owns the diagram.
These aren't expensive; they're discipline. And discipline is exactly what gets compressed out when each year's network change is treated as a one-off, costed individually, and approved by somebody who's not thinking about year seven.
## Where this lands with us
This is the heart of our Managed Services work, being the firm in year one who's also still there in year seven. We design as if we'll be the ones picking the network up again later. Sometimes that means slightly more spend up front. It always means a smaller bill at the rebuild, because the rebuild is smaller, or doesn't happen at all.
The hidden cost of buying network in pieces, from whoever's cheapest each year, is that you eventually pay somebody to undo it. We've been on both sides of that bill. The undo is the more expensive half.
## In summary
If you've got a comms cabinet you're nervous about opening, that's information. The network's telling you something. The till that drops mid-transaction, the CCTV camera that goes dark on Mondays, the WiFi that needs a router reboot in the morning, those aren't quirks but early signs of a network you've outgrown. Hear it now and you've got a planned project. Hear it at 2am on a Friday when the till stops talking and you've got a crisis, and the cost of crisis is never a quote you'd have accepted in cold daylight.
---
*Wondering whether your network is overdue a proper look? Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk). One of us will read it.*
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# The cyber-insurance questionnaire that caught everyone by surprise
Practice: Security Solutions
Author: Oliver
Date: 2026-05-16
Tags: cyber-insurance, security, MFA, CE+, compliance
URL: https://jmo.partners/insights/cyber-insurance-questionnaire-surprise/
The questionnaire landed on a Friday. The renewal was due in twelve working days. The finance director forwarded it to the operations manager, who forwarded it to us with a single line in the body: "Can you have a look at this, most of it is gibberish to me."
It wasn't gibberish, but a 28-question cyber-insurance proposal form from a mainstream UK insurer, asking the kinds of things insurers were asking in 2022 plus a few they weren't. MFA (multi-factor authentication, needing a code as well as a password) on all admin accounts. EDR (endpoint detection and response, security software that watches the laptops and tablets people work on) on all endpoints. Offline backups. Privileged access management (PAM, tight controls on who can do admin-level things). Email filtering with link-rewriting. Incident response plan. Tested in the last twelve months.
The client had four of the things on the list, though they thought they had eight. The gap was the conversation we then had with the finance director on the following Monday morning.
## The pull-back habit
Three of the gaps had been on a security roadmap we'd written for them eighteen months earlier. Phishing-resistant MFA had been quoted. EDR had been quoted. A Cyber Essentials Plus (CE+, the UK government's baseline cyber-hygiene certification) renewal, which they'd lapsed the year before, had been quoted.
Each of those quotes had been pulled back at budget review, not rejected outright. The reasoning was always the same and was always reasonable. "We haven't had a problem." "The current setup seems to work." "Let's revisit in six months." Six months turned into eighteen. Then the insurance form arrived.
This isn't a client failing so much as a pattern. Security spend that protects against something that hasn't happened is some of the easiest to push out a quarter. Penetration testing, where somebody is paid to try to break in so you can find the gaps before an attacker does, gets deferred. CE+ gets deferred. MFA rollout gets deferred to "after the project". The result of deferral is the same as the result of doing it, until one specific day when somebody asks a specific question and the result is suddenly very different.
## What the insurer was really asking
The 28 questions on that form weren't 28 things the insurer wanted you to have, but 28 things the insurer would price differently based on whether you had them.
If you had MFA on everything: standard premium. If you had MFA on admin accounts but not user accounts: 30-40 per cent uplift. If you had no MFA at all: declined, or premium so high it became a refuse-in-effect.
The same shape applied to backups (offline, tested in the last 90 days, restored from successfully, three separate questions), to EDR (deployed, monitored, alerts going somewhere a human reads them), and to email filtering (filtering plus link-rewriting plus impersonation protection, treated as three layers not one).
You could pass the form on paper by being generous with your answers. We've seen brokers wave that through. The trouble is, the answers come back to you if there's a claim. "You said you had MFA on all admin accounts. The breach was via an admin account without MFA. Claim denied."
So the form isn't a procurement exercise; it's a declaration, and the prep work is making sure the declaration is one you can stand behind a year later when somebody's reading it back to you with an open laptop on the desk.
## Twelve working days
We took the twelve working days. We didn't get the client from four out of twenty-eight to twenty-eight out of twenty-eight, and we never claimed we would. We got them to thirteen on paper, though only four of the new nine were fully implemented in the window; the other five were credibly in flight with a remediation plan we'd put in writing by the time the renewal landed. We had a clear written note against the remaining fifteen explaining what was in flight, what was being deferred, and what wouldn't be done in this insurance cycle.
The broker, to her credit, took that to underwriting and got the renewal through at a 12 per cent uplift instead of the 60 per cent it would otherwise have been. Underwriters are usually happier with a partial honest answer plus a remediation plan than they are with a perfect-looking form that doesn't survive a phone call.
Three months later we landed the MFA rollout. Six months later, the EDR. Nine months later, the CE+ certification. None of it had got cheaper; the questionnaire just made it real.
## The wider lesson
The insurance form is one trigger of several. The same dynamic shows up when a customer asks for a security questionnaire as part of onboarding. When a regulator changes the rules; cyber-insurance underwriters started asking these questions in earnest from 2024-25 onwards. When a peer firm gets breached and the board gets nervous. When a new contract has a security schedule attached.
In every case the deferred-security work catches up, and the variable is whether it does so on your timetable or somebody else's.
If you're going to defer (and sometimes deferral is genuinely the right call) defer with a date in the calendar and a written reason. "Deferred to Q3 2026, accepted as low-likelihood by FD on the basis of current threat profile" is a defensible note, where "decided not to do it" is the version that hurts later.
## Where this lands with us
This is our Security Solutions practice doing the most useful version of itself: not running a pen test, not deploying a tool, just sitting on a Teams call going through an insurance form line by line and being honest about what each line means.
We do that work as a discrete engagement. A fixed-fee questionnaire review. Two days of our time, a written gap analysis, a short letter you can hand to your broker. It tends to pay for itself many times over in the insurance premium, never mind in the breach that doesn't happen.
The form arrives on a Friday with the renewal twelve days away, and the cost of getting it wrong isn't only the premium uplift; it's a denied claim if you've fluffed an answer, a fortnight of unbillable hours pulled off whatever the team was supposed to be doing this month, and a board conversation you didn't want to have about why nobody was watching the renewal calendar. None of those line up in your favour at the same time. We'd rather have the conversation now than then.
---
*Renewal coming up and the questionnaire's giving you pause? Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk). One of us will read it.*
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# When a client tells us not to test something
Practice: Security Solutions
Author: Matthew
Date: 2026-05-16
Tags: security, penetration-testing, risk, scoping
URL: https://jmo.partners/insights/client-tells-us-not-to-test/
We were two weeks out from a penetration test (where somebody is paid to try to break into a system so you can find the gaps before an attacker does) and the scope call had been going well. The client's IT lead had walked us through their estate. We'd agreed targets: the corporate identity (the system that decides who gets to log in to what), the cloud file storage, the customer-facing portal, the VPN (virtual private network, the secure tunnel staff use to log in from outside the office).
Then he said, "Can we leave the warehouse system out of scope?"
Fair question on its face. There are reasons to exclude something from a test. The system's mid-migration. There's a vendor support agreement that excludes pen testing without notice. It's an isolated network with no path to anything sensitive. We've left things out for all of those reasons.
This one wasn't one of those reasons. He'd already told us the warehouse system was old. He told us the credentials were "a bit informal", shared between four shift leads, hadn't been changed in three years. He told us the database it ran on was a Windows version that had been out of mainstream support for years. And he told us, with a small smile, that he'd rather we didn't poke at it because he didn't want what we'd find to go in the report.
## The awkward conversation
We had to say no. Not loudly (this isn't a confrontation, the IT lead was being honest with us and we appreciated it) but firmly. The whole point of a pen test is to find the things the client would rather not find. Excluding the system the client most wants you not to look at is excluding the system you most need to look at.
We spent an hour on the call talking it through. Three things ended up mattering.
**The report exists for the board, not for him.** If the warehouse system is the weakest link, the board needs to know it's the weakest link. Leaving it out so the report looks better is a disservice to the people commissioning the test.
**An attacker won't leave it out of scope.** Real adversaries don't read your statement of work. They look for the path of least resistance. If the path of least resistance is a 2019-vintage database with shared credentials, that's the path they take. A test that pretends that path doesn't exist isn't a test.
**The fix doesn't need to be in this quarter.** Finding the gap doesn't oblige anyone to fix it tomorrow, only to put it on the list with a date next to it. The conversation about budgeting the fix is a separate conversation from the test that surfaces the gap.
We agreed to include the warehouse system in scope, agreed to flag findings against it in a separate annex of the report, and agreed that the IT lead could brief the board himself on the remediation plan before they read the annex. That gave him control of the narrative without us hiding the substance.
## Why this comes up more than people think
The pure version of "don't test this because I don't want to know" is rare, but the diluted version of it is everywhere.
"Can you test the new system but not the legacy one, we know the legacy one's bad."
"Can you stay off the finance servers during this quarter, it's a busy time."
"Can you test the office but not the remote workers, the remote setup is a mess."
"Can we exclude the third-party platform, they're contractually responsible for security."
Each of those has a defensible version and an indefensible version. Some legacy systems are genuinely scheduled for decommissioning in six weeks and there's no value in testing them. Some finance windows are genuinely the wrong time for a test that might cause an outage. Some third-party platforms genuinely have their own attestation reports that cover what you'd find.
The indefensible version of each is the same shape: testing the thing would surface something the requester would rather not have on a page they have to sign. That's the version we push back on.
## The role of the tester
We're not auditors and we're not the police. The client buys the test, the client owns the scope, the client owns the report. We don't get to override that.
What we do get to do is tell the client, in writing, when we think the scope is hiding the answer the test is supposed to find. Sometimes they push back and we proceed anyway, on the narrower scope, with our concern noted. Sometimes they hear it, sleep on it, and come back saying expand the scope. Sometimes they go quiet for a week and then come back with "OK, but find a way to make the report digestible".
What we don't do is shrug, take the narrower scope, and write a report that pretends the gap isn't there.
There's a version of this work where you give the client whatever they ask for, and it's a less awkward business to run, but it's also a worse one, because eighteen months later when the warehouse system gets breached and the board reads the test report from two years ago, the report says nothing about the warehouse system. And the unanswered question becomes whether the tester didn't look, or looked and didn't say.
## Where this lands with us
This is the part of our Security Solutions practice that doesn't show up in the marketing material. We'll run the test, write the report, walk you through the findings, but we'll also have the scoping conversation honestly, and we'll tell you when we think the scope's been written to protect somebody's reputation rather than the company's posture.
That tends to make the first conversation slightly more uncomfortable and the relationship that follows more useful. The trade is one we're happy with.
## In summary
If you don't want it tested, you probably need it tested. A scope written around the embarrassing parts is a report your insurer can use against you, a board paper that misses the actual risk, and an eighteen-month head start handed to whoever finds the gap first. Run the test. Argue about the remediation timeline after.
---
*Scoping a pen test and not sure which conversations to have first? Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk). One of us will read it.*
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# The handover meeting that wasn't: what we learned about turnover risk
Practice: Managed Services
Author: Jamie
Date: 2026-05-16
Tags: managed-services, documentation, turnover, asset-management
URL: https://jmo.partners/insights/handover-meeting-that-wasnt/
The first email arrived on the Wednesday. "Just a quick one, the SSL certificate on our booking site has expired. Can you fix?" SSL is the small file that proves a website is who it says it is and turns on the padlock in the browser. We could fix it, but we hadn't been managing it, and we hadn't been told to start. The IT manager who'd been handling it had left on the Tuesday. The handover meeting we'd been promised, the one where we'd be walked through what was in his head, hadn't happened — he'd taken his last day as leave, and the calendar item had fallen off the back end of the agenda.
Over the next eight weeks we found nine more like it. Three more SSL certificates. Two domain renewals, one of which we caught with about 48 hours to spare. A backup system that hadn't been tested for fourteen months; the tests had been on his personal calendar, not the shared one. A piece of finance software whose annual licence was paid through his personal corporate card and would lapse the day his card was cancelled. The phone system maintenance contract that wasn't on any list we had.
None of this was hidden on purpose. He just hadn't documented it, or he'd documented it in a notebook nobody had thought to ask for, or he'd documented it in a OneNote that lived on a personal OneDrive that got cleared the day his identity was disabled. He was a decent IT manager; the problem wasn't him but the shape of the handover.
## The handover meeting nobody books
Turnover risk in SME IT is one of those things everyone nods about and almost nobody plans for. The IT manager (sometimes a single person, sometimes one of two) knows where the bodies are buried. They've been there for years. They've been doing things in their head, on paper, on personal calendars, in chat threads with vendors who text them directly. The shared documentation is a fraction of what they know.
When they leave, three things happen in sequence. **Week one**, the urgent things break and get noticed. SSL certificates expire. Renewals lapse. A vendor calls and asks who they're talking to now. These are the easy ones, because they announce themselves.
**Months two to six**, the things that operate on a quarterly cadence reveal themselves. Quarterly backup tests. Quarterly disaster-recovery walk-throughs. Quarterly licence reconciliations. Quarterly invoices from vendors nobody quite remembers.
**Year one to two**, the annual things bite. Annual renewals nobody put on a calendar. Annual filings. Asset refreshes that should have been planned a quarter earlier. Cyber Essentials Plus (CE+, the UK government's annual cyber-hygiene certification, audited by an external assessor) recertifications. Cyber-insurance proposals. ISO surveillance audits (the yearly check-ins on your ISO 27001 or similar certification) if you have them.
By the time the annual things are showing up, the new IT manager, or the new IT supplier, has been blamed at least three times for things they had no way of knowing about. The trust deficit is hard to climb out of.
## What we now do at takeover
After enough of these, we've changed our onboarding for any new managed-services client. The first thirty days are scoped around finding what isn't in the documentation we've been given.
We look at three places. **The renewals trail.** Every domain, every certificate, every software licence, every support contract, every maintenance contract, every cyber-insurance policy. We pull the list from the client's finance system, not from IT documentation, because the finance system catches the things IT didn't track. We then cross-reference everything we found against the IT documentation. The gap is the work.
**The shared mailboxes and forward rules.** Vendors send renewal notices to the address they have on file. Often that's a single person's address, sometimes a generic one that nobody actually monitors. We get visibility on what's hitting both, and we redirect to a shared inbox that survives any one person leaving.
**The asset register.** Real physical kit and real licences. Walked, counted, checked against the supplier's record. In years of running these handovers we find at least one device nobody knew was there, and at least one licence that's been paid for and not used for two years. The licence overpayment usually covers the cost of the audit on its own.
It's not a glamorous thirty days, but the unglamorous work that earns the right to do the more interesting work later.
## Why this is a managed-services question, not an HR one
You might reasonably ask why this is an IT supplier's problem rather than a question for the company's own HR or operations function. The honest answer is that nobody else in an SME has the visibility. HR knows the person's leaving and runs the leaver checklist: laptop returned, accounts disabled, badge collected. Operations might own the office side of it. But neither of them knows that the SSL on the booking site renews on the 11th of October, or that the printer maintenance contract auto-renews unless you cancel sixty days before the anniversary.
That kind of operational knowledge is exactly where our Managed Services practice spends its time. We treat it as a continuity layer that survives staff changes on either side, ours or theirs. Documentation that's actually current. Renewals that live in a shared system. Vendor relationships in shared inboxes, not personal ones. Asset registers that match what's on the desks.
None of which prevents the turnover. It just stops the turnover from costing twenty thousand pounds in surprise renewals and missed certifications.
## In summary
If your IT is a single point of failure, the failure isn't a question of if but of when. When it happens you'll spend the first month firefighting expired certificates, the next six months reconstructing a quarterly cadence nobody wrote down, and the year after that picking up the annual renewals you didn't know existed. Twenty thousand pounds in surprise costs is the middle of the range. The expensive end is the customer who finds your booking site offline, the insurer who declines a claim because cover lapsed, the auditor who turns up to a certification you forgot to renew. The cheapest time to fix it is before they tell you they're leaving.
---
*Worried about what you'd lose if your IT manager left tomorrow? Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk). One of us will read it.*
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# We'd rather find the rogue access point than not
Practice: Security Solutions
Author: Oliver
Date: 2026-05-16
Tags: security, wireless, network-audit, rogue-AP
URL: https://jmo.partners/insights/rogue-access-point/
We were doing a wireless audit. Routine work: we'd been engaged for a network refresh and the audit was the first day of the engagement. Walk the building with a survey app on a tablet, map signal coverage, identify dead zones, identify channel overlap, list every access point (AP, the WiFi box on the wall or ceiling) we found. Three hours of slow walking and a lot of coffee.
The map came back with thirteen APs. The client's documentation said there were eleven. We walked it again and got the same count.
The two we couldn't account for were broadcasting an SSID (the name of a WiFi network) that looked legitimate at first glance. Same naming convention as the rest of the estate. Subtle differences if you looked closely. One in a small storage room above the back office. One in the ceiling of a corridor near the loading bay.
Neither was on the client's asset register. Neither was on any switch port the client could see. They were getting power from somewhere, and they were broadcasting, and they had been doing so for at least the four months that signal data from the previous audit had been available to look at.
## Three things it might be
There are three plausible explanations for an unlabelled AP, and we'd rather work through them than guess.
**Operational drift.** A previous contractor installed it, charged for it, didn't add it to the documentation, and moved on. The client paid for it, owns it, has no record of it. We see this on probably half the audits we do. It's a documentation failure, not a security incident.
**Shadow IT.** Somebody internal got fed up of the WiFi in their corner of the building, bought an AP from a high-street retailer, plugged it in. We see this on maybe a quarter of audits. The AP is real, it's friendly, but it's also not configured to the rest of the estate's security standard, and it's probably broadcasting on a channel that's clobbering everything else.
**Actual rogue device.** Something somebody planted. Either as part of a deliberate intrusion attempt, or, more often, as part of a previous tenant or contractor's setup that was never disconnected. The frequency of this is much lower than the first two, but it isn't zero, and the cost of getting it wrong is much higher.
You can usually tell which of the three you're looking at within twenty minutes once you've got the device in your hand. The brand, the configuration, the MAC address vendor lookup (a quick check of the device's hardware ID against a public registry that tells you who made it), the way it's powered. What you can't do is tell from across the building. You have to find it, physically.
So we found them. The storage-room one was a £40 consumer router somebody on the operations team had plugged in eighteen months earlier because the meeting room next door had poor signal. He'd genuinely forgotten about it and felt a bit sheepish. We turned it off, walked it back to its owner, and moved on.
The loading-bay one was harder to track. It was in the ceiling void, not screwed to the structure, just sitting on top of a cable tray. It was being powered by a PoE injector (a device that pushes power through an Ethernet cable so you don't need a separate plug) tucked behind a ventilation duct, plugged into a wall socket on a separate ring main from the rest of the IT power. It was a small business-grade AP, not a consumer one. The serial number didn't match anything on the client's records, but it did match a batch sold to a previous IT supplier the client had used in 2021 and parted ways with in 2022 — probably forgotten, possibly not.
## What we did next
We took it down. We took it back to the office. We pulled the configuration. The SSID it was broadcasting was open, no password, and it was bridged to a VLAN (a logical network segment) that turned out to be on the main staff network, not segregated from anything. Anybody within range of the loading bay, and there's a public footpath on the other side of the wall, could have been on the staff network for the past four years.
We can't tell you whether anyone was, because we don't have the logs. The AP wasn't logging to a central system because it wasn't centrally managed.
What we can tell you is the gap that allowed this to exist for that long was the same gap we wrote up in the audit report:
- No periodic wireless survey. The last one had been at install in 2019.
- No central management of APs. Each device was managed individually, which means nothing notices when an extra one shows up.
- No segregation between public-facing zones and the staff network. One flat network across the building.
Each of those gaps is fixable. We fixed them as part of the refresh. The story has a tidy ending.
## Why we'd rather find them
The headline of this post is the punchline of the engagement. We'd rather find the rogue AP than not. Even when finding it is awkward, because somebody internal installed it, because a previous supplier left a mess, because the report becomes harder to write. Even when nobody asked us to look for it specifically.
The alternative is being the firm that did the wireless audit and didn't find it. Two years later, when the breach happens, somebody asks why the audit missed it, and the answer is "we didn't look in the ceiling void". That's a worse position for everyone: the client, us, our professional indemnity insurer, the people whose data was on that network.
This is the spirit of our Security Solutions practice. The audit isn't a piece of paper but an actual look at the actual estate, with somebody walking it with a tablet for the full day it takes, and asking the awkward questions when the map doesn't match the documentation. The paper at the end is a byproduct.
## A short note for the procurement-minded
A wireless audit that takes half a day and produces a report is cheaper than the one that takes a full day and produces the same report. It's also cheaper than the one that takes a full day and finds the rogue AP, because that one then continues into incident response and a network rebuild.
If you've never had an audit find anything, that's information. It might mean your estate is genuinely clean, or it might mean the audit didn't look very hard. We'd want to know which. Because the device sitting in your ceiling void right now, broadcasting an open SSID into the car park, isn't waiting for your next audit cycle; it's exposing your staff network today. The cost of finding out from a regulator or an insurer instead of from us is an order of magnitude higher, and it tends to arrive with a press release attached.
---
*Wondering what's on your wireless that you don't know about? Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk). One of us will read it.*
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# The audit that's never really "finished"
Practice: Consulting Services
Author: Matthew
Date: 2026-05-16
Tags: audit, consulting, governance, documentation
URL: https://jmo.partners/insights/audit-never-really-finished/
We delivered the report in March. Eighty-six pages, structured findings, a remediation plan with owners and dates. The client's operations director thanked us at the closing call, said the board would receive it the following week, and we shook hands (virtually, it was a Teams call) and the engagement closed.
Then in May, an email. "Quick one, finance found a contract during a year-end clean that wasn't in your audit. Should it have been? Does it change anything?"
In July, another. The marketing team had spun up a new SaaS tool (software-as-a-service, cloud software you pay for monthly rather than install). Was it in scope?
In October, a third. A small acquisition had completed; the acquired company's IT was going to be folded in over the next six months. Could we update the audit?
By March of the following year, twelve months after the report, about forty per cent of what we'd written was already out of date — not wrong exactly, just superseded. The estate had moved, the audit had been a snapshot, and the thing it had snapshotted had kept moving.
## Why audits look like they finish
Most audit engagements are scoped to look like discrete projects. There's a kick-off. There's a fieldwork phase. There's a draft report. There's a closing meeting. There's a final report. There's an invoice. Both sides treat it as a project with a beginning and an end, because that's how projects work and that's how budgets work and that's how audit firms train their teams.
The trouble is the underlying thing, the estate, the supplier relationships, the data flows, the controls, whatever the audit was actually looking at, doesn't have beginnings and ends. It has a continuous flow of small changes. New tools. Departed staff. New contracts. Renewed contracts. A reorganisation. A change of bank. A new piece of regulation. The shape on the day you took the snapshot is not the shape on the day you delivered the report, and it's certainly not the shape three months later.
That doesn't make audits useless. A good audit on day one is a much better starting point than no audit. But the framing matters: the report isn't the deliverable but a starting position from which you maintain a current picture. The deliverable is the maintained picture, which only exists if somebody keeps maintaining it.
## What "maintained" actually means
Most clients don't want us to repeat the full audit every year. It's expensive, it's intrusive, and a lot of the eighty-six pages don't materially change. What they want is a way of keeping the parts that change up to date without redoing the parts that don't.
We've ended up with a rhythm that works for most.
**Quarterly:** a 90-minute review call with whoever owns the audit findings on the client side. Walk the action plan. Check what's been done, what's slipped, what's been deprioritised. Update the document. Cost: small. Value: high, because it forces the action plan to be a live document rather than a PDF in a folder.
**Annually:** a half-day refresh. We don't redo fieldwork. We ask three questions: what's changed since last year that wasn't in the report? what's still in the report but no longer accurate? what's still in the report but no longer relevant? We update the report, mark the changes, and reissue. Cost: maybe one to three days of our time. Value: a report that's still defensible to the board.
**Every three to five years:** a full re-audit. Fresh fieldwork, fresh scope, fresh perspective. We tend to bring in a different lead on our side for these, because familiarity with the previous report makes you blind to things you wrote three years ago and stopped noticing.
That rhythm doesn't suit every engagement, but the principle generalises. Some maintenance is much cheaper than redoing the whole, and much more valuable than letting it rot.
## What changes between audits
The things that change most between audits, across years of running them:
- **The supplier landscape.** Renewals, new contracts, retired contracts. Every audit has a supplier list; every supplier list is out of date within a quarter.
- **The shadow IT.** Tools spun up by individual teams without coming through IT. Sometimes useful. Sometimes a data-protection grenade. Always present.
- **The staff topology.** People joining and leaving change who has access to what, who owns what process, who maintains which document. The audit's RACI chart (the grid that maps who's responsible, accountable, consulted and informed for each task) is the first thing to go stale.
- **The regulatory ground.** ICO guidance shifts. FCA, SRA, CQC, whichever applies, issues something. A new piece of EU or UK legislation hits. The control framework you built on stops being quite the same framework.
The things that change less:
- **The estate of physical kit.** Three-to-five-year refresh cycles mean the hardware moves slowly.
- **The core network topology.** Once built, slow to change.
- **The high-level governance structure.** Boards and committees move slowly.
Knowing which is which lets you build a maintenance schedule that's proportionate. Frequent and light on the fast-moving stuff, occasional and deep on the slow.
## Where this lands with us
This is something our Consulting Services practice spends a lot of time on. Not the headline audit, we do those, but the ongoing work that keeps the audit honest after the report has been signed off. The quarterly review call, the annual refresh, the periodic reality-check.
It's not the most glamorous work, and it's not the most expensive, but it's the work that makes the audit actually pay back what it cost, because an audit you don't maintain is a sunk cost; an audit you do maintain is a working document.
## A short close
If your last audit was sitting on the shelf for a year and you can't remember the last time you opened it, the cost is already accruing. The next bad surprise, a failed Cyber Essentials renewal, a board question you can't answer, a regulator's letter asking about a control you no longer have evidence for, lands at the worst possible moment, and the gap between what the report says and what's actually true gets harder to close every quarter. Audits aren't projects but starting positions, and the work is keeping the position current, the longer that work goes undone, the more it costs to catch back up.
---
*Got an audit report on the shelf that's gone a bit dusty? Drop us a note at [info@jmopartners.co.uk](mailto:info@jmopartners.co.uk). One of us will read it.*
**JMO|Partners** · Enterprise IT, sized for SMEs.
---
# Managed Services
Source: https://jmo.partners/services/managed-services/
Managed IT Services for SMEs · London · JMO|Partners
Services
About
Insights
Resources
Get in touch
→
01
Services
02
About
03
Insights
04
Resources
Get in touch
→
SERVICES · 01 / MANAGED SERVICES
The day-to-day IT that your team should be able to take for
granted
.
One contract, one number, one team running the helpdesk, the network, the backups, and the vendor calls. For SMEs from 1 to 250 staff across Greater London and the home counties.
Managed Services is the practice that takes the day-to-day IT operations of an SME and runs it as one estate from a single point of accountability. Most SME IT setups are stitched together from three or four legacy contracts, a couple of suppliers who never quite handed over, and one person internally who knows where the bodies are buried. We take the whole thing over, document what's actually there, and operate it under one team.
For a one-person startup, that means the helpdesk you didn't have. For a 250-person operation, it means the layered ops function you'd otherwise need three full-time engineers to staff. Same team either way, scoped to what's actually needed.
What's included
We deliver these as a managed service, individually or as a bundle. Each item is delivered to the same standard regardless of which tier you're on:
Core operations
IT Support & Helpdesk
Network Management (UniFi specialism)
Server Management
Patch Management
Remote Monitoring & Management (RMM)
Mobile Device Management (MDM)
Data Backup
Vendor Management
Cloud & communications
Managed Email (Microsoft 365, Google Workspace)
M365 Tenancy Administration
Google Workspace Tenancy Administration
VOIP & Unified Communications
Cloud Services (M365, GWS, AWS)
Identity & Access Management (IAM)
Hardware & infrastructure
Hardware & Software Procurement
Custom PC Building
Structured Cabling (Cat6 / Cat6a / fibre)
IoT Management
People
Onboarding & Offboarding workflows
Training & Education
How we work
A four-step cadence, the same shape regardless of whether you're a 5-person startup or a 200-person established business:
Discovery (week 1).
We walk the estate, read every contract, map every licence and account, and produce a written health-check.
Stabilise (weeks 2–6).
We fix what's actually broken, document everything, and bring the estate up to a known-good baseline.
Operate (ongoing).
Helpdesk, monitoring, patching, vendor calls and procurement run on a monthly cadence. You get one number to ring.
Review (quarterly).
A formal QBR with what's changed, what's coming, what the roadmap says, sized to the business, not the supplier.
Who it's for
Managed Services typically lands well with:
SMEs from 1 to 250 staff across Greater London and the home counties
Businesses inheriting a tangle of legacy IT contracts and wanting one team to take it on
Teams with no internal IT, where the office manager has been holding it together until now
Established SMEs whose one-person IT manager has just resigned and the renewals are now invisible
Founder-led businesses tired of explaining their setup to a different engineer each call
Outcomes
What clients typically see in the first ninety days of a Managed Services engagement:
A documented estate. Everything that ought to be written down, is.
Predictable monthly cost. No more reactive call-out invoices.
Faster fixes. Tickets resolved by people who already know your setup.
A roadmap. A clear view of what to invest in, what to retire, and when.
From £250 per month for Essentials, £500 for Plus, £1,000 for Premium. One-off onboarding from £1,500.
See the pricing page
for what's in each tier.
Common questions
Do you cover Apple, Windows, and mixed estates?
Yes. We support UniFi, Apple, Microsoft and Google as primary stacks, and the full range of Windows hardware. Mixed estates are normal, most SMEs run one of those for productivity and a different one for engineering or design.
What size team is too small?
None. We run estates from one founder upwards. A one-person business with a single laptop and a Google Workspace account still benefits from helpdesk, MDM and backup being someone else's problem.
What size is too big?
Around 250 staff. Beyond that, the maths usually says hire in-house and keep us for the advisory layer.
Are you tied to a single vendor?
No. We have a preferred stack (UniFi for networking, Microsoft 365 or Google Workspace for productivity, named EDR and backup vendors) because we know them deeply, but we hold no exclusivity. If the right answer for your business is something else, we say so.
Who actually answers the phone?
For anything strategic or escalated, one of the three founders. For day-to-day support, the engineer assigned to your account. There's no switchboard.
More questions? See the
full FAQ
.
Related field notes
Long-form posts from the team on Managed Services topics:
Two years of UniFi rollouts: what we'd keep and what we'd swap
Cloud-first AD: where SME estates are actually landing in 2026
The four kinds of IT debt every SME carries
From four supplier contracts to one: a unified-internet story
The handover meeting that wasn't: what we learned about turnover risk
Ready to make IT the boring background it should be?
Drop us a note below, or email
info@jmopartners.co.uk
. One of the founders will read it.
Name
*
Company
Email
*
A few lines about your business and what you're looking for
*
Send enquiry
→
Thanks. We got it.
One of the founders will be in touch shortly. If it's urgent,
drop us a line directly
.
Explore the other practices
SERVICES
AI Enablement
Practical rollouts of Google Gemini, Anthropic Claude, OpenAI ChatGPT and Microsoft Copilot into how your business actually works, with the security and policy backing to do it properly.
02 / AI Enablement
SERVICES
Security Solutions
Cyber and physical security tailored for SMEs, delivered by an experienced information security consultant, aligned to the questionnaires your insurer is now sending.
03 / Security Solutions
SERVICES
Consulting Services
Independent IT consulting for SMEs. Audits, strategy, migrations and projects, scoped to fit the business, not the supplier.
04 / Consulting Services
IT solutions tailored for small and medium-sized businesses.
Services
Managed Services
AI Enablement
Security Solutions
Consulting Services
Company
About
Insights
Resources
Pricing
FAQ
Contact
Get in touch
info@jmopartners.co.uk
LinkedIn
X (Twitter)
Instagram
EST 2024 · LONDON
© 2026 JMO Partners Ltd · Company No.
15592258
Enterprise IT, sized for SMEs.
# AI Enablement
Source: https://jmo.partners/services/ai-enablement/
AI Enablement for SMEs · Gemini, Claude, ChatGPT & Copilot · JMO|Partners
Services
About
Insights
Resources
Get in touch
→
01
Services
02
About
03
Insights
04
Resources
Get in touch
→
SERVICES · 02 / AI ENABLEMENT
AI that
earns
its keep, not just its headlines.
Practical rollouts of Google Gemini, Anthropic Claude, OpenAI ChatGPT and Microsoft Copilot into how your business actually works, with the security and policy backing to do it properly.
AI Enablement is the practice that takes practical AI rollouts and lands them inside the SME workflows where they actually save time. A year into AI showing up in every SME conversation, the pattern of what's paying back is clearer than the marketing suggests. Most SMEs don't need a strategy deck. They need a small set of workflows where AI saves real hours, a clear policy on what staff can and can't do with it, and someone to configure the tools so the answer isn't "figure it out yourself".
We deploy Google Gemini, Anthropic Claude, OpenAI ChatGPT and Microsoft Copilot inside the productivity suite you already pay for, build the workflows that match how your business runs, and train the team so the tools get used.
What's included
Engagements are scoped per estate. The core building blocks:
Strategy & policy
AI readiness assessment
Acceptable-use policy aligned to your sector
Data classification and what's safe to put into a model
Information security review of any third-party tooling
Rollout
Google Gemini for Workspace deployment
Anthropic Claude Team deployment
ChatGPT (OpenAI enterprise plans) deployment
Microsoft Copilot deployment (Microsoft 365 and GitHub)
Custom workflows (drafting, summarisation, knowledge retrieval, meeting notes, document review)
Integration with the systems you already use (CRM, helpdesk, finance)
People & governance
Hands-on training tailored to each team
Prompt libraries built for your business
Office-hours support during the rollout window
Audit logging, access controls, cost monitoring
Review cadence at 30, 60 and 90 days
How we work
A four-step cadence over six weeks:
Audit (week 1).
We sit with each team, watch how they actually work, and identify three to five workflows where AI would save real time, not write a strategy deck.
Deploy (weeks 2–4).
We turn on the right tooling, configure it, and build the workflows. Information security backing throughout.
Train (weeks 4–6).
We sit with the team and run the workflows together, not a two-hour seminar, working alongside them until it sticks.
Review (90 days).
We measure what actually changed, what didn't, and tune the rollout.
Who it's for
SMEs already paying for Google Workspace or Microsoft 365 who want to use the AI features properly rather than ignore them
Founders who've been told they "need an AI strategy" and want a practical one instead
Operations leaders looking for a documented, defensible policy before staff start pasting client data into ChatGPT
Teams that have tried AI individually and want a coordinated approach
Outcomes
A small set of workflows where AI is provably saving hours per week
A written, signed-off acceptable-use policy
Staff who know what they can use AI for and what they can't
Confidence that the rollout will pass an audit, a renewal questionnaire or a client due-diligence ask
Assessment & policy from £7,500. Rollout projects from £15,000.
See the pricing page
for the indicative bandings.
Common questions
Will my data train a public model?
Not under the deployments we use. Google Gemini for Workspace, Anthropic Claude Team, OpenAI's enterprise ChatGPT plans and Microsoft Copilot all include enterprise data-handling commitments. We configure the deployment so this is contractually clear, not just assumed.
We tried Copilot and it didn't stick. What's different?
Usually the rollout, not the tool. AI features land best when someone has sat with each team and built the specific workflows that match how they work. Switching tools without changing that pattern produces the same outcome.
How does this fit with our cyber-insurance posture?
Insurers are starting to ask about AI use in renewal questionnaires. The policy and information security backing we produce is written to answer that question without surprises.
Do you build custom models?
We deploy the models the major vendors already provide, with workflows built around them. Custom-trained models are a different kind of project and rarely the right answer for an SME, we'll tell you when they are.
How quickly does an AI rollout pay for itself?
On the workflows where it sticks, usually within the first quarter. We measure this at 90 days so it's not a guess.
More questions? See the
full FAQ
.
Related field notes
AI tooling for SMEs: where it's earning its keep, where it isn't
What Mythos changes, and what it doesn't
SME supply chain attacks after TanStack
Want AI you can actually point at and measure?
Drop us a note below, or email
info@jmopartners.co.uk
. One of the founders will read it.
Name
*
Company
Email
*
A few lines about your business and what you're looking for
*
Send enquiry
→
Thanks. We got it.
One of the founders will be in touch shortly. If it's urgent,
drop us a line directly
.
Explore the other practices
SERVICES
Managed Services
The day-to-day IT operations practice: helpdesk, networks, identity, backup, vendor management. For SMEs from 1 to 250 staff.
01 / Managed Services
SERVICES
Security Solutions
Cyber and physical security tailored for SMEs, delivered by an experienced information security consultant.
03 / Security Solutions
SERVICES
Consulting Services
Independent IT consulting for SMEs. Audits, strategy, migrations and projects, scoped to fit the business.
04 / Consulting Services
IT solutions tailored for small and medium-sized businesses.
Services
Managed Services
AI Enablement
Security Solutions
Consulting Services
Company
About
Insights
Resources
Pricing
FAQ
Contact
Get in touch
info@jmopartners.co.uk
LinkedIn
X (Twitter)
Instagram
EST 2024 · LONDON
© 2026 JMO Partners Ltd · Company No.
15592258
Enterprise IT, sized for SMEs.
# Security Solutions
Source: https://jmo.partners/services/security-solutions/
Cyber Security for SMEs · CE+, EDR, CCTV, Cyber-Insurance · JMO|Partners
Services
About
Insights
Resources
Get in touch
→
01
Services
02
About
03
Insights
04
Resources
Get in touch
→
SERVICES · 03 / SECURITY SOLUTIONS
Security that
holds
up under audit, insurance renewal, and the day someone clicks the link.
Cyber and physical security tailored for SMEs, delivered by an experienced information security consultant, and aligned to the questionnaires your insurer is now sending.
Security Solutions is the practice that builds the controls that audits, insurance renewals, and client due-diligence packs ask about, in the order that matches the threats SMEs actually face. The cyber-insurance questionnaire used to be a formality. It isn't any more, and the next round of changes is already visible. The same goes for Cyber Essentials Plus assessments and the due-diligence packs your clients are starting to send through.
We do identity-first protection because identity is where most SME breaches start, layered EDR because endpoints are where most ransomware lands, and physical security where the office and the IT estate intersect.
What's included
Cyber security
Cyber Essentials & Cyber Essentials Plus readiness
Identity protection and MFA (Microsoft Entra, Google Workspace)
Endpoint Detection & Response (EDR) and XDR
Email security (anti-phishing, DMARC, DKIM, SPF)
Patch management and vulnerability scanning
Backup integrity testing
Penetration testing (external, internal, web application)
Phishing simulation & security awareness training
Dark web & brand monitoring
DNS / web filtering
Cyber-insurance questionnaire preparation
Information security & compliance
Data classification and handling
User access controls and permissions reviews
Acceptable-use and BYOD policies
Information security audits
GDPR / Data Protection audits
ISO 27001 readiness
Physical security & incident readiness
CCTV systems specification, install, maintenance
Access control and visitor management
Integration of physical security into IT estate
Incident response runbooks
Tabletop exercises
Post-incident reviews
How we work
Baseline (week 1).
Where is the estate against Cyber Essentials Plus, against your insurer's questionnaire, against a basic NCSC SME checklist? We produce a written gap report.
Prioritise (week 1–2).
Highest-impact gaps first. We rank by risk reduction per pound spent, not by what the supplier wants to sell you.
Remediate (weeks 2–8).
We close the gaps in order, with clear evidence of what was done and when, so the audit trail is ready when the questionnaire arrives.
Maintain (ongoing).
Patching, monitoring, identity reviews, EDR triage and quarterly audit refresh.
Who it's for
SMEs preparing for a Cyber Essentials Plus assessment for the first time or recertifying
Businesses whose cyber-insurance questionnaire just arrived and looks longer than last year's
Clients of professional service firms (legal, financial, healthcare) whose due-diligence pack now includes 28 questions about security posture
Offices that need physical and digital security to work as one system rather than two contracts
Outcomes
A defensible posture against Cyber Essentials Plus and the common insurance questionnaires
Evidence ready when the audit, renewal or client due-diligence arrives
Identity and endpoint controls that are actually configured, not just licensed
A physical security estate that's documented and tied into the IT systems
Cyber Essentials Plus Readiness from £1,500. Comprehensive Security Audit from £3,500. Managed Security Services from £150 PUPM.
See the pricing page
for the full picture.
Common questions
Do we need Cyber Essentials Plus?
If you handle client data, sell into the public sector, hold sensitive records, or carry cyber-insurance, then increasingly yes. We can tell you quickly whether it's needed or whether basic Cyber Essentials covers your position.
Our insurer just sent a 28-question form. Can you help with that?
Yes. This is one of the things we do most often. We map each question to the underlying control, evidence what's already in place, and close any gaps before the renewal date.
Do you install CCTV?
Yes. We specify, install and maintain CCTV and access control systems, and we tie them into the IT estate so video review, alerts and incident correlation actually work. Physical security as part of the same practice because the office and the data are the same estate.
How is this different from any other MSP's security add-on?
The work is led by an experienced information security consultant, not delegated to a generalist engineer. The controls are sequenced by risk reduction per pound, not by what's easiest to bolt on.
Does EDR replace antivirus?
For most SMEs we'd recommend, yes, and licensing is usually similar or lower. The behaviour is different and the threat coverage is materially better.
More questions? See the
full FAQ
.
Related field notes
Cyber-insurance underwriting in 2026: what changed and what's coming next
Cyber Essentials Plus renewal: the prep-window calendar
Email security in 2026: the four layers and where SMEs trip
XDR rollout for a 50-seat SME: what changed and what didn't
The cyber-insurance questionnaire that caught everyone by surprise
Audit, renewal or due-diligence on the horizon?
Drop us a note below, or email
info@jmopartners.co.uk
. One of the founders will read it.
Name
*
Company
Email
*
A few lines about your business and what you're looking for
*
Send enquiry
→
Thanks. We got it.
One of the founders will be in touch shortly. If it's urgent,
drop us a line directly
.
Explore the other practices
SERVICES
Managed Services
The day-to-day IT operations practice: helpdesk, networks, identity, backup, vendor management.
01 / Managed Services
SERVICES
AI Enablement
Practical rollouts of Google Gemini, Anthropic Claude, OpenAI ChatGPT and Microsoft Copilot into how your business actually works.
02 / AI Enablement
SERVICES
Consulting Services
Independent IT consulting for SMEs. Audits, strategy, migrations and projects.
04 / Consulting Services
IT solutions tailored for small and medium-sized businesses.
Services
Managed Services
AI Enablement
Security Solutions
Consulting Services
Company
About
Insights
Resources
Pricing
FAQ
Contact
Get in touch
info@jmopartners.co.uk
LinkedIn
X (Twitter)
Instagram
EST 2024 · LONDON
© 2026 JMO Partners Ltd · Company No.
15592258
Enterprise IT, sized for SMEs.
# Consulting Services
Source: https://jmo.partners/services/consulting-services/
IT Consulting for SMEs · Strategy, Audits, Cloud Migration · JMO|Partners
Services
About
Insights
Resources
Get in touch
→
01
Services
02
About
03
Insights
04
Resources
Get in touch
→
SERVICES · 04 / CONSULTING SERVICES
The IT decisions you only make every few years — made
properly
.
Independent IT consulting for SMEs. Audits, strategy, migrations and projects, scoped to fit the business, not the supplier.
Consulting Services is the practice that brings the experience of running across eighteen industries to the IT decisions an SME makes only every few years. A cloud migration. An office move. A core systems change. A merger. A first ever IT strategy. Each of these projects looks one-off from inside the business but fits a well-worn pattern from outside it.
We sit on your side of the table, do the work that produces a written and costed plan, and either deliver the project or hand it back to you in a state your incumbent supplier can execute.
What's included
Strategy & planning
IT Strategy & Planning
Board IT reviews and quarterly cadences
Contract calendars and renewals planning
Hardware refresh planning
Vendor selection and consolidation
Audits & due diligence
One-off IT Health Check
Infrastructure audits
Information security audits
M&A IT due diligence
Cyber-insurance pre-renewal review
Cyber Essentials gap analysis
Projects & build
Cloud migration (M365, GWS, AWS)
Office moves and fit-outs
Network rebuilds (incl. UniFi)
Wi-Fi Site Survey & Design
Tenancy migrations
Virtualisation
Project Management for complex IT change
Website Design (brochure to lead-gen funnel)
How we work
Brief (week 1).
Single meeting per stakeholder. We walk away with a written brief and the list of things nobody quite agrees on yet.
Audit (weeks 1–3).
We read every contract, walk the estate, and produce findings. Findings are written for the board, not for IT.
Plan (week 3–4).
A costed plan with two or three scenarios, the trade-offs spelled out, and a clear recommendation.
Deliver or hand off (ongoing).
Either we run the project, or we hand it to your incumbent supplier in a state they can execute. Your choice.
Who it's for
SME founders or boards making a one-off IT decision and wanting an independent view before signing a supplier
Businesses that already have an MSP but want a second opinion on a major project
Companies in the middle of a tenancy migration, an office move, or a systems change where the existing supplier is out of depth
Acquirers needing IT due diligence on a target SME
Outcomes
A written plan you can take to the board
A clear view of the cost, the risk, and the time
Two or three sensible options, not one supplier's preferred one
Either a delivered project or a project your incumbent can deliver
Strategy Workshop from £2,750. IT Roadmap Development from £10,000. On-demand consulting from £175 per hour. Monthly retainers from £1,500.
See the pricing page
for the full picture.
Common questions
Will you compete with our existing MSP?
Not unless you ask us to. The consulting practice is independent by design and frequently works alongside an incumbent. If the right outcome is to keep the incumbent and tune the engagement, that's what we'll recommend.
How long does a strategy engagement take?
Typically four to six weeks for the initial audit and plan. Longer if it turns into a delivered project.
Do you build websites?
Yes. Modern, responsive sites, brochure or lead-generating, built quickly with AI-assisted craft and ready to update yourselves. Usually launched in days, not months.
Can you help with an office move?
Often. The IT side of an office move is one of the most common projects we run: network, cabling, telephony, AV, physical security and access control, sequenced so the move happens on time.
What does a board IT review look like?
A quarterly cadence with the leadership team. We bring the data, the roadmap and the cost view. You bring the business context. Output is a single page the board signs off on.
More questions? See the
full FAQ
.
Related field notes
Tenancy migration: the unknowns that surfaced in week three
Three projects we should have split into six
Why we end up rebuilding networks we didn't design
The audit that's never really "finished"
When the wrong people write the spec: a story from a CCTV install
Got an IT decision coming up that you only make every few years?
Drop us a note below, or email
info@jmopartners.co.uk
. One of the founders will read it.
Name
*
Company
Email
*
A few lines about your business and what you're looking for
*
Send enquiry
→
Thanks. We got it.
One of the founders will be in touch shortly. If it's urgent,
drop us a line directly
.
Explore the other practices
SERVICES
Managed Services
The day-to-day IT operations practice: helpdesk, networks, identity, backup, vendor management.
01 / Managed Services
SERVICES
AI Enablement
Practical rollouts of Google Gemini, Anthropic Claude, OpenAI ChatGPT and Microsoft Copilot into how your business actually works.
02 / AI Enablement
SERVICES
Security Solutions
Cyber and physical security tailored for SMEs, delivered by an experienced information security consultant.
03 / Security Solutions
IT solutions tailored for small and medium-sized businesses.
Services
Managed Services
AI Enablement
Security Solutions
Consulting Services
Company
About
Insights
Resources
Pricing
FAQ
Contact
Get in touch
info@jmopartners.co.uk
LinkedIn
X (Twitter)
Instagram
EST 2024 · LONDON
© 2026 JMO Partners Ltd · Company No.
15592258
Enterprise IT, sized for SMEs.
# FAQ — frequently asked questions
Source: https://jmo.partners/faq/
FAQ · JMO|Partners — Managed IT, AI, Cyber Security & Consulting for SMEs
Services
About
Insights
Resources
Get in touch
→
01
Services
02
About
03
Insights
04
Resources
Get in touch
→
FAQ
The questions SMEs ask before signing with an IT
partner
.
The questions below are the ones we get asked most often before a first engagement. If yours isn't here,
get in touch
— one of the three founders will take the call.
About JMO|Partners
Who is JMO|Partners?
JMO|Partners is a South London IT consultancy serving SMEs across Greater London and the home counties. We deliver four practices: Managed Services, AI Enablement, Security Solutions and Consulting Services. Founded in 2024 (Companies House
15592258
) by three friends with experience across eighteen industries.
Why "Speak to a founder, not a switchboard"?
The three founders, Oliver, Matthew and Jamie, are the senior practitioners. For anything strategic or escalated, you get one of them on the phone directly. For day-to-day support, you get the engineer assigned to your account. There's no call-centre layer between you and the people doing the work.
How long have you been operating?
JMO|Partners was incorporated in 2024. The founders bring eighteen industries' worth of experience between them, including financial services, fintech, healthcare, hospitality, manufacturing, pharmaceuticals and professional services.
Practices
What's the difference between your four practices?
Managed Services
runs the day-to-day IT: helpdesk, networks, identity, backup, vendor management.
AI Enablement
rolls Google Gemini, Anthropic Claude, OpenAI ChatGPT and Microsoft Copilot into how your business actually works, with the security and policy backing.
Security Solutions
is cyber and physical security led by an experienced information security consultant: CE+ readiness, EDR, CCTV, access control.
Consulting Services
is the one-off advisory and project work: audits, IT strategy, cloud migration, office moves, website design.
Most engagements start with one and expand.
Can we engage you for just one practice?
Yes. Most do start that way. Managed Services is the most common entry point, but plenty of clients first engage us for a specific Security audit, AI rollout or Consulting project, and add other practices later as trust builds.
Do you partner with a specific vendor stack?
We have a preferred stack (UniFi for networking, Microsoft 365 or Google Workspace for productivity, named vendors for EDR and backup) because we know them deeply. We hold no exclusivity. If the right answer for your business is something different, we say so.
Coverage and sizing
What sizes of business do you work with?
SMEs from 1 to 250 staff. A one-person founder running on a single laptop and Google Workspace benefits from us as much as a 250-person operation needing a layered ops function. We scope to fit either.
Where are you based and where do you cover?
Based in South London. We cover Greater London (E, EC, N, NW, SE, SW, W, WC), the commute belt (BR, CR, DA, EN, HA, IG, KT, RM, SM, TW, UB, WD), and home counties (AL, BN, CB, CM, CO, CT, GU, HP, LU, ME, MK, OX, RG, RH, SG, SL, TN). Exceptions outside this footprint are possible, so get in touch and we'll talk.
Do you take on residential clients?
Yes, but it's job-dependent. We run a small amount of residential and high-net-worth individual work alongside the SME book: smart home, CCTV, network setup, ongoing support. If your project fits, we'll quote.
Pricing and contracts
How do you charge?
Managed Services:
a base monthly fee plus per-device pricing, structured around three tiers (Essentials, Plus, Premium), with a one-off onboarding fee at the start of each engagement. See the
pricing page
for the bandings.
Consulting Services:
fixed-fee for defined scopes (strategy workshop, audit, roadmap) or hourly for advisory.
AI Enablement and Security Solutions:
project-based for rollouts and audits, then a managed component for ongoing operation if you want it.
Quotes are bespoke and follow a short discovery call.
Do you publish pricing?
Indicative bandings yes, detailed quotes no — every estate is different. You'll find the tier structure and starting points on the
pricing page
.
Do you charge an onboarding fee?
Yes. Onboarding covers the work we do before the monthly service starts: estate discovery, contract and licence audit, documentation, the patch and monitoring baseline, and operational handover. It's a one-off cost: from £1,500 for Essentials, from £3,000 for Plus, from £5,000 for Premium. We sometimes waive part of it for clients who sign a longer contract or commit to a broader scope of work.
What's the minimum contract length?
Twelve months is the standard for managed services across the UK SME market, and that's what we do for Managed Services engagements. Project work and consulting engagements are scoped per project, not on a minimum term.
How much notice do I need to give to leave?
Thirty days. That's at the SME-friendly end of the UK market — many providers ask for sixty or ninety. We keep it short because we don't think contractual friction is the right reason for a client to stay.
What happens if we want to leave?
Clean handover. We document everything you'd need to give an incoming provider, return any client-owned credentials and data, and stay available for handover questions for thirty days. No friction, no hostage-tactics.
Day-to-day
Who actually answers the phone?
For anything strategic, escalated, or new, one of the three founders. For day-to-day support tickets, the engineer assigned to your account, who already knows your setup. There is no call-centre or switchboard layer.
What are your support hours?
Standard support runs 8am to 6pm, Monday to Friday, for all clients, with P1 (critical) issues getting extended cover outside those hours.
Hours can be adjusted per contract.
Hospitality, retail and any business that runs evenings or weekends as standard can scope always-on or weekend cover into the engagement.
Do I get a dedicated account manager?
Yes, every client does, regardless of tier. The named account manager is who you talk to between QBRs, who knows your roadmap, and who escalates internally on your behalf. Premium clients get priority access to their account manager; Plus and Essentials clients get standard access.
What's the SLA for response and resolution?
Critical (P1):
response within one hour
High (P2):
response within four hours
Normal (P3):
response within eight hours
We target 99.9% uptime on managed services. Full SLA terms are in the MSA template.
Do you sub-contract or use offshore support?
No. All support is delivered in-house by UK-based staff. Specialist sub-contractors are sometimes used for physical work (cabling installs, CCTV installs at scale): always UK-based, always known to us, always disclosed in the SOW.
Transitions
How does onboarding work?
A four-step pattern, regardless of size:
Discovery (week 1).
We walk the estate, read every contract, map every licence and account.
Stabilise (weeks 2-6).
We fix what's actually broken and bring the estate to a known-good baseline.
Operate (ongoing).
Helpdesk, monitoring, patching, vendor calls and procurement on a monthly cadence.
Review (quarterly).
A formal QBR with what's changed, what's coming, and what the roadmap says.
Can you take over from our current MSP?
Yes, it's one of the most common engagement shapes we see. We've documented the handover process and can run it with or without the cooperation of the outgoing provider. Either way, you keep operating through the transition.
What if you find things our current provider hasn't documented?
We document them and tell you what we found. The first month of an engagement nearly always surfaces undocumented decisions, unlabelled hardware, expired contracts, or licences nobody is sure who owns. We log it all and walk you through it.
Question not answered?
Drop us a note below, or email
info@jmopartners.co.uk
. One of the founders will read it.
Name
*
Company
Email
*
Your question
*
Send enquiry
→
Thanks. We got it.
One of the founders will be in touch shortly. If it's urgent,
drop us a line directly
.
IT solutions tailored for small and medium-sized businesses.
Services
Managed Services
AI Enablement
Security Solutions
Consulting Services
Company
About
Insights
Resources
Pricing
FAQ
Contact
Get in touch
info@jmopartners.co.uk
LinkedIn
X (Twitter)
Instagram
EST 2024 · LONDON
© 2026 JMO Partners Ltd · Company No.
15592258
Enterprise IT, sized for SMEs.
# Pricing
Source: https://jmo.partners/pricing/
Pricing · JMO|Partners — Managed IT, AI, Cyber Security & Consulting
Services
About
Insights
Resources
Get in touch
→
01
Services
02
About
03
Insights
04
Resources
Get in touch
→
PRICING
Pricing that fits the team you
actually
have, not the one the supplier wants you to grow into.
Starting figures for each of the four practices. Detailed quotes follow a discovery call.
Managed Services
A base monthly fee plus per-device pricing, structured around three tiers. Every tier includes a dedicated account manager, standard 8am–6pm Mon-Fri support with P1 extended cover, and hours adjustable per contract where the business needs evening or weekend cover.
Essentials
Essentials
From
£250
/ month
One-off onboarding from £1,500
For small SMEs needing reliable IT support without the bells and whistles. Best when the estate is under ten devices.
Up to 10 endpoint devices, 1 meeting room
Additional devices at £15 each per month
Dedicated account manager
Support hours 8am–6pm Mon-Fri, P1 extended cover
Basic proactive monitoring
Weekly reports, critical patches
Typical: 13-device estate · £295 / month (plus from £1,500 onboarding)
Get a tailored quote
→
Plus · Most common
Plus
From
£500
/ month
One-off onboarding from £3,000
For growing SMEs who want more frequent on-site support, advanced monitoring and quarterly reviews. The most common starting point.
Up to 20 endpoint devices, 3 meeting rooms
Additional devices at £15 each per month
Dedicated account manager
One free on-site visit each month
Quarterly system reviews and custom reports
Advanced proactive monitoring
Support hours 8am–6pm Mon-Fri, P1 extended cover
Typical: 25-device estate · £575 / month (plus from £3,000 onboarding)
Get a tailored quote
→
Premium
Premium
From
£1,000
/ month
One-off onboarding from £5,000
For established SMEs running multiple offices or hybrid setups. Priority access to your account manager, more frequent on-site support, and the lowest per-device rate.
Up to 40 endpoint devices, 5 meeting rooms
Additional devices at £12 each per month (lowest rate)
Dedicated account manager (priority access)
Five free on-site visits each month
Monthly custom reports
Comprehensive proactive monitoring
Support hours 8am–6pm Mon-Fri, P1 extended cover
Typical: 45-device estate · £1,060 / month (plus from £5,000 onboarding)
Get a tailored quote
→
Full
Managed Services page
has the breakdown of what's included across the day-to-day, cloud, hardware and people layers.
Other practices
Indicative starting figures. Each engagement is scoped to fit.
AI Enablement
Assessment & policy from
£7,500
Rollout projects from
£15,000
Strategy workshop from
£3,500
Practical AI rollouts using Google Gemini, Anthropic Claude, OpenAI ChatGPT and Microsoft Copilot. Workflow build, training, governance.
See AI Enablement →
Security Solutions
CE+ Readiness from
£1,500
Comprehensive Security Audit from
£3,500
Managed Security Services from
£150 PUPM
Pen testing from
£3,500
Cyber and physical security led by an experienced information security consultant. CE+, EDR, CCTV, access control.
See Security Solutions →
Consulting Services
Strategy Workshop from
£2,750
IT Roadmap Development from
£10,000
Hourly from
£175 / hr
Monthly retainer from
£1,500
Independent IT consulting for SMEs. Audits, strategy, migrations, office moves, website design.
See Consulting Services →
Things to know
All prices subject to VAT
Onboarding:
every new Managed Services engagement carries a one-off onboarding fee covering estate discovery, documentation and operational handover. From £1,500 (Essentials), £3,000 (Plus), £5,000 (Premium). Final figure scoped during the discovery call.
Greater London travel included; outside Greater London on a case-by-case basis
30 days' notice to terminate (SME-friendly end of UK MSP norm)
Standard 12-month minimum on Managed Services
Support hours adjustable per contract: weekend or evening cover available where the business needs it
Volume discounts available for larger engagements or longer-term contracts
Ready to get a tailored quote?
Drop us a note below, or email
info@jmopartners.co.uk
. One of the founders will read it.
Name
*
Company
Email
*
Team size, current setup, what you're looking for
*
Send enquiry
→
Thanks. We got it.
One of the founders will be in touch shortly. If it's urgent,
drop us a line directly
.
IT solutions tailored for small and medium-sized businesses.
Services
Managed Services
AI Enablement
Security Solutions
Consulting Services
Company
About
Insights
Resources
Pricing
FAQ
Contact
Get in touch
info@jmopartners.co.uk
LinkedIn
X (Twitter)
Instagram
EST 2024 · LONDON
© 2026 JMO Partners Ltd · Company No.
15592258
Enterprise IT, sized for SMEs.
# Gemini, Claude, ChatGPT, Copilot: where each earns its seat cost in an SME
By Matthew, Founder. Published 2026-05-26.
Twice a week somebody asks us which AI product to buy. The honest answer is not the answer either of us wants to give, which is: it depends on the stack you already run and the work the team actually does. Four products genuinely compete for SME budget in 2026, Google Gemini, Anthropic Claude, OpenAI ChatGPT and Microsoft Copilot, and each one has a place where it earns its seat cost cleanly and other places where it is the wrong answer. We thought it was worth writing down how we think about it before the next call.
This is not a benchmark piece, and it is not about model quality. Models change quarterly. What does not change is the shape of an SME stack, the tools the team uses every day, and the workflows where AI is actually doing useful work rather than being demoed.
## The frame
Every AI product is sold on its model, but the seat cost is paid on its integration. For an SME, the question is rarely "is this model good" and usually "does this AI live where my team already works". Three pieces of that:
- Where the data is. If most of the team's documents are in Google Workspace, the friction of pulling them into ChatGPT Enterprise is real. If they are in SharePoint, the friction of pulling them into Gemini is real.
- Where the user is. A meeting summariser that lives in Teams is used. A meeting summariser that lives in a browser tab is opened occasionally and forgotten.
- What the work shape is. Long-form analysis is different from short drafting which is different from data extraction which is different from agentic workflow.
With that frame, here is how the four products land.
## Microsoft Copilot for Microsoft 365
The default answer if the business already runs on Microsoft 365. Copilot lives inside Outlook, Word, Excel, Teams, OneDrive and SharePoint, so the friction is close to zero. The licence is roughly £24.70 per user per month at the time of writing, on top of an existing M365 Business Standard or Premium seat, and it is sold annually.
Where Copilot earns its seat: meeting transcription and summarisation inside Teams, drafting first-pass replies in Outlook, summarising long Word documents, querying across SharePoint and OneDrive for content the user knows exists but cannot find. The Excel work is improving but still narrow; do not buy Copilot expecting it to replace a financial analyst.
Where Copilot is the wrong answer: businesses on Google Workspace (the integrations do not exist), workflows that need very long context windows (Copilot's context is shorter than Claude's), and any work that benefits from being on a non-Microsoft model. Also, the cleanup tax is real; Copilot exposes how badly your SharePoint is organised. Some of the value our clients get from the rollout is actually from the cleanup the rollout forces.
The pilot pattern that works: five to ten power users for three months, weekly check-ins, then a structured 90-day review. We have written more about that elsewhere on this site.
## Google Gemini for Workspace
The default answer if the business runs on Google Workspace. Gemini for Workspace lives inside Gmail, Docs, Sheets, Slides, Meet and Drive, and the integration is now substantially good, which was not true 18 months ago. Pricing sits around £19 per user per month on top of a Business Standard or Plus seat, again sold annually.
Where Gemini earns its seat: drafting in Gmail and Docs, "help me understand this spreadsheet" inside Sheets, video-call summaries in Meet (often the cleanest of the four for this), and Drive-wide search across content the user owns or has access to. The Workspace integration is the point; trying to use Gemini meaningfully without Workspace is harder than it looks.
Where Gemini is the wrong answer: M365 shops (no real integration), regulated workflows where Anthropic or OpenAI's enterprise data-handling commitments matter more than Google's, and any work that benefits from being on a non-Google model. The standalone Gemini app is fine, but if the business is paying Google for Workspace already, the value is in the integration, not the app.
## Anthropic Claude Team
The default answer when the work is analytical, long-form, or document-heavy and the integrations matter less than the model. Claude Team runs at $30 per seat per month (about £24), billed annually, with a five-seat minimum. It plugs into Slack, Microsoft 365 and Google Workspace via connectors, but the natural home is the Claude app itself.
Where Claude earns its seat: long-document analysis (lease reviews, regulatory submissions, contract diffs), structured drafting where consistency matters more than speed, research synthesis across multiple sources, and any work where a 200,000-token context window meaningfully changes what is possible. We have property-management clients running lease summarisation through Claude that would not work on either Copilot or Gemini because the documents are too long.
Where Claude is the wrong answer: businesses that need AI inside their existing apps rather than as a separate tool, sales workflows where the user wants email-and-go (Copilot wins on that), and anything where the user is unlikely to open a separate app every day.
## OpenAI ChatGPT Team and Enterprise
The default answer when the work is varied, the team wants a single capable tool, and the integration story is fine but not the point. ChatGPT Team is $30 per seat per month (about £24), annual, two-seat minimum. ChatGPT Enterprise prices on application and adds SSO, audit logs, longer retention controls, and a larger context window.
Where ChatGPT earns its seat: general-purpose drafting and ideation, custom GPTs (light internal tools), data-extraction work (turning a messy PDF into a clean table), image generation when the team needs it, and code assistance when the team has a developer. ChatGPT also has the largest connector ecosystem of the four, which matters for a business with a heterogeneous stack.
Where ChatGPT is the wrong answer: businesses that are already paying Microsoft for Copilot and would be paying twice for substantially overlapping capability, regulated workflows where Microsoft's or Google's enterprise commitments are easier to sign off, and any work that benefits from the deep Office or Workspace integration the other two offer.
## How this lands on an invoice
For a 25-person SME, the rough monthly cost is similar across the four:
- Copilot for M365: 25 × £24.70 = £617.50
- Gemini for Workspace: 25 × £19 = £475
- Claude Team: 25 × £24 = £600
- ChatGPT Team: 25 × £24 = £600
The numbers are close enough that the decision is rarely about price. It is about fit, and about whether you are buying one tool or two.
The split we see working: one stack-native product (Copilot or Gemini, depending on the M365/Google answer) for the integrated everyday work, plus one analytical product (Claude or ChatGPT) for the deeper work that does not fit cleanly inside Office or Workspace. About a third of our AI clients run this two-tool pattern. The rest run one and are satisfied.
## How we help the decision
Most SMEs do not need a 40-page comparison deck. They need three calls:
- What stack are you on? M365, Google Workspace, or split. That answer narrows the integration story to one or two products.
- What is the highest-value workflow? If it is meeting summaries and Outlook drafting, the answer is probably Copilot or Gemini. If it is long-document analysis or research synthesis, the answer is probably Claude or ChatGPT.
- Who runs the pilot? Five to ten people, three months, with someone owning the review. Without that, the answer is "do not buy yet".
That sequence usually lands on a single product in under an hour. We then run the pilot, set up the policy and security backing, and review the rollout at 90 days. If the answer is wrong, the licence is monthly enough that the cost of being wrong is small.
## Where this lands with us
This is the work our AI Enablement practice runs every week. We are vendor-independent across the four products, we configure the deployment so the data-handling commitments are contractually clear rather than just assumed, and we sit alongside the team during the rollout. The seat cost is real, but the bigger cost is the wrong product picked for the wrong reason and the lost months of rollout work that follows.
The four products are good. The decision about which one fits is the work.
Trying to pick between two AI vendors and not sure how to frame the call? Drop us a note at info@jmopartners.co.uk and we will do an initial fit review.
JMO|Partners · Enterprise IT, sized for SMEs.
# Hallucination tolerance by workflow: where AI mistakes cost you nothing, where they cost £15,000
By Jamie, Founder. Published 2025-10-26.
A client emailed us a few weeks ago to ask whether they should be running supplier invoices through ChatGPT to extract the line items. The honest answer is "it depends on what happens when it gets one wrong", and that question turns out to be the only one that matters when you are working out whether to put AI on a workflow. Every workflow has a tolerance for mistakes, and matching the workflow's tolerance to the model's reliability is the whole job.
The risk banding below is what we have ended up using on the discovery call. It is rough by design; a useful frame beats a precise one when the model output is itself fuzzy.
## Band one: mistakes cost you nothing
Workflows where the output is reviewed by a human before it goes anywhere, where the AI is a first-pass tool, and where a wrong answer means the human edits it rather than the business losing money.
Meeting summaries. The transcript is the source of truth. If the summary misses a point, the user adds it back. If it adds a point the meeting did not cover, the user removes it. Worst-case cost: a minute of editing.
Drafting internal communications. An all-hands email, a project update, an internal Slack message. A human reads it before it sends. The AI is doing 60% of the writing and the human is doing 40% of the editing, and the editing is the quality gate.
First-pass searching across documents. "Find me the section in the policy about overtime." If the AI returns the wrong section, the user spots it immediately because they can read. Worst-case cost: thirty seconds.
Most of the AI value we see at SMEs lives in this band. It is also the safest band to start in, which is why pilots that begin here tend to land cleanly.
## Band two: mistakes cost you minutes, sometimes hours
Workflows where the output goes to an internal audience that will not necessarily catch the mistake immediately, but where a wrong answer is recoverable.
Drafting customer-facing emails for internal review. Sales team uses AI to draft outreach, marketing uses AI to draft newsletters, support uses AI to draft tier-one replies. A human still signs off, but the review may be lighter than it should be, and a confidently wrong line can ship before anyone notices. Worst-case cost: a customer asks a question the email answered incorrectly, and somebody on the team spends an hour unwinding it.
Summarising long reports for the SLT. If the summary misrepresents the conclusion of a 60-page document and the SLT reads only the summary, the decision they make is wrong. The cost is the time it takes to spot the error and revisit the decision, which is usually a meeting.
Code suggestions for internal tooling. If a developer is using AI to write a script that runs internally, a wrong answer breaks the script and the developer fixes it. Recoverable, but the recovery time is non-trivial.
This band needs lightweight controls. A second pair of eyes on customer-facing copy. A "summary of what changed" note from the AI itself. Spot-checks of the source against the output, weekly rather than per-item. The aim is not zero-defect; it is a defect rate the business can absorb.
## Band three: mistakes cost real money
Workflows where a wrong answer leads to a financial loss, a regulatory issue, or a customer-facing commitment the business has to honour.
Invoice extraction and posting. AI reads a supplier invoice, extracts the line items, posts them to the accounts package. The 80% case works. The 20% case (credit notes, multi-currency, multi-line splits, items where the VAT treatment is non-standard) is where the cost lands. We have seen this one quoted as a £15,000 problem when an SME let it run unsupervised for three months and the bookkeeper had to unwind every entry by hand.
Contract drafting with no legal review. An AI generates a service agreement that a non-lawyer signs and sends. The clause the AI made up that sounds plausibly legal turns out to be unenforceable or to commit the business to something it did not mean. The cost is in the lost dispute or the lost engagement when the customer's counsel reads it.
Quote generation without a human price check. AI drafts a customer quote based on a description of the work. The quote is 30% too low. The business is now committed to the price.
These are not workflows AI cannot help with. They are workflows where AI must be a draft tool and the human must be the gate. The cost of removing the human gate is structurally too high to recover from a productivity gain.
## Band four: do not do this yet
Workflows where a single wrong answer is materially expensive and the human gate is not feasible, either because volume is too high or because the failure happens in real time.
Autonomous customer-service chatbots without a human escalation path. The bot answers product questions, makes product commitments, quotes prices. Volume is too high for review. A confidently wrong answer ships before anyone sees it. We have not seen this work at any SME we have spoken to, and we have spoken to a few that tried.
Financial calculation without a downstream check. AI calculates depreciation, runs cash-flow forecasts, prices a deal. The output is used as the source figure for a decision. A model that hallucinates 1% of the time is unacceptable when 1% of the figures are wrong.
Compliance reporting. A model summarising regulatory submissions or generating the SAR (subject-access request) responses. The cost of a wrong answer is the regulatory exposure, which can be six-figure even for SMEs in regulated sectors.
Band-four workflows are not permanently off the table. They are off the table until either the model reliability improves materially or the human gate becomes economically viable at the volume in question.
## How to use the frame
Three steps on the call:
- List the workflows. Not "AI in general"; the specific things the team does today that AI might change. Drafting outreach, summarising calls, extracting invoice data, drafting contracts, answering customer queries.
- Band each one. Where does a wrong answer land? Recoverable in seconds, in minutes, in money, or not at all?
- Build the pilot list from bands one and two. Stay out of bands three and four for the first 90 days. Revisit band three with human gates once the team has a feel for the model's reliability on real work.
## Where this lands with us
The risk band is the first slide of every AI assessment we run. It does two useful things at once: it sets a realistic expectation for what AI is going to do in the first quarter, and it gives the policy a backbone, because the acceptable-use policy that comes out the other side maps directly to the bands.
The mistake we see SMEs make is not running an unsafe workflow once. It is running a band-three workflow as if it were band one, because the band-one rollout went well and the team forgot the bands are not the same shape.
Thinking about which workflows to put AI on next and want a second opinion on the risk shape? Drop us a note at info@jmopartners.co.uk.
JMO|Partners · Enterprise IT, sized for SMEs.
# The AI acceptable-use policy nobody reads (and how to write one that does)
By Oliver, Founder. Published 2025-08-26.
Most AI acceptable-use policies we read at SME clients are inherited from a template. They are six to ten pages long, cover every possible AI scenario the drafter could think of, mention regulations the business is not subject to, and have not been opened by anyone except the person who saved them to SharePoint. They are not policies. They are paperwork.
The policies that actually shape behaviour are the ones the team can read in under five minutes and remember the headline of. We have written a handful of these for SME clients and the shape is now fairly settled. It is five sections, two pages, and a review every six months.
## Why the template policy fails
Three patterns sink the inherited-template AI policy.
It is too generic to be useful. "Employees must use AI tools responsibly" is not a policy; it is an aspiration. The employee asking "can I paste this customer email into ChatGPT to draft a reply" gets no answer from the document. So they paste it in, because the work needs doing.
It lists tools the business does not use. Templates often enumerate fifteen AI products by name, most of which the business has never bought a seat for. The team reads the list and concludes the policy was not written for them, because it was not.
It mixes the policy with the rationale. Two pages of "why AI matters and how AI is changing work" before any actual rule. Nobody gets to the rule. Whatever is on page one is the policy in practice.
The fix is not a longer policy. It is a shorter one, written for the actual stack, with the supporting material in an appendix the curious can read and the rest can ignore.
## The five sections
The shape we have landed on:
### 1. Approved tools (one paragraph)
The named list of AI products the business has paid for and configured. "We use Microsoft Copilot for Microsoft 365 and ChatGPT Team. No other AI tool is approved for work data." That is the section. If the team wants to use something else they have to ask, because the policy is enumerative not permissive.
Three notes on this section. First, name the products by their full enterprise tier ("Microsoft Copilot for Microsoft 365", not just "Copilot"), because the consumer tier is a different product with different data-handling commitments. Second, update this section quarterly; the AI vendor landscape moves fast enough that "approved tools" goes out of date. Third, keep the unapproved list short or do not have one; the rule is "approved" not "everything except these".
### 2. Data classification (one paragraph, one table)
Three classes of data, each with a yes/no answer for AI use. This is the bit the team comes back to.
- Public data. Marketing copy, published documents, general web research. Any approved AI tool, no restriction. Use it.
- Internal data. Internal documents, meeting notes, draft work, anything not classified higher. Approved AI tools only, inside the enterprise tier. Standard work.
- Confidential or regulated data. Customer personal data, financial information, employee records, anything covered by a confidentiality agreement, anything regulated. Do not paste this into any AI tool unless a specific configuration has been signed off, which it will not have been for the everyday Copilot or ChatGPT seat.
The table is short. The team can remember it. That is the point.
### 3. Workflow scope (one paragraph)
What the AI tools are for, and what they are not for. Two lines.
What they are for: drafting, summarising, searching, first-pass analysis of documents and emails. Anything where a human is reviewing the output before it goes anywhere.
What they are not for: making decisions on behalf of customers, generating financial figures used as the source of record, drafting legal commitments without legal review, replying to customer queries without a human read. Anything in band three or band four of the risk frame, in other words.
### 4. What to do if something goes wrong (one paragraph)
If something has gone into an AI tool that should not have, the team needs a route. The route is: tell the IT lead, do not delete the chat (it is the evidence), do not panic. The IT lead then assesses whether anything material has happened, contacts the vendor if needed, and decides on next steps. Disciplinary action is not the default; the default is education and a process tweak.
The policy that punishes mistakes loudly is the policy that hides them. The team learns to not say when they have made a slip, and the slip becomes a real problem rather than a teachable moment. The opposite stance, treating slips as policy improvements, gets better outcomes.
### 5. Review cadence (one line)
"This policy is reviewed every six months by the IT lead. Last reviewed: [date]." That is the section. Without it, the policy ages and the approved-tools list goes stale.
## The supporting appendix
For the curious, three appendices at the end, none of which the staff member needs to read:
- A. Why these tools. The reasoning behind the approved list, what the enterprise tier covers, the data-handling commitments in plain English.
- B. Worked examples. Six or seven scenarios staff have actually asked about, with the answer. "Can I paste a CV into Copilot to summarise it" gets a specific answer rather than the team guessing.
- C. The compliance map. Where this policy maps to UK GDPR, the ICO guidance on AI, and any sector-specific regulator. This is the section that satisfies the cyber-insurance questionnaire.
The appendices are where the depth lives. The policy itself is the two pages.
## How the policy actually lands
Writing the policy is half the work. Landing it is the other half.
What works: a 20-minute all-hands session walking through the five sections, with the worked examples open on screen, and time for questions. The questions tell you which bits of the policy are unclear, which gets folded back into the next revision. A copy on the intranet that is searchable, and a brief reminder six months later when the review happens.
What does not work: emailing the PDF and asking the team to confirm they have read it. They have not, and the policy is no more real than it was before.
## Where this lands with us
The acceptable-use policy is a deliverable inside our AI Enablement assessment. We write it specific to the stack, with the worked examples drawn from the workflows the team actually runs. The team-briefing session is part of the engagement; it is not a separate workshop.
The policy that gets read is the policy that gets followed, and the policy that gets followed is the policy that protects the business when the next cyber-insurance renewal asks the question.
Working on an AI policy and want a second opinion before it goes to the team? Drop us a note at info@jmopartners.co.uk.
JMO|Partners · Enterprise IT, sized for SMEs.
# Copilot pilot pattern: five users, three months, what to actually measure
By Matthew, Founder. Published 2025-11-10.
Most Copilot pilots we are asked to review at month three have not really happened. The licences were bought, the seats were assigned, two or three users tried it for a fortnight, and the question "should we roll wider" gets answered on vibes. That is not a pilot. That is a software purchase that did not get used.
A pilot is a structured experiment with a defined population, a defined duration, defined measurements, and a defined decision at the end. Five users, three months, four numbers. We have run this shape a dozen times now and the pattern holds.
## Why five users
Not three (statistically thin and noisy if one is on holiday for a fortnight), not ten (the budget conversation gets harder, and the variance does not narrow much). Five is the population that gives a usable signal at a cost the business can absorb if the answer is "do not roll wider".
Who the five are matters more than how many. Three principles:
- Cover the work shape. Not five people from the same team doing the same job. A spread across the kinds of work the business does: a sales person, a finance person, a delivery lead, an operations person, an admin role. If Copilot does not earn its keep for one of these, you want to know before you commit £10,000 a year.
- Pick people who will use it. Not the loudest sceptic, not the loudest enthusiast. The colleague who tries things, gives honest feedback, and is busy enough that they will not use a tool that costs them time.
- Brief them once, properly. A 45-minute session explaining what Copilot can and cannot do, with examples from their actual work. Not a generic training video. The pilot starts with people who know what they have been given.
## Why three months
Two months is not enough; the team is still in the novelty phase, the workflows have not stabilised, and the early enthusiasm has not faded into the realistic mid-quarter pattern. Four months is more than is needed; the answer is usually visible by week ten and waiting longer just defers the decision.
Three months also matches the natural M365 billing rhythm and gives enough monthly check-ins to spot patterns. The shape we run:
- Week 1. Briefing, account setup, first workflow scoped per user. The pilot lead checks each user has a real first task to try by Friday.
- Weeks 2 to 4. Daily use. A 15-minute check-in at the end of week 2 and week 4. The check-in is not a survey; it is a conversation about what worked and what did not.
- Month 2. Steady-state use. A 30-minute review at the midpoint. Workflows that are sticking should be visible. Workflows that are not sticking get a second look.
- Month 3. Continued use plus a structured 60-minute review at the end. The decision conversation is the deliverable.
## What to measure
Four numbers, all of which the business can collect without buying a measurement tool.
Usage frequency per user. Microsoft 365 admin gives you Copilot usage per user per app per week. Not a perfect measure (a user who opens Copilot twice a day for thirty seconds each looks the same as one who runs a forty-minute summarisation session), but a usable proxy. The pattern to look for is a steady or rising line. A user whose usage drops to zero in week six is telling you something.
Self-reported time saved per user per week. Ask the pilot users at each check-in: "Hours saved this week by Copilot, your honest estimate." The number is fuzzy by design. What matters is whether it is rising, stable, or falling, and whether the user can give an example of where the saving came from. "Three hours, mostly in meeting summaries and Outlook drafting" is a useful answer. "Hard to say, maybe an hour" means the value is not yet clear.
Quality concerns per user. Did Copilot get something wrong this week, and what happened? A non-zero answer is fine and expected. A pattern (the same user catching the same kind of mistake repeatedly) tells you which workflows to add to the band-three list in the policy.
Would you keep it? Asked at the end of month three. A binary yes or no, with one sentence of why. The sentence is the value of the question.
That is the dashboard. Four numbers, ten minutes to update per user per week.
## The decision conversation
The 60-minute review at the end of month three is the point. The shape:
- Each pilot user reports. Usage, hours saved, quality concerns, keep-or-drop, in two minutes each. Ten minutes total.
- Patterns across the five. Which workflows showed up everywhere? Which kinds of work was Copilot good at, which was it bad at? Twenty minutes.
- The roll-wider question. If we expanded to the next twenty users, which of those would land in band one and which would not? Twenty minutes.
- Decision. Roll wider with a defined scope, run a second pilot with a different population, or do not buy. Ten minutes.
The decision is usually clear by the end of the hour. When it is not, the answer is "run another pilot with a different team", not "buy it anyway and hope".
## What to do with a mixed answer
Sometimes the pilot lands ambiguous. Two users are getting value, three are not, and the team is split on whether to expand.
Three follow-ups that work better than "vote on it":
- Look at what the two are doing differently. If their workflows are recognisably different from the three, the question is not whether Copilot is good. It is whether the business has enough of those workflows to justify the seat cost.
- Try a different five. A second pilot with a different population. Cheaper than rolling wider on a guess.
- Drop to a smaller licence count and run on. If two users want to keep it, run two seats for a quarter and revisit. Most Copilot work is annual, but some packages allow monthly true-ups; check before assuming.
## Where this lands with us
The pilot shape is the part of the AI Enablement engagement that we run alongside the client. We run the briefing, the check-ins, the review at month three, and the decision conversation. The deliverables are the four numbers, the patterns synthesis, and a roll-wider plan if the answer is yes.
The pilot that lands is the pilot that is run properly. The pilot that does not is the one that gets bought, half-tried, and rolled wider because the renewal date came around. We have helped more clients unwind the second pattern than we have helped run the first, which is why this shape exists.
About to start a Copilot pilot and want a second pair of eyes on the shape? Drop us a note at info@jmopartners.co.uk.
JMO|Partners · Enterprise IT, sized for SMEs.
# What a 25-person AI rollout looks like, week by week
By Oliver, Founder. Published 2025-12-25.
The question we get asked most often after the pricing one is how long an AI rollout actually takes. The honest answer for a 25-person SME is six working weeks, give or take a fortnight depending on the stack and how clean the documents are. Not six months; the long-rollout stories are usually about an enterprise with a procurement gate and a regulator. For an SME with three founders and a clear stack, six weeks is the shape, and the shape repeats.
We have run this cadence enough times that the weeks have names. Here is what each one looks like and what the team should be doing inside it.
## Week 1: discovery
The week the rollout is fastest to get wrong if it is skipped. The aim is not to talk about AI; it is to understand the work the team actually does, so the rollout has a target rather than a slogan.
What we run: four 45-minute conversations across the business, one per main work area. A founder, a sales person, an operations person, a finance person. The conversation is not "what AI workflows do you want"; it is "walk me through your Monday morning, your Wednesday afternoon, the thing that ate three hours last week". The AI use-cases drop out of those conversations more honestly than they do out of a brainstorm.
What the client owes us: access to the people, a calendar, and a list of the tools they already pay for. That is the input. The output of week one is a shortlist of three to five workflows where AI looks like it would land, ranked by how clearly the risk band sits in band one or two.
## Week 2: policy and stack
The week most rollouts skip and then regret. The aim is to have the acceptable-use policy written, the approved tools chosen, and the data-handling commitments in writing before any seats are bought.
What we run: a 90-minute session with the SLT to agree which AI product fits the stack (M365 shop, Workspace shop, or other), what the approved-tools list will say, and what the data-classification table looks like. The session produces a draft policy by end of day. The draft is then circulated for a 48-hour comment window, refined, and signed by Friday.
What the client owes us: someone with authority in the room and a willingness to make calls. The policy that gets stuck in committee delays everything downstream.
By the end of week two, the business knows which AI product it is buying, has a signed policy that covers it, and has a configured tenant or workspace ready to provision seats.
## Week 3: pilot start
The week the work starts being visible. The aim is to get five seats live, the pilot users briefed, and the first workflows running before Friday.
What we run: the seat provisioning (usually a few hours of admin work, sometimes a day if the tenant needs cleanup first), a 60-minute briefing with the pilot five, and one-to-one 30-minute sessions through the week with each user to get their first AI-supported workflow up and running. The briefing covers what the product does, what the policy says, where the data-classification line is, and what the four pilot measurements will be.
What the client owes us: the five users available for an hour each in week three. Not later. The pilot that loses its first week is a pilot that takes nine weeks instead of six.
By end of week three, the five are using Copilot or Gemini or Claude or ChatGPT in real workflows. The dashboard has its first numbers.
## Weeks 4 and 5: pilot run with light training
The weeks where the team finds out what works. The aim is to let the use settle into a real pattern, with light support and the first round of workflow tuning.
What we run: a 15-minute check-in at the end of week four with each pilot user (five conversations, an hour and a quarter total), plus a 60-minute group session in week five where the pilot users compare notes. The group session is where the patterns become visible; one person discovers a use-case that another had not tried, and the pilot gets richer.
We also begin building the prompt library in these weeks. Two or three prompts per pilot user, the ones that produced the best output, captured with the source workflow they fit. The prompt library is a deliverable; we do not leave the rollout without one.
What the client owes us: the time. The check-ins are short but they have to happen. A pilot user who is too busy to do a 15-minute check-in is a pilot user who is too busy to use Copilot, and that is itself a data point.
## Week 6: decision and roll-wider plan
The week the rollout becomes a permanent capability or a refund conversation. The aim is to run the structured 60-minute review, make the keep-or-drop call, and write the plan for the next 20 users if the answer is keep.
What we run: the review meeting with the pilot five plus the SLT, the dashboard summary across the three months, and the roll-wider plan if appropriate. The plan covers who gets seats in months two and three, in what order, with what onboarding, and at what budget.
If the decision is to roll wider, the next three to four months are mostly business-as-usual: more users onboarded a few at a time, the prompt library grows, the policy gets refined as edge cases come up. The intensive work is done.
## What runs in parallel through the six weeks
Three workstreams that do not get a week of their own but matter to the rollout landing cleanly.
Information security review. The vendor's data-handling commitments, retention configuration, audit logging, SSO and conditional access. This is set up in week two alongside the policy and verified in week three before the pilot users go live. By week four it is invisible, which is the right state for it.
Cost tracking. The licences, the consultancy time, the internal time spent on the rollout. We build a simple sheet in week one and update it weekly. By week six, the business has a real per-user-per-month cost figure including the rollout overhead, which is the figure that matters for the roll-wider conversation.
Documentation. The policy, the prompt library, the use-case map, the dashboard. All live in one place the team can find. We hand it over at week six and it becomes the SME's own asset.
## The cost shape
Indicative for a 25-person SME, six-week engagement:
- Assessment and policy work, weeks 1 to 2: from £7,500.
- Pilot deployment, configuration and training, weeks 3 to 6: from £15,000 depending on stack complexity.
- Five seats of the chosen AI product, three months: about £1,800 to £2,400 at SME pricing.
- Review and roll-wider plan: included in the deployment fee.
Total cash outlay for the six weeks: roughly £24,500 to £25,500. If the decision at week six is "do not roll wider", the seats stop costing and the business has paid for the discovery, the policy, and the honest answer. If the decision is to roll wider, the per-user cost going forward is the seat licence plus a light support layer that folds into the Managed Services contract.
## Where this lands with us
This cadence is the AI Enablement engagement. We sit alongside the team for the six weeks, run the discovery, draft the policy, configure the deployment, run the pilot, and write the review. The team owns the outcome; we own the cadence.
The mistake we see most often is treating week one as administrative and rushing to week three. The discovery is the difference between a pilot that lands and a pilot that drifts, and it is also the cheapest part of the engagement to do well.
Thinking about an AI rollout and want to see whether the six-week shape fits your business? Drop us a note at info@jmopartners.co.uk.
JMO|Partners · Enterprise IT, sized for SMEs.
# Cyber-insurance questionnaires are asking about AI: what underwriters want to see
By Jamie, Founder. Published 2026-01-10.
We saw it on three renewal questionnaires in March, then four in April, and at this rate every UK SME cyber-insurance policy is going to ask about AI by the autumn. The questions are not subtle, and the underwriters have moved faster on this than we expected. Eighteen months ago, "AI" was not a section on a renewal form. In 2026 it is four sections, and the businesses that have an answer ready will renew on better terms than the businesses that do not.
This post is what we are seeing on the forms and what an underwriter is looking for when they read the answers. Cyber-insurance renewals have moved quickly enough on this that the post may not date well, but the pattern is clear enough now to be worth writing down.
## Why the questionnaires changed
Two things. The first is a real claims pattern; insurers have started seeing AI-adjacent losses, mostly in two shapes. One is data leakage, an employee pasting customer data into a consumer AI tool and the data showing up somewhere it should not. The other is what one underwriter called "confident-wrong" failures, an AI generating an output (a quote, a contract, a price) that committed the business to something it did not mean.
The second is regulatory pressure. The ICO has been clearer about AI in 2025 and 2026, and the EU AI Act enforcement timeline lands in earnest this year. Underwriters are pricing in the risk that a regulatory action will land on an SME that did not have its AI house in order.
Together those have made AI a category of cyber risk the underwriters now want visibility on, the same way they ask about backups, MFA and patch cadence. This is the new normal, and the questionnaires reflect it.
## Section 1: which AI tools are approved for company use
The question, in the formulation we are seeing most: "List the AI products approved for processing company data, including the enterprise tier or licence type." Some forms add: "Note any AI products that have been used on company data without formal approval."
What the underwriter is looking for: a named list of products, with the enterprise tier specified. "Microsoft Copilot for Microsoft 365" not "Copilot". "ChatGPT Team" not "ChatGPT". The enterprise tier matters because it covers the data-handling commitments the underwriter actually cares about; the consumer tier does not.
The bad answer: "Employees may use AI tools at their discretion." That tells the underwriter the business does not know what data is going where, and the premium reflects it.
The good answer: a list of two or three products, with the tier, plus a one-line policy reference. "We use Microsoft Copilot for Microsoft 365 and ChatGPT Team. Other AI products are not approved for company data. Acceptable-use policy attached as Appendix C."
## Section 2: what data classes go into AI tools
The question, paraphrased: "Describe the data classes processed by AI tools and the controls preventing higher-classification data from entering AI systems."
What the underwriter wants: evidence that the business has a data-classification model, knows what goes where, and has some controls to enforce it. A three-class model (public, internal, confidential) with a yes/no answer per class is what we usually see ticked off as adequate.
The bad answer: "We trust our employees to use AI appropriately." That is not a control. The good answer mentions training, the policy, and any technical controls in place (DLP rules, conditional-access policies, browser extensions that warn on paste, audit-log review).
## Section 3: vendor data-handling commitments
The question: "Confirm the contractual data-handling position of each approved AI vendor, specifically: data residency, retention period, training opt-out, and audit-log access."
This one trips a lot of SMEs because the answer requires having actually read the vendor's enterprise terms. The four items are not always together on a single page on the vendor's website, and they vary by tier.
What the underwriter wants: the four bullets, in plain English, for each product. "Microsoft Copilot for M365: data stays in EU region, default 30-day retention configurable to immediate deletion, no training on customer data by default, audit logs available via Purview." "ChatGPT Team: data in US region with EU pilot available, 30-day retention, no training on customer data, audit logs in admin console."
The bad answer is silence or a link to a page. The good answer fits in a paragraph and demonstrates the business has done the work.
## Section 4: AI-related incident response
The question: "Describe how an AI-related data incident would be detected, contained and reported, including any specific procedures for AI tool misuse."
This is the section we see the most blanks on, because most SMEs have not written it. What the underwriter wants is recognisable continuity with the rest of the incident-response plan; the AI-specific bit is usually a paragraph addition rather than a separate document.
The shape that lands well: a named person who handles AI-policy concerns (usually the IT lead or the founder), a route for staff to raise a concern without immediate disciplinary action (the policy-improvement framing matters), a check on whether the data has actually left the business (vendor audit logs, employee account history), and a notification path to the underwriter and to any data subjects if appropriate.
## The supporting documents the underwriter wants to see
Three attachments turn a clean answer into a discount-eligible answer:
- The acceptable-use policy. Two pages, the five-section structure we have written about elsewhere on the site. The underwriter reads it.
- The vendor data-handling summary. A one-pager listing the approved tools and the four-item table above. Internal document, but the underwriter looks for it.
- The incident-response addendum. A paragraph appended to the existing incident-response plan, covering the AI-specific bits. Does not need to be a separate plan; it does need to exist.
Three documents, each under two pages, all sitting in SharePoint or Drive in a folder the IT lead can find at five minutes' notice when the broker asks.
## What the discount looks like
We have seen renewal premiums move by 5% to 12% on AI-related answers in the last two quarters. That is not enormous on an SME policy, but it is real, and the cost of putting the documentation in place is roughly the cost of two months of premium discount on a typical 25-person business. The maths usually works.
The discount is not the only reason to have the documentation, but it is the reason that gets the conversation on the board agenda when other reasons do not.
## Where this lands with us
The four documents are deliverables inside our AI Enablement assessment. We draft them specific to the stack, the work the business does, and the vendors the team uses. The documents are not the point; the answer they give the underwriter is.
The renewal that lands cleanly is the renewal that has the answers ready before the broker asks. The renewal that does not is the one with the awkward phone call in week three of the cycle.
Cyber-insurance renewal coming up and want a second pair of eyes on the AI sections? Drop us a note at info@jmopartners.co.uk.
JMO|Partners · Enterprise IT, sized for SMEs.
# The post-pilot Copilot stall: why power users love it and the rest of the team isn't
By Matthew, Founder. Published 2025-10-10.
A pattern we have seen at every SME we have worked with on a Copilot rollout beyond the pilot phase: month three is good, month four is good, month six is suspiciously quiet, and the month-nine review shows two camps. The original five pilot users are still saving meaningful time. The next twenty users are using Copilot intermittently or not at all. The licence cost is steady, the value is concentrated, and the question "should we have rolled this wider" gets asked at the worst possible moment, halfway through the annual commitment.
This is the post-pilot stall. It is not a Copilot-specific problem, but Copilot rollouts surface it more visibly than other software because the value is so user-dependent. Here is the shape we see, and the pattern that pulls a stalled rollout back into productive use.
## Why the stall happens
Three reasons that compound.
The pilot users self-selected. The five people who were briefed, made time, and gave the rollout an honest run were already the kind of people who try new tools. The next twenty are not necessarily the same population. Most are too busy to add a tool to their day without a forcing function.
The wider briefing was lighter. The pilot users got a 60-minute session and 15-minute check-ins. The wider rollout often got a 20-minute group session and an email with a link. The drop in onboarding density correlates almost perfectly with the drop in usage.
The workflows did not transfer cleanly. The pilot users discovered the workflows that worked for their specific jobs. The wider rollout assumes those workflows are universal. Some are; meeting summaries work for anyone in meetings. Some are not; the way a specific salesperson uses Copilot to draft outreach does not translate to the operations team without a translation.
## What the 90-day review of a stalled rollout shows
When we get called in on a stalled rollout, the pattern is consistent. The usage data tells the story before any conversations need to happen.
Two distinct populations. Plotting active users per week against weeks since onboarding, two curves emerge. The pilot group sits flat at a high usage level. The post-pilot wave starts at a moderate level, drops by week three, and is at near-zero by week six. Same product, same prompts, different onboarding pattern.
No prompt library handover. The pilot users built a working set of prompts. Those prompts mostly live in the pilot users' heads. The wider rollout never inherited them.
No mid-team champion. Each team that adopted Copilot wider had no nominated person inside the team who owned it. The IT lead is too far from the day-to-day work; the team needs its own person.
The check-in cadence collapsed. The pilot had a structured cadence of conversations. The wider rollout had a launch and then silence. Without a forum for "I tried this and it did not work", the team's quiet frustration becomes quiet disuse.
## How to pull a stalled rollout back
The pattern that works, in the order we run it.
### 1. Segment the population
Pull the usage data and identify three groups: still-using, drifted, and never-started. The numbers are different per business but the shape is consistent. Plan the recovery for each group separately, because the intervention is different.
For the still-using group, the work is mostly to keep them productive and surface their prompts to the rest. For the drifted group, the work is a targeted re-onboarding with the workflows that fit their specific job. For the never-started group, the work is a short pilot of two or three people from the group to find out whether the product fits the work at all.
### 2. Build the prompt library properly
The library is the artefact that translates pilot-user knowledge into wider-rollout fuel. Two prompts per workflow, per role, with the source workflow described in one sentence. Lives in a single location, searchable, owned by a named person, reviewed quarterly.
This is unglamorous work, and it is also the highest-leverage piece of a recovery. A prompt library someone can copy from at the moment they have a task to do beats any amount of generic training.
### 3. Nominate team champions
One person per team of five to eight, whose role is to be the "ask me about Copilot" person inside that team. Not a heavy commitment; an hour a week of office hours plus visible use. The team needs a peer, not an IT lead two layers away.
The champions get a 90-minute briefing on the prompt library, the policy, and the most common workflows. They do not need to be technical; they need to be the person on the team who tries things and tells the truth about whether they work.
### 4. Reinstate the cadence
A monthly 30-minute meeting per team where the champion runs through what worked that month, what did not, and what the team is asking about. The meeting produces three things: a quick-wins list for the team, a problems list for the rollout lead, and a sense that this thing is being managed rather than left to fend for itself.
Three months of this cadence usually pulls the never-started group up to the drifted group's level, and the drifted group back into productive use. The still-using group keeps going.
## What not to do
Three patterns we see attempted that mostly do not work.
More training. The team has had training. More training is not the problem and is not the answer. What they lack is the moment-of-task workflow that fits their specific job; a generic refresher does not produce that.
Cancel the licences. Tempting if the usage data is bad, but it punishes the still-using group for the rollout's failures. Try the recovery first; cancel at the year-end if the recovery does not land.
Switch products. The conviction that "Copilot is bad, we should try ChatGPT instead" is sometimes right but more often wrong. If the usage data shows the still-using group is getting real value, the product is fine and the rollout is the problem. Switching products restarts the problem.
## Where this lands with us
Adoption recovery is one of the engagements our AI Enablement practice runs. We come in at the post-pilot stall point, look at the usage data, build the prompt library properly, nominate the champions, and reinstate the cadence for three months. The engagement is shorter than the original rollout because the core work, the discovery and policy, is already done.
The rollout that gets second-stage attention is the rollout that produces real value. The rollout that does not gets cancelled at renewal and goes down as an expensive lesson.
Sitting on a Copilot rollout that has stalled and not sure how to restart it? Drop us a note at info@jmopartners.co.uk.
JMO|Partners · Enterprise IT, sized for SMEs.
# Building an SME prompt library that's actually used
By Jamie, Founder. Published 2025-09-25.
A team that has been using Copilot or ChatGPT for six months has built up a working set of prompts. They live in chat histories, in saved messages, in the heads of the two power users, on the back of one person's notebook. The prompts work, but the value of them is locked inside individuals. New joiners do not get them. Adjacent teams do not see them. When the power user goes on holiday or moves on, the prompts go too.
A prompt library fixes that. It is unglamorous work and it is the single highest-leverage piece of infrastructure for an AI rollout past the pilot phase. Here is the shape that lands.
## What a prompt library actually is
Three things, in that order:
- A list of prompts the business has tested and decided to keep. Each one tied to a specific workflow, written down in the form the user actually pastes in.
- A short description of when to use each one. Not "this prompt is for emails", which is not specific enough. "Drafting a follow-up email after a discovery call, when the call notes are pasted in above."
- A worked example of input and output. Real input, real output, ideally with the names changed. Without the example, the user has to guess what the prompt expects.
That is the unit. Multiply by the workflows the business runs and you have a library.
## Where it lives
Two principles: it lives where the team already works, and it is searchable.
For an M365 business, that is usually a SharePoint site, with one page per workflow category and the prompts as expandable sections inside the page. For a Google Workspace business, a Drive folder with one Doc per category. For businesses that have Notion or Confluence, those work fine; the test is whether the team can find a specific prompt in under thirty seconds.
What does not work: a chat in Slack or Teams ("just check the pinned posts"), a OneNote notebook nobody opens, an Airtable that requires another login. Friction kills adoption. If the user has to think for more than ten seconds about where the prompt library is, they will not check before writing the prompt themselves, and the library stops being the source of truth.
## How it is structured
By workflow, not by role. The library is for "drafting a customer follow-up" or "summarising a long document" or "extracting line items from an invoice", not for "the sales team prompts" or "the finance team prompts". The same prompt may be useful across roles.
Inside each workflow page, three to five prompts maximum. More than that and the user picks the wrong one. Better to have one strong prompt per pattern than four similar ones.
Each prompt page has:
- The prompt itself, in a code block so it copies cleanly.
- The one-sentence "when to use this".
- The worked example, input and output.
- Who owns it (a named person, not a team).
- The last review date.
The owner and the date are the part most libraries skip. Without them, prompts go stale and nobody catches it.
## Who owns the library
One named person, usually the IT lead or whoever ran the rollout, with deputies for each main team. The owner's job is to add new prompts when the team finds them, retire prompts that stop working, and run the quarterly review.
The deputies' job is lighter. They are the "ask me which prompt to use" person inside their team, and they flag candidate prompts to the owner. Three to five deputies for an SME of 25 to 50 people is the right shape.
What does not work: making the library a community wiki anyone can edit. Quality drops, duplicates appear, and the trust the team has in the library disappears within a quarter. The model that works is a small group of editors with a clear pipeline for contributions from everyone else.
## How prompts get in
A pipeline, not a free-for-all. The shape:
- A team member finds a prompt that works. They use it for a week to make sure the value is real.
- They submit it to their deputy. A simple form or a Slack message, with the prompt, the workflow, and the worked example.
- The deputy reviews and forwards to the owner. The review is light; the owner adds the prompt, sets the owner field, and announces it.
- The team is notified. A monthly "new prompts this month" digest, three to five items, with a link to each.
The submission-to-publication time should be under a week for the pipeline to feel responsive. Longer than that and people stop submitting.
## The quarterly review
The review is the discipline that keeps the library trustworthy. Once a quarter, the owner and the deputies go through every prompt and answer three questions:
- Has the model output changed materially since this prompt was added? (Model updates can break a working prompt.)
- Is the workflow still real, or has the team stopped doing it?
- Are there two prompts doing similar jobs that should be merged?
The review usually retires a quarter of the library and adds new ones to balance. A library that is the same size and the same prompts after a year is a library nobody is using.
## What success looks like
Six months in, the library is the answer to "how do I use Copilot for X" for most of the business. New joiners get pointed at it on day three of induction and have working prompts inside a week. The two power users who built most of the initial set are still contributing, but they are no longer the bottleneck. The team's collective prompt skill is rising, not concentrated.
The licence cost is the same as it always was. The value is twice what it was at the post-pilot stall, because the prompts are now team knowledge rather than individual knowledge.
## Where this lands with us
The library is one of the deliverables of our AI Enablement engagements. We seed it during the pilot with the prompts the pilot users discover, hand it over with the structure and owner in place, and check in at the quarterly reviews if the client wants us to. After the first review, most clients run it themselves.
The library is the smallest piece of infrastructure with the biggest effect on whether a rollout produces compound value or peaks at month three and tails off.
Working on the prompt-library piece of an AI rollout and want a template to start from? Drop us a note at info@jmopartners.co.uk.
JMO|Partners · Enterprise IT, sized for SMEs.