The moment it was not, for us, arrived with AI. No one kicked a door down or anything, it kind of crept up on us in the same way it might have done so to a lot of people in the tech world. We just looked up one quarter and realized AI was doing real, load-bearing work at several stages of our lifecycle while our unwritten process still quietly assumed a human was doing all of it. That gap is where bad things grow.

So we standardized our software development process, not the fun kind either, where someone makes a slide deck with eight boxes and an arrow and a flash dance. The tedious kind, where you write down what you actually do, discover that maybe half of it is wrong, and argue your way to something the whole team will sign. This post is about that kind of work and the process of standardizing the process. It is less glamorous than a fancy flowchart and about ten times more useful if you are thinking about doing this yourself.

The Tell: Everybody knew the process, nobody agreed on it

The first honest thing we did was stop describing our process out loud and start writing it down. Talking about a process is easy because conversation smooths over the seams but without putting it in writing, it was all just talking and no action. Writing forces you to define each part with words. Is the requirements doc reviewed, or has it been approved? By whom? Before or after the estimate?

We sat down with a whiteboard and listed every stage from the first client conversation to code in production. Eight stages came out of it: discovery, scope, define, plan, build, verify, release, monitor. Nothing exotic. The exotic part was what happened when we first asked each person to describe, in one sentence, what actually happens inside each stage. The sentences did not match. They were not contradictory exactly, they were just different enough that two developers could both follow “the process” and produce different work. That is the tell. If your team cannot independently write the same sentence about a stage, you do not have a standard there, you have a tradition loaded with assumptions. These kinds of traditions are fine enough when you’re starting out but they do not survive growth, turnover, or a new tool that revolutionizes who does the work.

Microsoft’s Well-Architected Framework has a whole section on formalizing development practices, and the part that stuck with us is the framing: standardization is not about control, it is about making the work predictable enough that you can improve it. You cannot tune a process you cannot describe.

Why: AI changed who was doing the work

Plenty of teams talk about standardizing for years and never do it, because there was never really an immediate need or a deadline to the process as long as everything was done on time and within budget. For us, the sideways and yours probably did too, if you’ve made it this far. AI had crept into our day to day with a draft here, a test case there, and a second opinion on a pull request. Eventually, it just became too useful to ignore, too fast to be invconvenient, and eventually completely unaccounted for in any document we had. Our process assumed a person wrote the requirements doc. A person did, sort of, with a lot of help. Our process assumed a person reviewed every line of a pull request and a person did, after something else had already flagged the obvious stuff. None of that was reckless, it was just not written down, which meant nobody could tell you where the human checkpoints were supposed to be. And when you cannot name your checkpoints, you cannot tell whether you still have them. There is no consistency and that can really derail time management in a a team.

So we picked a single organizing question and held it over every stage. When and where does AI come into the equation and who should be reviewing the additional work required to meet expectations? That line of questioning turned out to be the whole project. It is specific enough to argue about and broad enough to apply to discovery, planning, testing, and deploys alike. Microsoft’s own AI-assisted development guidance treats these tools as accelerators inside an existing engineering discipline rather than replacements for it, and that matched what we were seeing in practice. AI is spectacular at drafting, structuring, and speed. It is not the thing you want holding the virtual pen on scope.

Step One: Write the Real Process

The temptation when you standardize is to document the process you would have if everyone behaved perfectly. Resist it, as an aspirational process document is a work of fiction, and your team will read it exactly once. We wrote the current state first, warts included, and some of the warts were embarrassing. There was a stage where “the client signs off” meant an email reply that said “looks good.” There was a period where tickets moved into development without an estimate anybody had actually agreed to, much less kept track of. So, writing it all down in plain language did more to fix it than any amount of process design, because once it is on the page in front of a handful of people, somebody says out loud what everyone was thinking.

Only after the current state was out there did we start making changes, and the changes were smaller than we expected. Most of what we needed was already happening somewhere on the team, just not everywhere, or consistently, or in an order anyone could predict. Standardizing is usually less about inventing practices and more about picking which existing version of a practice wins.

One early decision shaped everything afterward and it was that discovery stays a real, billed, scoped phase. Not a courtesy call, not a free hour before the proposal. We learned the hard way on a past project that speed only helps after you actually know what you are building. Point AI at a fuzzy problem and it will cheerfully help you build the wrong thing much faster than before. Microsoft’s guidance on requirements management for agile teams makes a similar point in a gentler language. The requirement is the unit everything downstream depends on, so it is worth slowing down for.

Step Two: Consistency is Key

We went stage by stage with the same question, and we did not let ourselves skip a box because the answer seemed obvious and well, the obvious ones were where we found the surprises. Take the requirements spec. The answer looked simple enough, AI drafts it and a person reviews it. But asking properly forced two follow-ups. First, what does AI get to work from? We decided, everything. The signed statement of work, the discovery notes, every call recording and transcript, every scrap of prior documentation from the client. More context in, better output. There is no such thing as over-briefing here, and half the bad AI output we had seen was really just under-briefed AI output. Second, what does the human review actually mean? We landed on something slightly heretical. The client signs the spec, and we treat that signature as a strong starting point rather than a frozen contract. Requirements change as you learn. Pretending otherwise just moves the argument to change orders later, which is a worse place to have it. That is what asking the question properly does, and by properly, we mean every single time. It takes a box you thought was settled and turns it into two decisions you now have in writing.

Step Three: Open Dialogue

The most productive hours of this whole effort were the ones that felt least productive at the time. Specifically, the shortcuts we talked ourselves into and then back out of. The biggest one was to let AI turn the requirements spec straight into a finished implementation plan, with developers simply picking up tickets at the end. It is so fast and genuinely tempting but it is the biggest mistake anyone can make with AI. It quietly pushes every misunderstanding downstream to the exact point where fixing it is most expensive. A developer executing someone else’s plan, or something else’s plan, is a developer who does not fully understand what they are building and you find out on the day it matters. So we rejected it, and we wrote down that we rejected it, along with why and that last part matters more than it sounds. Six months from now someone new is going to look at our planning step and think “why is a human doing this, we could automate it.” The document answers them. A standard without its reasoning attached gets quietly eroded by every clever person who joins after you wrote it.

What we kept instead was that spec use cases would become epics, and breaking an epic into tickets is done together by AI, the assigned developer, and the technical lead. AI drafts the first pass. The people who will actually build the thing shape the rest. It is slower on paper but faster in reality, and the developer walks in understanding the work.

Step Four: Make Every Rule Checkable

Here is where a lot of standardization efforts quietly die. You write “tickets should be well defined before development starts,” everyone nods, and nothing changes, because “well defined” is a vibe and vibes do not gate check anything. We forced every rule into something checkable. Our Definition of Ready became four concrete items, and a ticket clears all four or it does not enter the queue:

• acceptance criteria written so they can become tests
• an estimate the assigned developer personally agrees to
• dependencies identified
• a design or mockup attached whenever a UI is involved.

No exceptions, even for the person who wrote the rule.
The acceptance-criteria-as-tests piece turned out to be the quiet MVP of the entire project. When each requirement becomes its own test, three good things happen without anyone doing extra work. Developers know when they are done. Reviewers know what to look for. And AI has an actual target to aim at, which is the difference between AI that helps and AI that produces plausible-looking work nobody can evaluate. Microsoft’s architecture strategies for testing make the same argument from the reliability side, tests defined against explicit criteria are what make a change reviewable at all. The checkability test is a good filter to run over your own draft standard. Read each rule and ask what you would look at to know it was followed. If the answer is “you would just kind of know,” rewrite it or delete it.

Step Five: Label Everything

Not everything we discussed deserved to become a rule, and pretending otherwise is how process documents get ignored. Some things we were sure about and some things we are still figuring out. We labeled everything differently on purpose. One rule we decided on was that we do not run sprints. Work moves through one continuous lane on a single board, pulled rather than assigned, with a strict limit of one ticket in flight per developer. That was a real decision with real tradeoffs, and Microsoft’s documentation on work in progress limits and Kanban generally covers the mechanics better than we could. Our reason for it was specific though, sprint commitments assume you can predict a two-week window, and the pace of AI-assisted work has been changing faster than any two-week estimate anyone would make. A pull system and a WIP limit gave us flow control without asking anyone to forecast something they cannot forecast. In part, it is an openly labeled experiment, whether AI code review should ever skip the human step entirely. We are intentionally undecided. It is an open question across the industry, and we would rather run it as an experiment with a review date than write a policy we do not believe yet.

Another one we admitted in writing was with backlogs running past a hundred items, we do not yet have a clean way to see which tickets are genuinely ready to build. We are piloting checklist tooling and automation rules and that is it, that is the whole entry. Writing “we have not solved this” in your own standard feels bad for about a day and then pays you back forever, because it tells the team where to push and it keeps the document credible.

Step Six: Note Obstacles Disguised As Essential

Every standard needs a small number of things that do not bend. Ours came down to one, a human confirms every release before it ships. Almost everything upstream of that gate now runs itself. Automated tests, a quality and security scan, an AI review pass that checks the change against our standards and leaves comments. Verification is where AI does the most independent work we give it anywhere, the Playwright suite runs first, AI classifies each failure, then AI runs its own exploratory pass against the deployed feature hunting for the cases nobody thought to script. A developer other than the author still confirms every finding and operates the feature by hand before signing off. Microsoft’s Azure App Testing and Playwright Workspaces docs cover running that kind of suite at scale, and the pipeline approvals documentation covers the gate itself.

The reason we drew the line there rather than somewhere else is because the release decision is the only step in the lifecycle where the cost of being wrong lands entirely on the client. Everything else is recoverable inside our own walls. Microsoft’s safe deployment practices guidance treats progressive, verifiable rollout as a discipline rather than a tool choice, which is roughly how we think about the final gate. It is not that we distrust the automation. It is that somebody’s name belongs on the decision. For projects at the right scale, once the pipeline is solid and a rollback plan genuinely exists, we ship qualifying deploy is with a blue-green pattern, which in Azure terms usually means deployment slots and a swap. It is worth being precise about what that is and is not since blue-green only ever fires after the human approval. It is how an already-approved release ships without downtime. It is not a second, quieter way of deciding whether to ship.

Step Seven: Note Obstacles Disguised As Essential

A process you have only tested on a whiteboard is a hypothesis. We ran ours on live client work, which is uncomfortable and also the only way to find out what is actually wrong with it since real projects surface the friction immediately. A stage that reads beautifully takes four days in practice. A checklist item that seemed essential could turn out to be a formality nobody uses. We changed several things after the first pass, including tightening what Design Review covers, because it turned out two different stages were both quietly claiming to approve architecture. We also kept notes on the moments people worked around the process instead of with it because workarounds are diagnostic. When a good developer routes around a step, the step is usually wrong, not the developer. Treat those as bug reports against the standard, not compliance problems, and people will keep telling you about them.

Step Eight: Build the Feedback Loop

The last piece of standardizing is making sure the standard does not rot the moment you publish it. Two things do that for us. The first is technical, after release, nightly regression runs keep going, AI reviews the results, and it opens tickets directly for anything that fails. By the time anyone starts the next working day, issues are already queued and triaged, straight back into planning. Azure Monitor supports the same shape of loop with work item integration from Application Insights, so production reality flows back into the backlog without waiting for somebody to notice. A lifecycle that only runs one direction is a waterfall wearing a hoodie. Yes, we did consider creating an image like that to prove this point. The second is cultural, the document has a version number and an owner, the open questions have review dates, and we expect to be wrong about at least some things. Security is a good example of something we deliberately left room to revise, since the shape of a secure development lifecycle keeps moving as the tooling does. We also published it to the team rather than filing it, because a standard in a shared drive nobody opens is just a very long opinion. Kind of like a blog. ;)

What we learned standardizing our software development process

If you are staring down the same project, here is the short version of what we learned, minus the parts that were specific to us. The best way is to write the current state before the future state, and be embarrassing about it. Pick one question and ask it at every single stage, including the boxes you think are settled. Record the shortcuts you rejected along with every reason why, because that reasoning is the only thing protecting the decision later. Make every rule checkable or cut it. Label your experiments as experiments and your unsolved problems as unsolved. Choose a very small number of gates that never move, and be able to explain why those are there and not others. Pilot it on real work. Build a loop that feeds production back into planning and then expect to revise the whole thing. Review new rollouts because something could have been released that changes everything you just settled on.

And this is all just a note on scale, since we are a small local firm and not a platform org with a process department. Small teams sometimes assume standardization is something you do when you have outgrown something but we found it to be the opposite. A small team that can actually agree on something in a room with a written standard, while everyone still fits in that room, is a standard everyone believes in. Doing it later means doing it to people instead of with them.

None of this is about trusting AI less in the process. It is about being precise regarding what it is good at, which is drafting, structuring, and accelerating, while keeping people working where it actually matters, which is scope, requirements, and the call to ship. We will keep refining it, and we will write about what changes. If you are working through the same questions at your own shop, whether that is your first AI-assisted project or a process document that has not been opened since 2023, we are always up for comparing notes. So, come argue with us. That is rather the point of writing it down.

Here is the good news, and it is genuinely good news. Most of the incidents that generate that pile start with something small and preventable. A password nobody rotated. A firewall nobody patched. A backup nobody tested. The controls that stop them are already sitting inside the Microsoft and Azure licensing you are probably paying for right now. You just have to turn them on and keep them on.

Let us walk through the true cost of a cyber incident, what it looked like for real companies, and which Azure basics do the most work for the least money. If you would rather skip to the part where somebody else handles it, our managed IT and cloud services cover that too.

The Real Cost of a Cyber Incident Starts After the Ransom

IBM’s 2026 Cost of a Data Breach report puts the global average breach at $4.99 million, a twelve percent jump over the prior year, with healthcare leading at $6.6 million. Before you close the tab, fair warning, those averages lean heavily on enterprises with legal departments and eight-figure incident budgets. They are not your number. Your number looks more like the cyber insurance data, which tracks actual claims from actual mid-market companies. Coalition’s 2026 Cyber Claims Report found the average ransomware claim severity landed at $269,000, with initial ransom demands up forty seven percent year over year and eighty six percent of businesses refusing to pay anyway. Business email compromise and funds transfer fraud together made up fifty eight percent of all claims, with funds transfer fraud averaging $141,000 per incident. That last one deserves a moment. More than half of all cyber claims are not dramatic hacker-in-a-hoodie events. They are somebody in accounting wiring money to a bank account that looked exactly right.

So, when you honestly price out the real cost of a cyber incident, you are adding up five separate meters, all running at once:

Add all of these together and the cost of a cyber incident for a healthy SMB regularly lands somewhere between a very bad quarter and the end of the company. Which brings us to the part where that stops being hypothetical.

What the Cost of a Cyber Incident Looked Like for Four Real Companies

KNP Logistics: 158 years, one password

KNP was a UK haulage company running roughly 500 trucks with 700 employees. In 2025, the Akira ransomware group got in by guessing a single employee’s password. They encrypted the servers, the backups, and the disaster recovery environment, then demanded around five million pounds. KNP had cyber insurance and a crisis team on site the next morning. It did not matter. The company collapsed and 700 people lost their jobs. The lesson is not “buy better insurance.” We all know there is no such thing as good insurance! The lesson here is that the backups lived where the attacker could reach them, which is what turned a bad week into the full cost of a cyber incident.

Lincoln College: an Illinois closure

Closer to home, Lincoln College in downstate Illinois survived a fire, the 1918 flu, and the Great Depression across 157 years. It did not survive a December 2021 ransomware attack that knocked out recruitment and enrollment systems during an already fragile stretch, and the school closed permanently in May 2022. The attack was not the only cause. It was the shove.

Change Healthcare: the vendor you did not know you depended on

When Change Healthcare went down in 2024, the ripple effect of the damage flowed out into small independent practices that had nothing to do with the breach. An American Medical Association survey of more than 1,400 physicians, seventy eight percent of them in practices of ten doctors or fewer, found eighty percent lost revenue from unpaid claims, fifty five percent dipped into personal funds to keep the lights on, and thirty one percent could not make payroll. Nobody attacked those practices. They just plugged into something that got attacked, and they absorbed the cost of a cyber incident anyway.

CDK Global: a billion dollars of somebody else’s outage

Same pattern, different industry. The June 2024 CDK Global attack froze dealer management software for thousands of car dealerships, most of them family-owned SMBs. Anderson Economic Group pegged the direct dealer losses at $1.02 billion over roughly three weeks.

Two of these four cases are supply chain incidents, which is not a coincidence. A growing share of the costs of cyber incidents now arrive through somebody else’s network. The cost of just how connected we all are now, without even realizing it.

What Drives the Cost of a Cyber Incident: How Attackers Actually Get In

Verizon’s 2026 Data Breach Investigations Report analyzed more than 22,000 confirmed breaches. Ransomware showed up in 48% of them, third parties were involved in 48% of breaches (a 60% jump year over year), and the human element was present in 62%. Vulnerability exploitation overtook stolen credentials as the leading way in, largely through unpatched internet-facing edge devices. The size skew is brutal. Small organizations accounted for roughly 96% of ransomware victims in the DBIR dataset. You are not too small to be a target. You are the target.

Microsoft’s own telemetry says the same thing from a different angle. The Microsoft Digital Defense Report 2025 found that more than half of attacks with a known motive were extortion or ransomware, that 97% of identity attacks are plain password attacks, and that multifactor authentication blocks more than 99% of identity-based attacks even when the attacker already has valid credentials. Ninety nine percent from a control you already own. Most of the cost of a cyber incident traces back to a login that should have been challenged and was not.

The Azure Basics That Prevent Most of Them

None of what follows is exotic. It is the security equivalent of locking the back door and testing the smoke alarms, and it is where a competent Azure managed services partner spends their first ninety days. Each control below removes a specific line from the cost of a cyber incident.

1. MFA on everything, then make it phishing resistant

Microsoft is not asking anymore. Mandatory MFA for the Azure portal and admin centers finished rolling out in March 2025, and Phase 2 extended enforcement to resource management through Azure CLI, PowerShell, REST APIs, and infrastructure as code starting October 2025. The full policy and timeline live in Microsoft’s mandatory MFA documentation. We also covered this, not too long ago. If you have no policies today, flip on security defaults like, yesterday. It is free, it takes about ninety seconds, and it requires MFA registration for everyone. Then, plan the upgrade to phishing-resistant passwordless authentication with passkeys, because text message codes stopped being a serious control a while ago.

2. Let Conditional Access do the thinking

Microsoft Entra Conditional Access is the policy engine that decides, per sign-in, whether a login gets through, gets challenged, or gets blocked. It reads all the signals like user, device compliance, location, application, and real-time risk. Three policies cover most SMBs; require MFA for all users, block legacy authentication protocols, and require a compliant or hybrid-joined device for anything sensitive. Layer in risk-based policies from Entra ID Protection so a sign-in from an impossible location forces a password reset instead of a shrug.

3. Stop handing out permanent admin

Standing global admin rights are how a phishing click becomes a company-wide cyber incident. Privileged Identity Management makes admin access something a person requests, justifies, and holds for only a few hours instead of forever, which is usually the case for most organizations. Pair PIM with two cloud-only emergency access accounts with long random credentials stored somewhere physical and you have something solid. When Conditional Access misfires at 4:45 on a Friday, and someday it will, those accounts are the difference between a hiccup and a weekend.

4. Patch the edge before somebody else finds it

Vulnerability exploitation is now the leading initial access vector, and favorite targets are the internet-facing boxes nobody owns, VPN appliances, firewalls, and that one server that is still running because a report depends on it. Azure Update Manager gives you scheduled, unified patching for Azure VMs and Arc-enabled servers on premises, with compliance reporting that tells you what actually got patched instead of what you hoped got patched. On the endpoint side, attack surface reduction rules block the specific behaviors ransomware relies on, like Office spawning child processes and scripts launching downloaded content.

5. Backups the attacker cannot touch

This is the one that decided KNP’s fate, and it is the single highest-leverage control on this list. Modern ransomware crews hunt backups first. Microsoft’s Azure backup and restore plan to protect against ransomware lays out their answer. It is the 3-2-1 rule, immutable storage using write once read many, and multi-user authorization so destructive operations require a second approver out of band. Azure Backup ships soft delete on by default, retaining deleted backup data for an extra fourteen days at no cost, and the security features overview covers immutable vaults and the rest. Turn all of it on and then, and this is the part everyone skips, restore something on purpose once a quarter. An untested backup is a rumor.

6. Give your endpoints and workloads a brain

Microsoft Defender for Business is included in Microsoft 365 Business Premium and is purpose-built for companies under 300 seats. Endpoint detection and response, automated investigation and remediation, vulnerability management, and all in a console a human can actually operate. For your Azure and hybrid workloads, Microsoft Defender for Cloud handles posture management and workload protection. If you are already paying for Business Premium and running the free antivirus that shipped with the laptop, you are leaving the good stuff in the box. Microsoft’s security best practices for business is the checklist.

7. Watch, measure, and know when something is off

Prevention fails eventually. Detection is what shortens the incident. Microsoft Sentinel is the cloud-native SIEM that correlates signals across identity, endpoint, email, and Azure, and for an SMB it is usually consumption-priced into something reasonable. For a running scorecard, Microsoft Secure Score measures your posture across identity, apps, and devices and hands you a ranked list of improvement actions. It is the closest thing to a credit score for your tenant, and it makes board conversations dramatically shorter.

The Napkin Math on the Cost of a Cyber Incident

Here is the comparison that truly matters. A thirty seat SMB moving to Microsoft 365 Business Premium, turning on Conditional Access and PIM, hardening Azure Backup with immutability, deploying Defender for Business, and paying a managed IT partner to run all of it, is spending somewhere in the low tens of thousands per year, all in. Try saying all of that in one breath!

The average ransomware claim is $269,000. The average funds transfer fraud loss is $141,000. Neither figure includes the three weeks you did not invoice anybody. You are not buying certainty. You are buying the difference between a Tuesday you complain about and a Tuesday that ends the company. Framed that way, the cost of a cyber incident makes the security budget look less like overhead and more like the cheapest insurance on the balance sheet.

A Thirty Day Plan That Lowers the Cost of a Cyber Incident

Week one. Turn on security defaults or a baseline Conditional Access policy. Block legacy authentication. Inventory every account with admin rights and write the number down, because it will be higher than you think.

Week two. Enable soft delete and immutability on backup vaults. Identify your three most critical systems and confirm you have a restore path for each.

Week three. Deploy Defender for Business to every endpoint. Enable attack surface reduction rules in audit mode first, then enforce.

Week four. Pull your Microsoft Secure Score, knock out the top five improvement actions, and run one live restore test. Document what broke, because something will.

That is a month. It is not glamorous, and it removes most of what actually drives the cost of a cyber incident at a company your size. We even visualized it for you.

Where CSW Solutions Fits In

Let’s be transparent here. Every control above is documented publicly, included in licensing you probably own, and technically available to anyone with an admin login and a free afternoon. The problem was never availability. It is that you already have a job, and it is not this one. Security posture decays quietly, and the cost of a cyber incident is what that decay eventually invoices you for.

What we do at CSW Solutions is own the boring, relentless middle. We are probably one of the few locally managed IT services and Microsoft partners around, and our managed security work is exactly the list above, executed on a schedule and reported on in language a business owner can act on. We design and enforce Conditional Access instead of leaving it half-configured. We keep patching current across Azure and your on-premises servers. We build backups that survive an attacker who is specifically looking for them, and we actually test the restores. We are in your time zone but we watch the alerts at hours when nobody in your office is awake, and we track your Secure Score quarter over quarter so improvement is a number, not a feeling. We work with companies across manufacturing, professional services, healthcare, and distribution. We know what a thirty person firm can realistically absorb, and we know which controls earn their keep first. Nobody here is going to sell you a security operations center you do not need.

If you are not sure where you stand, it is perfectly normal and you’ll be happy to know it is a solvable problem. A short conversation and a look at your tenant will tell you more than another article will. Whenever you are ready, we would be glad to talk. Your business survived a pandemic, a supply chain, and at least one Chicago winter that felt personal. A guessed password should not be the thing that gets it.

FAQ or TLDR

What is the average cost of a cyber incident for a small business? Enterprise averages run near $4.99 million globally, but they are not representative of SMBs. Cyber insurance claim data is the better yardstick: ransomware claims average around $269,000 and funds transfer fraud averages around $141,000, before downtime and lost revenue.

Does cyber insurance cover the cost of a cyber incident? Partially, and increasingly with conditions. Most carriers now require MFA, endpoint detection and response, and tested backups before they will write or renew a policy. KNP Logistics had coverage and still closed, because insurance pays claims, it does not restore encrypted backups.

What is the single highest-value security control for an SMB? Multifactor authentication, especially phishing-resistant MFA. Microsoft’s data shows it blocks more than ninety nine percent of identity-based attacks. Immutable, tested backups are a close second.

Do we need Azure to get these protections? Not entirely. Much of this lives in Microsoft 365 Business Premium, including Defender for Business, Conditional Access, and Intune. Azure adds Update Manager, Defender for Cloud, Sentinel, and immutable Azure Backup for hybrid and cloud workloads.

How do we lower the cost of a cyber incident without a big budget? Start with what you already own. Security defaults or Conditional Access, immutable backups with soft delete, Defender for Business on every endpoint, and one tested restore. Those four steps cost licensing you likely already pay for plus a few days of focused work.

How long does a ransomware recovery take? Two to four weeks is common for an SMB without immutable, tested backups. With them, it is often days. The gap between those two outcomes is the entire argument for doing this work before you need it.

That is the whole thesis of this post in one bug. Sustainable AI engineering is not a sustainability initiative that happens to involve software. It is software engineering, of the ordinary kind, applied to a resource that used to be too cheap to think about. The teams winning on cost, latency, and increasingly on procurement in 2026 are not the ones with the best carbon narrative. They are the ones who treated energy per unit of work as a real engineering constraint, gave it a number, put that number in CI, and refused to ship regressions against it.

You cannot optimize your way out of this at the infrastructure layer, because someone already did

Worth getting this out of the way, because it is the most common misconception in the room. The datacenter is not where your remaining efficiency lives. Microsoft reports a fleet average power usage effectiveness of 1.17 for FY25, meaning overhead costs about seventeen cents of energy for every dollar spent on actual computation. There is not a lot of room left in that number, and none of it is yours to capture. You inherit it the moment you deploy, along with the closed-loop cooling, the renewable matching, and the hardware refresh cadence.

What that means practically: two companies running the same model in the same Azure region have identical infrastructure efficiency and can still differ by an order of magnitude in energy per transaction. The entire delta is architecture and code. And the pressure to close that delta is now external, not aspirational. Microsoft’s own 2026 report disclosed FY25 emissions of 20.29 million metric tons of CO2 equivalent, up 25 percent year over year, driven primarily by AI infrastructure growth. If a company with a carbon negative commitment and effectively unlimited procurement leverage still watched demand outrun efficiency, the lesson for the rest of us is that the fix has to happen where the demand is generated. Which is in the application.

Give it a number or it is a vibe

Software engineering became a discipline when we started measuring things, and sustainable AI engineering crossed that threshold in 2024 when the Software Carbon Intensity specification was accredited as ISO/IEC 21031:2024. The formula is small enough to memorize:

SCI = ((E * I) + M) per R

Energy consumed, times the carbon intensity of the grid supplying it, plus embodied emissions from the hardware amortized over its life, all divided by a functional unit of your choosing.

That last term is the one that matters to engineers, and it is why SCI is useful where a total emissions number is not. SCI is a rate, not a total. Pick your R as one API call, one document processed, one support ticket resolved, one agent run, and suddenly you have a metric that behaves like every other engineering metric you already trust. It goes down when you improve the system and up when you regress it, independent of whether traffic grew. A total emissions number cannot tell the difference between a team that doubled its efficiency and a team that doubled its users. SCI can.

Microsoft publishes a reference architecture for actually computing this on Azure, and it is refreshingly buildable: pull energy and emissions data from the Azure carbon optimization APIs, pull utilization and scaling factors from Application Insights, pull real-time grid carbon intensity from a provider like WattTime or Electricity Maps, land it all in Data Lake Storage because the portal only retains twelve months, compute the score in Azure Functions, and report in Power BI. The baseline itself comes free: Azure Carbon Optimization is included for all subscriptions and reports emissions down to individual resources, with recommendations for SKU changes and idle resource cleanup plus an estimate of the savings before you commit.

A real example of the measurement discipline, because the rigor is instructive: AVEVA published an SCI case study for its System Platform product measured on a single ThinkCentre workstation, using a precision power supply accurate to 0.01 watts. Baseline draw was 11.3 watts, loaded draw was 16.0 watts, giving a software-attributable delta of 4.67 watts. Multiplied across 8,322 annual operating hours at a global average grid intensity of 474.8 gCO2e per kilowatt-hour, plus 70 kilograms of amortized embodied hardware carbon, that produced a score of 0.474 gCO2e per licensed instance per year. Notice what they did not do: they did not estimate, and they did not measure the whole machine. They isolated the delta attributable to their own code. That is the standard.

The model layer is where the joules are

For AI workloads, the single highest-leverage engineering decision is which model handles which request, and the answer is almost never “the biggest one, always.”

Microsoft’s own guidance on optimizing AI workload cost puts real numbers on this. Routing 60 to 80 percent of traffic to smaller models such as GPT-4o mini or Phi-4, escalating to a frontier model only when the small model signals low confidence, typically cuts cost by that same 60 to 80 percent on routine queries with no measurable quality drop. The Azure OpenAI Batch API carries a 50 percent discount for work that tolerates a 24 hour window, which covers nightly index refreshes, evaluation runs, embedding jobs, and most summarization. Scale-to-zero on GPU container workloads saves up to 90 percent of idle capacity for a cold start measured in tens of seconds. Matching the GPU SKU to the model size, T4 or L4 class hardware under thirteen billion parameters instead of reflexively provisioning H100s, saves 40 to 70 percent. Spot capacity for checkpointable batch work saves 60 to 80 percent, and 4-bit quantization via AWQ or GPTQ fits a thirty billion parameter model onto a sixteen gigabyte card.

Microsoft productized the routing insight, which tells you how load-bearing it is. Model router in Microsoft Foundry is a single endpoint backed by a trained classifier that reads each prompt for complexity, reasoning demand, and task type, then dispatches to an underlying model. It ships three modes: balanced considers only models within one to two percent of best available quality, cost widens that band to five or six percent and optimizes hard for high-volume savings, and quality ignores cost entirely. You are billed for whichever model served the request, with no router surcharge.

The engineering work here is not calling the router. It is building the evaluation harness that tells you whether the cheaper path is actually good enough for your traffic, because Microsoft’s percentages are ranges from other people’s workloads. No eval set, no routing. That is the order of operations, and teams that invert it ship a cost win and a quality regression on the same day.

Caching is the other big lever, and it rewards deliberate prompt architecture. Because Azure OpenAI matches on the first 1,024 tokens and then in 128 token increments, the correct design is stable content first and variable content last:

[ system instructions      ]  <- identical on every call, cacheable
[ tool and function schemas]  <- identical on every call, cacheable
[ few-shot examples        ]  <- identical on every call, cacheable
------------- 1024 token boundary crossed -------------
[ retrieved context        ]  <- varies
[ user message             ]  <- varies

Provisioned deployments can see up to a 100 percent discount on cached input tokens, so the difference between a template assembled thoughtfully and one assembled by string concatenation in whatever order the fields appeared in the DTO is enormous. One layer up, semantic caching stores embeddings of past queries alongside their responses in Azure Cache for Redis or Cosmos DB and returns the cached answer above a similarity threshold. For an internal support assistant where four hundred employees ask the same eight questions about expense policy, this converts an inference bill into a rounding error.

Retrieval discipline belongs in the same conversation. Every unnecessary chunk you stuff into context is tokens burned on prefill for no gain in answer quality, and past a point it actively hurts as the relevant passage drowns in filler. Keeping median retrieval count low, tuning chunk size to your actual document structure, and reranking a small set instead of dumping a large one are efficiency decisions dressed up as quality decisions. They happen to be both. Same with structured outputs: constraining the model to a schema instead of asking it to write prose you then parse cuts output tokens, removes a retry loop, and deletes the regex you were going to regret.

Agent architectures deserve a specific warning. An agent loop that re-sends its entire conversation history plus twenty tool schemas on every turn has quadratic token growth baked into its design, and it will look fine in a demo with four turns and ruinous in production with forty. Pruning history, summarizing older turns, and loading tool definitions on demand rather than all upfront are not micro-optimizations at that scale. They are the difference between a feature that ships and one that gets pulled.

The boring application layer, where half the waste actually lives

None of this is AI-specific, which is exactly why it gets skipped. Microsoft’s performance efficiency recommendations for sustainable workloads read like a code review checklist, and the overlap with sustainability is total: reduce chatty API interactions, minimize payload sizes, use efficient message encoding, implement throttling and response caching through API Management, and continuously optimize your highest-volume endpoints. Apply storage compression and fix your database queries. Align data with the right access tier and set lifecycle policies so cold data stops sitting in hot storage. Review your backup, recovery point, and log retention policies so data stops accumulating by default. Choose server-side or client-side rendering based on actual device and network conditions rather than framework fashion. Ship appropriately sized images, skip unnecessary asset downloads, and prefer system fonts. Deploy close to users and keep dependent resources in the same region.

The Well-Architected sustainability guidance is blunter still about the largest sources of waste: idle virtual machines, clusters sized for a peak that occurs twice a year, multi-region active-active topologies that roughly double emissions to defend against a failure mode nobody actually priced, and telemetry pipelines logging the same event at four layers of the stack. Nobody has ever given a conference talk called “We Deleted Eleven Terabytes Of Redundant Debug Logs.” It remains one of the highest-return afternoons available to most engineering teams.

If you want a catalog rather than principles, the Green Software Foundation maintains 62 reviewed patterns organized by lifecycle phase, with 26 in development, 16 in architecture, and 15 in operations, tagged by persona so an AI/ML engineer sees the twelve that apply to them. It is a decent source of pull request comments.

Carbon-aware code, which is now a thing you can actually write

Here is where it gets fun for engineers, because Azure API Management shipped a limited preview that turns grid carbon intensity into a runtime variable your policies can read.

Traffic shifting lets you tag backends with a preferredCarbonEmission level and have API Management prefer greener regions, falling back to higher-carbon ones only to preserve continuity. Traffic shaping exposes context.Deployment.SustainabilityInfo.CurrentCarbonIntensity directly inside policy expressions, so you can extend cache durations, tighten rate limits, or reduce logging verbosity when the local grid gets dirty:

xml

<when condition="@(context.Deployment.SustainabilityInfo.CurrentCarbonIntensity == CarbonIntensityCategory.High)">
    <cache-store duration="3600" />
    <rate-limit-by-key calls="100" renewal-period="60"
                       counter-key="@(context.Request.IpAddress)" />
</when>

That is a conditional. You already know how to write it. The interesting design question it raises is what your application should do when energy is expensive, and the honest answer for most products is: cache harder, defer the deferrable, and degrade gracefully in ways users will not notice. Which is good engineering regardless of the grid.

Put it in the pipeline or it will regress by Thursday

This is the part that separates a one-time cleanup from a durable capability, and Microsoft’s testing guidance for sustainable workloads is the most concretely useful page in the whole set.

Establish CPU and memory baselines by monitoring allocations during unit and integration tests, then configure alerts or outright test failures when the application exceeds them, so unsustainable code changes get caught in review instead of in the next quarterly bill. Cache build artifacts between runs when inputs have not changed, and use local caching on self-hosted agents to avoid network transfers. Split large repositories so CI only compiles what actually changed. Autoscale your build agents so they scale in when testing finishes rather than idling. Profile for parallelization opportunities rather than assuming. Use chaos engineering to verify the system fails gracefully instead of burning resources thrashing, and consider building what Microsoft calls an eco version of the application, a deliberately degraded mode that sacrifices non-essential features to cut emissions, and then test it like any other configuration. Where you have grid data, schedule your heavy integration and load test runs during low-carbon hours.

An allocation budget that fails the build is a strange thing to be excited about, and yet it is the single most reliable mechanism in this entire post. Everything else is a project. A quality gate is a ratchet.

Why this is an advantage rather than a chore

Three commercial reasons, all downstream of the engineering. It is margin. AI features priced per seat and delivered per token mean every avoidable token is gross margin handed to your infrastructure provider. Teams that engineered routing, caching, and batching early can price aggressively against competitors who cannot, and absorb a bad month without an emergency meeting.

It is speed, which is the same variable in different clothing. A tuned small model classifying a ticket in 200 milliseconds is a better product than a frontier model reaching the same conclusion in three seconds with more eloquence nobody requested. Users never notice your joules. They notice your latency constantly.

It is the sales cycle. Enterprise and public sector buyers increasingly put energy and emissions questions in security questionnaires and RFPs, partly from conviction and largely because their own disclosure obligations flow downstream into their vendor list. A supplier that answers with a real SCI figure, a defined functional unit, and a trend line closes faster than one that answers with a paragraph about caring deeply. The number is the differentiator, and the number is a product of your architecture.

CSW Solutions Can Help

Funny thing is, this work sits precisely where our expertise and multitude of practices overlap. On the AI and automation side, we build the routing, caching, retrieval, and evaluation layers that determine what your AI features cost to run, and we build the eval harness first so nobody ships a cost optimization that quietly degrades answer quality. On the custom software side, we can go into the application and fix the architecture generating the waste, because a cache in front of a chatty design is a bandage on a leak, and because most of the savings we find are in ordinary code rather than in model choice. On the managed IT and cloud side, we set up the Azure governance that keeps savings from evaporating in two quarters, a Carbon Optimization baseline, an SCI score with a functional unit that matches how you actually sell, allocation budgets wired into your pipelines, right-sizing reviews, and reporting you can hand to a customer who asks. Try saying all of that in one breath!

We are small enough that whoever scopes your work is whoever does it, and experienced enough to tell you when the answer is “your model selection is fine, your retrieval layer is the problem.” Most engagements start with a two-week assessment. We baseline current consumption, profile where energy and money actually go across the model layer and the application layer, model the savings against your real traffic rather than a vendor’s averages, and hand you a prioritized plan with numbers attached. Then you decide whether we implement it or we help your team to do it.

Efficient architecture used to be something engineers argued for and finance eventually approved. In 2026, it decides whether your AI product has a business model. If you would like a second set of eyes on where your compute is going, we would be glad to look. And if nothing else, go check whether there is a timestamp at the top of your system prompt.

So you have a decision to make, and most legacy application modernization advice sorts itself into two camps that are both wrong. There is the “burn it down and go cloud native” camp, and the “if it ain’t broke” camp. The first is expensive. The second is expensive later, and with less warning. The right camp? It is usually more boring and more specific.

Stop Asking Whether the Code is Bad

That is the wrong question, and it is the one everybody starts with. Code quality is real, but it is a terrible input for a modernization decision, because “this code is ugly” and “this code should be replaced” are not the same statement. Plenty of ugly code is doing exactly what it needs to do at a cost of zero dollars a month. Here are some better questions, in rough order of importance:

Is it a source of competitive advantage, or is it plumbing? If your app encodes something your competitors cannot easily copy, it deserves investment. If it is a glorified form over a database, it deserves a vendor.

How often does it need to change? An app that changes twice a year and an app that changes twice a week have entirely different economics. Technical debt only costs you interest when you keep borrowing.

Who is on the hook when it breaks at 2 a.m.? If the answer is “one person,” you have a bus factor problem, and modernization is one of several possible fixes.

What is it blocking? This is the one that usually unlocks the budget. Not “the code is old,” but “we cannot offer customers a self-service portal, we cannot integrate with the new ERP, and we cannot pass the security questionnaire that our biggest prospect just sent us.”

What does the runway look like? Support dates, license renewals, hardware warranties, and the retirement plans of the two people who understand it.

Microsoft frames the strategic menu as the six Rs of application modernization: rehost, replatform, refactor, rebuild, retire, and retain. Two of those get almost no airtime and really deserve more. Retire is free money if you find an app that three people log into and none of them can explain why. Retain is a legitimate, defensible choice that people treat as cowardice. It is not. It is capital allocation.

For the rest of this post, we are going to collapse the middle of that menu into the three doors most SMB decisions actually come down to.

Door One: Wrap It In An API

This is the option people skip, and it is usually the best one. The idea is pretty straightforward. You leave the legacy application alone, more or less, and you put a modern, well-documented, secured interface in front of it. New systems talk to the interface. The interface talks to the old app, in whatever ancient dialect the old app requires. Nobody else has to learn that dialect ever again. Microsoft calls the design principle here the anti-corruption layer, which is a wonderfully judgmental name for a translation shim. The point here is containment, the legacy system’s weird data model, its odd assumptions, and its 1990s naming conventions stop leaking into everything new you build. On Azure, API Management is the usual front door, giving you authentication, rate limiting, versioning, and a developer portal without having to write any of that yourself.

This is so often the right first move because it is cheap, it is fast, and it is reversible. You can put up a meaningful API facade over a legacy system in weeks, not quarters. It does not require you to understand every line of Kevin’s pricing module. You got that, Kevin? It immediately unblocks the thing that was actually blocked, which is usually integration, not the app itself. It also buys you something subtle. When traffic flows through a facade, you can see it. You get logs, metrics, and a real map of who calls what and how often. Most organizations discover that 80 percent of the calls hit 20 percent of the functionality, which can really inform the entire rebuild conversation later.

There is a bigger payoff hiding here too. That same facade is the setup for the strangler fig pattern, which is the single most useful idea in modernization and is named after a plant that grows around a host tree until the tree is gone and the fig is standing on its own. You route requests through the facade. Then you rebuild one capability, point the facade at the new implementation for that capability only, and leave everything else alone. Repeat. Clients never know. The legacy system shrinks a slice at a time until one day there is nothing left inside it and you turn it off on a Tuesday afternoon with no drama. No harm, no foul.

Microsoft is candid about when the pattern does not fit. If you cannot intercept requests to the backend, or you do not have source access to disable migrated features and redirect internal calls, the fig has nothing to grow on. And if the system is genuinely small, running two systems in parallel is more overhead than just replacing it. That last point is the real cost of door one. A facade means you are running two things instead of one. Temporarily. “Temporarily” has a way of becoming “since 2019.” A wrap without a stated end state is not a strategy, it is a coping mechanism.

Door Two: Re-platform

Replatform, or re-platform, is the move where you keep the application substantially intact and change what it runs on. Microsoft’s shorthand is “lift, tinker, and shift,” which is honest about the fact that there is always some tinkering. In practice, for the SMB stack we see most often, is like when an ASP.NET web app that has been running on a Windows Server VM moves to Azure App Service, and the SQL Server database behind it moves to Azure SQL Managed Instance. It is specifically built to preserve the surface area of on-premises SQL Server so you do not have to rewrite everything that touches it. This is not rearchitecting. You are basically getting out of the patching business, the hardware business, and the “we cannot scale on Black Friday” business.

The results here can be unglamorous and enormous at the same time. In a Microsoft roundup of continuous modernization work, Australian retailer Coles moved from six-week release cycles to weekly, with build times dropping from a couple of hours to 10 to 15 minutes. Credit Europe Bank NV cut customer onboarding from three days to nine minutes. Sapiens reported cutting deployment efforts in half. Notice that none of those are “we rewrote the app.” They are “we changed where and how the app lives, and the business is faster.” Assessment is not optional here, and it is the step people skip because it feels like it is not real work. Azure Migrate does discovery, assessment, and, importantly, dependency analysis, which is how you find out that the “standalone” app has a scheduled job writing to a file share that a completely different department’s Access database reads every night. That file share is not in anyone’s documentation. It is in the dependency map.

And now the cautionary tale, because re-platforming is where the most expensive public failures happen. In April 2018, TSB Bank in the UK migrated to a new core banking platform. The Financial Conduct Authority’s enforcement notice is worth reading in full, but the TLDR is that a significant proportion of the bank’s 5.2 million customers were affected when the platform experienced technical failures immediately after cutover. TSB did not return to normal operations until December of that year. Eight months. The regulators fined the bank £48.65 million between them in December 2022, and TSB paid out £32.7 million in customer redress on top of that.

Here is the part that matters for your business, whatever size it is. The FCA’s finding was not “the code was bad,” it was that TSB “failed to organise and control the IT migration programme adequately” and failed to manage the operational risks of its outsourcing arrangements. The migration failed as a program, not as a technical exercise. Big-bang cutovers concentrate all of your risk into a single weekend, and the only thing standing between you and an eight-month outage is whether your rollback plan is real. The strangler fig exists precisely so you do not have to bet the company on one weekend.

Door Three: Rebuild

Sometimes you do have to start over. The signals are usually some combination of whether the platform itself is dead and unsupportable, the data model actively prevents the business model you need, the cost of change per feature has climbed past the cost of change in a new system, or the thing has become a genuine security liability that no amount of network isolation can fix. When rebuild is right, it is very right. Microsoft’s guidance points at rebuild for highly complex applications, monolith decomposition, and cases where advanced security and compliance requirements have to be designed in rather than bolted on.

But you should always walk into a rebuild with your eyes open, and the best essay on why is a quarter century old. In 2000, Joel Spolsky wrote “Things You Should Never Do, Part I” about Netscape’s decision to throw out its codebase and rewrite the browser from scratch. His argument was that the ugly code you want to delete is ugly precisely because it is full of accumulated bug fixes, each one representing knowledge somebody paid for. Delete the code and you delete the knowledge. Netscape spent years rebuilding while Internet Explorer took the market. Two and a half decades later, the essay still gets passed around engineering teams, which tells you something about how often the lesson needs relearning.

The modern version of the mistake is not “rewrite from scratch.” It is “rewrite from scratch, in microservices, because that is what mature companies do.” Two data points worth sitting with.

Shopify, which is not exactly a small operation, has written openly about the fact that its core commerce platform is still a monolith, just a modular one, with enforced boundaries between components instead of network calls between services. They chose the discipline of microservices without the operational cost of microservices. And in 2023, an Amazon Prime Video team published an internal case study, widely covered at the time, about moving one audio and video quality monitoring workload from a distributed serverless architecture back to a consolidated monolithic service, reporting roughly a 90 percent reduction in infrastructure cost. One team, one workload, not a repudiation of everything, but if the company that popularized service-oriented architecture can look at a specific workload and say “this should be one process,” you can too.

The rebuild that works, in our experience, has three properties. It is scoped to a capability rather than an application. It runs behind a facade so the cutover is a routing change instead of an event. And it has a hard rule that the old system stays running, untouched and unimproved, until the new one has been carrying real traffic for long enough that everyone forgot the old one was even there.

The Failure Mode Nobody Plans For

There is a fourth outcome that is not a door, and it deserves its own section because it is that nightmare scenario that actually keeps us up at night.

On August 1, 2012, Knight Capital Group deployed new order routing code to its production servers. According to the SEC’s administrative order, a technician copied the new code to seven of the firm’s eight servers and missed the eighth. The new code activated its behavior using a flag that had, years earlier, been used by an old feature called Power Peg. Power Peg had been dead since 2003, but the code was never removed. On that eighth server, the flag woke it up. In roughly 45 minutes, the system executed more than 4 million orders across 154 stocks, totaling over 397 million shares. Knight lost more than $460 million. The firm did not survive as an independent company. Nobody at Knight decided to run nine-year-old dead code in production. They just never deleted it, and eventually nobody remembered it was there. That is what legacy risk actually looks like. It is not slow performance or an outdated UI. It is a system containing behavior that no living person can predict. If your reaction to any part of your codebase is “I do not know what that does and I am not going to find out,” that is not a maintenance item. That is the whole business case.

So Which Door? A Legacy Application Modernization Decision Path

Here is the compressed version of the sequence we walk clients through.

1. Start with an assessment, always. Inventory, dependency map, support dates, change frequency, and an honest read on who understands what. This takes weeks, not months, and it is the cheapest investment you will make. Azure Migrate handles the infrastructure side. For .NET specifically, GitHub Copilot app modernization tooling will now assess a codebase and propose and even apply a remediation plan for the Azure move, which has meaningfully changed the cost of the analysis step in the last couple of years.
2. If the app is fine but isolated, wrap it. The business need is almost never “this app is old.” It is “this app cannot talk to anything.” Solve the stated problem first. Then decide.
3. If the app is fine but the floor is falling out from under it, re-platform. Dead operating system, dead database version, dying hardware, unsustainable patching burden. Move it, change as little as possible, and do it in slices with a real rollback plan.
4. If the app cannot express what the business now needs, rebuild the part that cannot. Not the whole thing but the part behind a facade, with the old one still running.
5. If nobody can explain what it does, that is an emergency regardless of which door you pick. Buy the knowledge back through documentation, characterization tests, and observability before you touch anything. Don’t freak out yet, we got you.
6. And if two people log in and neither can explain why, retire it. Go find them, there are usually three of them and they cost more than anyone realizes.

One more thing, because it gets left out of every modernization plan and then eats it from the inside, decide up front who owns the new thing. A facade needs monitoring. A PaaS deployment needs someone watching cost and scaling. A rebuilt service needs an on-call rotation. If the answer to “who runs this” is a shrug, you have not modernized. You have moved the ghost into a nicer house and handed it the keys. A shrug is not an answer. It is the sound a system makes on its way to becoming legacy again.

Where CSW Solutions Fits

We are a local company based out of Chicago, which means two things for you. First, you are going to talk to the people doing the work, not an account manager who relays your questions to a team you never meet. Second, we do not have a bench to keep busy, so we have no incentive to sell you a rebuild when a facade would do. We have talked clients out of rewrites. It is one of our favorite parts of the job.

We work across custom software development, AI and automation, and managed IT and cloud, and legacy application modernization touches all three. Someone has to write the code, someone has to make sure it’s secure and scalable, run the platform afterward, and increasingly someone has to figure out where AI actually belongs in the new system instead of where it looks good in a deck. We build on Azure, and we are deep enough in it to tell you which service is the right fit and which one is just the one Microsoft is promoting this quarter.

A typical engagement starts with an assessment. It comes down to what you have, what it depends on, what is about to lose support, and what it is costing you in the places you have not been measuring. You get a document with a recommendation and a number attached to each option, including the option of doing nothing. Sometimes it says “wrap it, revisit in two years.” Sometimes it says “this needs to be rebuilt and here is the sequence.” Either way you own the document, and you are free to hand it to somebody else.

If Windows Server 2016 or SQL Server 2016 is in your environment, the clock on that is real and it is short. If Kevin’s pricing module is in your environment, the clock on that is unknowable, which is worse.

Either way, the first conversation is free and we will tell you the truth about what we find. Reach out to us any time and let us go look at what you’ve got together. Bring the AC unit story. We collect those.

Previsible’s 2025 AI Traffic Report looked at 19 Google Analytics properties and found that AI referred sessions went from 17,076 to 107,100 comparing January through May of 2025 against the same stretch in 2024. That is a 527% year over year jump, and in one of the accounts they studied, ChatGPT traffic climbed from roughly 600 visits a month to more than 22,000. Legal, finance, health, insurance, and small business services made up about 55% of all the traffic coming from large language models. Which is to say, not sci-fi verticals but your verticals.

Meanwhile, the front door of the internet quietly changed shape. Semrush tracked more than 10 million keywords through 2025 and found that the share of AI Overviews attached to commercial intent queries went from 8.15% to 18.57%, a relative increase of about 128%. Transactional queries went from under 2% to nearly 14%. Translated out of analyst dialect, this was the AI summary used to show up when people wanted to learn something. Now it also shows up when people are getting ready to buy something.

That is the whole story in two numbers. More people are arriving from AI, and AI is increasingly answering the questions that used to end in a phone call to you. This makes AI search visibility, being the company the model actually names, the lead generation problem nobody put on this year’s budget.

The Uncomfortable Middle of the Funnel

Here is the thing nobody ever dared to say out loud at the marketing meeting. For most SMBs, the top of the funnel was never really the website. It was word of mouth, referrals, the Chamber breakfast, the guy who knows a guy. The website’s job was basically to survive the background check that followed.

AI search inserted itself directly into that momentum without a hitch, and it did something more aggressive than Google ever did. It stopped handing out ten blue doors and started giving one answer with footnotes. When a facilities manager types “best commercial HVAC service near Naperville with 24 hour emergency support,” the model does not return a list for them to evaluate. It evaluates for them, names two or three companies, and offers a short reason for each. You are either in that paragraph or you are not in the conversation. There is no page two of an answer.

But the Traffic is Minimal, So Who Cares?

Fair pushback. AI referrals are still a rounding error in most accounts. Microsoft Clarity studied 1,277 domains over eight months and confirmed it. AI traffic grew 155.6% while search grew 24%, social grew 21.5%, and direct grew 14.9%, but even after all that growth AI still accounted for less than one percent of total traffic. Now the part that should make you sit up. In the same study, visitors arriving from large language models clicked through to sign up at a rate of 1.66%. Visitors from traditional search did it at 0.15%. That is roughly eleven times the rate. On subscription conversions, Copilot referrals converted at 17 times the rate of direct traffic and 15 times the rate of search. More than half of the sites in the sample had already turned AI sourced visitors into signups or subscriptions.

Microsoft’s own writeup on how AI search is changing the way conversions are measured, stacks up the corroborating research. 56% of sites saw higher conversions from AI driven sessions, with high traffic sites converting at 7.05% versus 5.81% for organic. AI referrals at 11.4% versus 5.3% for organic across global ecommerce. And Microsoft Advertising reports that Copilot powered buying journeys run 33% shorter and are 76% more likely to end in a lower funnel conversion.

Think about what that means mechanically rather than as a statistic. A nonhuman, digital model just spent four turns of conversation qualifying someone, narrowing the field, and then it named you. The person who clicks your link is not browsing. They have been pre-sold by a machine with no financial stake in the outcome, which, ironically, makes it the most persuasive salesperson you will ever have.

You do not want some of that traffic. You want every bit of it you can get.

What Losing Looks Like

Chegg is the cautionary tale everyone should know. In February 2025 the education company sued Google, alleging AI Overviews had gutted its business. The numbers in the filing were not subtle. Their fourth quarter revenue of $143.5 million went down 24% year over year, a $6.1 million net loss, and non subscriber traffic went down 49% in January 2025 alone. That’s compared to the more feasible 8% decline a couple of quarters earlier. The company was worth under $200 million and trading around a dollar a share by the time it filed.

Chegg’s problem was in a structural way that most SMBs are not. Their entire product relied on answers to questions, which is exactly the thing generative AI does for free. If your business is a service delivered by humans in a specific place, you are not facing that particular guillotine. You are facing a quieter one. If the AI model has nothing useful to say about you, it will say something useful about your competitor. If it cannot find your service area, it picks the company whose service area is written in plain text on a crawlable page. This is not malice. It is retrieval. The model quotes what it can read, verify, and restate with confidence.

And there is a version of this that is worse than being skipped and that is being described incorrectly. Stale hours, a phone number from two offices ago, a service you stopped offering in 2021, or even a certification you let lapse. All of that gets scraped, blended, and delivered to a prospect in a confident tone of voice with your name on it. You do not get a chance to correct the record before the meeting.

What Winning Looks Like

The encouraging news is that many of the companies doing well in this space are not doing anything mystical. They are doing what is legible.

An agency called Intercore Technologies restructured a Chicago personal injury firm’s site around answer first content. They created roughly 50 core pages rewritten to lead with the answer, FAQ sections built out to real depth, a proper legal entity schema markup, and a presence across more than one platform so the model had multiple corroborating sources. The result was a 68% visibility across ChatGPT, Perplexity, and Claude, 156 new clients traced to AI recommendations, about $2.34 million in attributed revenue, and a 16.9% conversion rate on AI sourced leads. Broworks, a webflow development shop, added custom schema, comparison tables, and FAQ blocks. They reported that 10% of its organic traffic was coming from LLMs, 27% of AI referred sessions became sales qualified leads, and that those visitors ended up spending 30% longer on site rather than traditional organic ones. Go Fish Digital ran the play on itself and saw a 43% growth in monthly AI driven traffic and an 83% lift in conversions from that traffic over three months. Apollo.io took a different route entirely, building out a community subreddit and publishing genuinely detailed competitor comparisons. It now sees a 63% citation rate on AI prompts about brand awareness in its category. HubSpot has already collected several of these if you want to read even more about them.

The caveat is that these are self reported agency case studies, not audited financials. Treat the direction as real and the decimal places as marketing. But the pattern is consistent and boring in the best way. Stat your business clearly. Label it so machines can parse it. Make sure more than one source on the internet says the same thing, and you’ll see results.

AI Search Visibility: What Microsoft Actually Tells You to Do

Here is where it gets practical, and where the advice is mercifully concrete, because Microsoft has been unusually forthcoming about this. Copilot is built on Bing’s index, which means Bing’s guidance is not a side quest. It is basically documentation for how to get into an AI answer.

Start with the scoreboard you did not know existed. In February 2026 Microsoft launched AI Performance in Bing Webmaster Tools as a public preview. It shows total citations, how many of your pages get cited per day, which specific URLs get referenced, and the grounding queries the AI used to find you. That last one is the good stuff. It is the closest thing anyone has to getting a keyword report for AI answers, and it is free. If you take one action after reading this, make sure it is verifying your site in Bing Webmaster Tools and opening that tab.

Then fix the plumbing. Microsoft’s guidance on keeping content discoverable with sitemaps in AI powered search is refreshingly specific. Use XML rather than plain text so the metadata survives. Make your lastmod values honest and precise in ISO 8601 format with a timestamp, so it reflects when the page content actually changed and not when your CMS republished the sitemap file. Freshness signals influence both in how fast you get indexed and how accurate the AI answer about you will be. Stop worrying about changefreq and priority, because Bing ignores both. And pair your sitemap with IndexNow, which pings participating engines the moment a page changes instead of waiting for a crawler to wander by. It is a single HTTP request. Most modern platforms have a plugin, and if yours does not, it is an afternoon of work.

Check that the crawlers can get in at all. Microsoft publishes a list of which crawlers Bing uses and a robots.txt tester inside Webmaster Tools. We have found blanket disallow rules in more client robots.txt files than we would like to admit, usually left over from a staging environment or added by a well meaning developer during a scraping panic. Blocking AI crawlers is a legitimate strategic choice for some publishers. It is almost never the right choice for a services business that wants to be recommended.

Write for extraction, not just for reading. Microsoft Advertising published a direct guide on optimizing your content for inclusion in AI search answers, and it reads like a checklist because it really is one. Use JSON-LD schema markup to label what things are: products, services, reviews, FAQs, events, organizations. Break content into modular chunks with real H2 and H3 headings, Q and A blocks, lists, and tables, because models retrieve passages rather than whole pages. Write self contained answers of one or two sentences that still make sense when they get yanked out of context, since that is exactly what happens. Anchor claims in measurable facts, and their example is perfect: “42 dB” beats “quiet.” And do not bury the good part in a tab, an accordion, a carousel, or a PDF. If a human needs to click to reveal it, assume the model never saw it.

That last point deserves its own sentence. Fact density is the whole game. “We serve the greater Chicago area with fast response times” is a sentence a model cannot do anything with. “We provide managed IT support to businesses in Cook, DuPage, and Lake counties, with a one hour response SLA on critical tickets and 24/7 phone coverage” is a sentence a model can quote, and will.

Then measure it honestly. Microsoft Clarity added dedicated channel groups, AIPlatform and PaidAIPlatform, which separate organic links inside AI chat responses from paid placements inside AI products, across ChatGPT, Copilot, Gemini, Claude, and Perplexity. You get sessions, conversions, heatmaps, and session recordings filtered to just those visitors. Watching a recording of someone who arrived from an AI recommendation is genuinely instructive, because they behave nothing like a search visitor. They arrive knowing things. They skip your careful narrative homepage flow and go looking for the one specific fact the model told them about, and if they cannot find it in about ten seconds they leave and go ask again.

One big thing to note is that attribution here is imperfect and everyone knows it. A lot of AI referred traffic shows up as Direct when the source is stripped, and Clarity does not retroactively reclassify history. Which is part of why Microsoft argues in that conversions piece that you should stop staring at last touch clicks and start tracking upstream signals such as citation frequency, impressions in answers, or how queries get refined. Preference now forms before the click, sometimes entirely without one. Their five KPIs for an AI mediated web is a decent starting framework if you like your metrics tidy.

The Credibility Loop Nobody Warned You About

Here is the strategic wrinkle, and it is the reason this belongs on other desks rather than only in marketing. Everything that makes you visible to an AI model is also what makes you look competent to a human. Structured data means someone thought about how your services are categorized. Honest lastmod timestamps mean somebody is maintaining the site. Real service area definitions, specifics instead of adjectives, case studies with numbers in them. A model reads those as retrievable facts. A buyer reads them as a company that has its act together.

The inverse is equally true and considerably more expensive. A site the AI cannot parse is usually a site with a stale CMS, a plugin stack nobody has updated, content written by committee in 2019, and no one clearly accountable for it. Prospects sense that even when they cannot name it. Now the machines are broadcasting it, in complete sentences, to people who asked for a recommendation.

There is also a genuine timing argument, and I say this as someone allergic to false urgency. AI Overview coverage has been volatile: Semrush measured it at 6.49% of queries in January 2025, peaking near 24.61% in July, then settling back to 15.69% by November. Google is clearly still tuning. Commercial coverage kept climbing anyway, and a separate Semrush analysis of more than 600,000 keywords found commercial intent SERPs with AI Overviews grew another 71% between November 2025 and April 2026, with finance up 231%. Zero click rates, for what it is worth, actually dipped slightly, from 33.75% to 31.53%, so the apocalypse narrative was totally oversold. The trend is not that clicks vanish. The trend is that fewer companies get shown, and being one of them is worth more than it used to be.

The window is open because most of your competitors are still arguing about whether this is real. Being early to a channel where a machine hand delivers pre qualified buyers is not a small edge. Ask anyone who bought Google Ads in 2006.

Your AI Search Visibility Checklist for Monday

TLDR? Or if you want the short version, in order, on a scale of hours rather than quarters, we’ve got you covered.

1. Verify your site in Bing Webmaster Tools and look at AI Performance.
2. Ask a few models what they say about your company and your top three service queries, and write the answers down verbatim so you have a baseline.
3. Check robots.txt for anything blocking AI crawlers.
4. Fix your sitemap’s lastmod values and turn on IndexNow.
5. Add organization, service, and FAQ schema to the pages that matter.
6. Rewrite your five highest intent pages so the answer comes first and the specifics are numeric.
7. Turn on Clarity’s AI channel groups so you can prove any of this actually worked.

None of that is glamorous but all of it compounds.
And you’re welcome.

Where CSW Solutions Comes In

Now the part where I tell you what we do, because you have read a couple thousand words and we always give a straight answer at CSW Solutions. We are a Chicago based IT and AI consulting firm. The reason we care about this particular topic is that it sits exactly where our service lines overlap, and it is a rare problem where the technical fix and the revenue fix are the same fix.

On the managed IT and cloud side, we do the unsexy foundation work: getting your site properly indexed, verifying you in Bing Webmaster Tools, cleaning up robots.txt and sitemaps, wiring up IndexNow, and making sure your Azure hosted site is fast, secure, and consistently crawlable. Models cannot cite a page that times out.

On the custom software development side, we do it all. We implement the structured data layer that makes your content machine readable, and we fix the CMS and template problems that bury your best facts inside tabs, accordions, and PDFs. If your service catalog lives in a system that nobody can export cleanly, that is a development problem wearing a marketing costume, and we have solved it a number of times.

On the AI and automation side, we build the monitoring loop. We track what the major assistants actually say about you, catch the moment they start describing you incorrectly, and automate the freshness signals so your published facts stay current without somebody remembering to do it. We also help you keep the internal knowledge that feeds all of this in one governed place, on Microsoft 365 and Azure, rather than scattered across eleven people’s laptops.

If you would rather just get your code up to speed or modernize ERPs in your company, those are fine reasons to call us too. Reach out to CSW Solutions and let us take a look. The models are already answering questions about your business. It would be nice if they got them right.

2026 seems to be the year where security is the number one concern among tech leaders. Zero Trust has graduated from conference-keynote vocabulary into something your cyber insurance carrier asks about in writing, and the “we’re too small to be a target” has aged about as gracefully as that Windows XP machine running the shop floor. The genuinely good news is that zero trust is no longer a thing you buy into. It is a thing you configure. If your company already pays for Microsoft 365, you are probably sitting on most of the parts. The bill is not the blocker. The blocker is that nobody has actually had a sit-down session over an afternoon and turned the knobs.

Let’s fix that.

Zero Trust, Explained Without the Vendor Fog

When you strip away the marketing mumbo jumbo, Zero Trust is three sentences long. Microsoft states them plainly in its Zero Trust guidance:

• Verify explicitly. Every access request gets authenticated and authorized using every signal available, not just a password that somebody also uses for their fantasy football league.

• Use least privilege access. People and workloads get only the access they need, for the shortest time they need it. Not forever, “because it was easier during onboarding.”

• Assume breach. Design your controls as though an attacker is already inside, because statistically, at some point, one will be.

The old model was a castle and a moat. Everything inside the network was trusted, everything outside was suspicious, and the VPN was the drawbridge. That model died the moment your team started working from kitchen tables, your accounting system moved to somebody else’s cloud, and your “network perimeter” became whatever coffee shop had an open outlet. The moat is still there. It just has a guest wifi password taped to the reception desk.

Zero Trust replaces the moat with a bouncer at every door, checking ID every single time, and being genuinely unbothered about hurting anyone’s feelings.

Three Real Cases, None of Which Required a Genius Attacker

Abstract threat models do not move budgets. Stories do.

KNP Logistics. A 158-year-old British haulage company with roughly 500 trucks and 700 employees. Attackers from the Akira ransomware group got in by guessing a single employee’s password. The company’s systems were encrypted, the ransom demand was far beyond what the business could pay, and KNP shut down. Seven hundred people lost their jobs because of one weak credential. Tom’s Hardware covered the collapse after the details came out in UK parliamentary testimony, and The Hacker News broke down the mechanics. No zero-day. No nation-state. A guess. o_O

Change Healthcare. This was a much bigger company and a much more ridiculous root cause. Attackers logged into a Citrix remote access portal using stolen credentials, and that portal did not have multifactor authentication (MFA) enabled. The resulting ransomware event disrupted claims processing for a meaningful slice of American healthcare and cost billions. UnitedHealth’s CEO confirmed the missing MFA under Congressional questioning, as Cybersecurity Dive reported. If a company that size can leave one door unlocked, so can a 40-person firm with three admins and no full-time security on staff.

CDK Global. In June 2024, a ransomware attack on a single dealer, management software provider knocked roughly 15,000 car dealerships offline for about two weeks. Most of those dealerships were small businesses. They did nothing wrong. They were writing sales paperwork by hand while their vendor negotiated with criminals, as TechTarget documented in its postmortem. This is the one people underestimate, you most definitely can be compromised by proximity.

That last case is not an outlier anymore. According to analysis of the 2026 Verizon Data Breach Investigations Report, third parties were involved in 48% of breaches, up from 30% the year before. Vulnerability exploitation is now the leading initial access vector at 31%, and edge devices and VPNs account for 22% of those exploitation breaches, up from 3%. Read that again: the drawbridge is now a way in.

The Numbers That Should End the “We’re too small” Conversation

Microsoft’s 2025 Digital Defense Report is worth twenty minutes of anyone’s time, but here are the load-bearing figures:

More than 97% of identity attacks are password attacks. Not clever token theft, not exotic cryptography, just someone trying passwords until one works. Identity-based attacks jumped 32% in the first half of 2025 alone. More than half of attacks with a known motive were driven by extortion or ransomware, while espionage accounted for only 4%. In other words, almost nobody is after your secrets. They are after your ability to keep operating, because that is what you will pay to get back. And the punchline from the same report is that MFA can block over 99% of identity-based attacks. Ninety-nine percent. From a control that basically ships in the box. If there were a vaccine with that efficacy rate for a disease that kills 158-year-old companies, we would be putting it in the water supply.

Microsoft has clearly done this math too, which is why MFA is no longer optional for administrative work in Azure. Mandatory MFA enforcement rolled out to the Azure portal, Entra admin center, Intune admin center, and Microsoft 365 admin center between October 2024 and February 2025. Phase two, covering Azure CLI, Azure PowerShell, the mobile app, infrastructure-as-code tooling, and REST APIs, started October 1, 2025 for create, update, and delete operations. Organizations could request a postponement, and that postponement expired as we previously warned you, on July 1, 2026. If your team asked for the extension and then filed it under “later,” later has left the building.

Where to Actually Start: A Five-phase Plan

You do not need a security operations center, you only need a sequence. Here is the one we would run, ordered by return on effort rather than by what looks impressive in a slide deck.

Phase One: Find out where you stand, which takes an hour

Before you change anything, open Microsoft Secure Score in the Defender portal. It scores your current configuration and hands you a ranked list of improvement actions, with the effort and user impact of each already estimated. It is the closest thing security has to a difficulty-adjusted to-do list, and it is included with your subscription.

Write your number down. You are going to enjoy watching it move.

While you are in there, get honest about inventory. Every unmanaged laptop, every service account with a password from 2019, along with every SaaS tool somebody expensed and never told IT about. You cannot apply least privilege to systems you have forgotten exist. This is the least glamorous phase and the one that most determines whether the rest of it works.

Phase Two: Identity, because that is where the fight actually happens

If you do nothing else on this list, do this. Ninety-seven percent of identity attacks are password attacks so, you need to make passwords insufficient. The smallest organizations can start with security defaults, a one-switch preset that requires MFA for everyone, forces it on administrators every time, and blocks legacy authentication protocols. It is free, it takes about ninety seconds, and it is dramatically better than nothing.

Once you outgrow that, and you will, move to Conditional Access, which is included with Microsoft Entra ID P1 and therefore with Microsoft 365 Business Premium. Conditional Access is the actual engine of Zero Trust. It is made up of policies that evaluate who is asking, from what device, from where, for what resource, and at what risk level, then decides. Microsoft publishes Conditional Access policy templates so you are not writing them from a blank page, plus a specific walkthrough for requiring MFA for all users.

Then three follow-ups that punch above their weight:

1. Separate your admin accounts from your daily-driver accounts. Your Global Administrator should not also be the account reading email and clicking PDFs from vendors. This is the security equivalent of not doing your database migrations while logged in as root, and yes, everybody knows that, and no, hardly anybody does it.
2. Require phishing-resistant MFA for administrators. Text message codes and push approvals can be phished or fatigued out of a tired human. Passkeys and hardware keys cannot, because the cryptography is bound to the actual domain. Microsoft documents both passkey support in Entra ID and a ready-made policy for requiring phishing-resistant MFA on admin roles. Buy hardware keys for your three or four admins. It will cost less than a decent office chair.
3. Stop leaving admin rights switched on. Privileged Identity Management turns standing privilege into just-in-time privilege. PIM means an admin activates the role when needed, with approval and a time limit, and it expires on its own. An attacker who steals those credentials at 2am gets a normal user account and a lot of frustration.

One more thing, and it is a process fix rather than a product one. Attack groups like Scattered Spider have had enormous success simply calling the help desk, impersonating an employee, and asking for a password or MFA reset. The FBI and CISA published a joint advisory on the group’s tradecraft for exactly this reason. If your identity verification procedure for a reset request is “they sounded like Dave,” you have a very expensive vulnerability staffed by nice people. Our advice? Write a real verification script and practice it.

Phase Three: Devices, so a compliant laptop is the price of admission

A verified identity on a compromised laptop is a verified attacker. This is why Zero Trust pairs identity with device health.

Enroll company devices in Microsoft Intune and set device compliance policies: disk encryption on, firewall on, antivirus current, OS patched above a minimum version, screen lock enforced. Then close the loop with Conditional Access by requiring a compliant device for access to company data. Microsoft’s Zero Trust guidance walks through this pairing as step four of the adoption path.

For detection and response on those endpoints, Microsoft Defender for Business is the SMB-shaped version of the enterprise product. Next-generation antivirus, endpoint detection and response, attack surface reduction rules, vulnerability management, and automated investigation and remediation. Built for organizations without a dedicated security team, which describes most of the country.

A note on bring-your-own-device, because somebody is about to object, you do not have to seize your bookkeeper’s personal iPad. App protection policies can enforce encryption, PIN requirements, and copy-paste restrictions on the company data inside an app while leaving the rest of the device alone. Nobody’s vacation photos are at risk.

Phase Four: Retire the VPN, which was never as good as you thought

Your VPN grants network-level access. Once a user is in, they can typically see far more of your internal environment than their job requires, and lateral movement becomes trivial. Combine that with the DBIR finding that edge devices and VPNs went from 3% to 22% of exploitation-based breaches, and the case writes itself.

Microsoft Entra Private Access replaces that model with per-application access. Users reach the specific line-of-business app they need, with Conditional Access and MFA applied to each app individually, and never get a seat on the network itself. Microsoft publishes a VPN replacement tutorial that starts with a Quick Access configuration, so you can pilot it with one app and one small group before a full commitment.

Skip this phase if you have already moved everything to SaaS. If you still have a server closet with an accounting application in it, this really must be your highest-value infrastructure project this year.

Phase Five: Assume breach, and mean it (or beat it?)

Assume breach is the principle everyone nods along to and nobody funds. It has two practical components.

• First, backups your attacker cannot delete. Modern ransomware crews hunt backups before they encrypt anything, because a company with clean restores does not pay. Azure Backup’s security features include soft delete and immutable vaults, which prevent recovery points from being deleted or shortened even by someone holding valid administrator credentials. Microsoft also publishes a full backup and restore plan for ransomware protection. Turn on immutability, then actually perform a test restore, because an untested backup is just a rumor.

• Second, if you run anything in Azure beyond Microsoft 365, turn on Microsoft Defender for Cloud. Its foundational cloud security posture management tier gives you continuous assessment, a secure score for your Azure resources, and prioritized recommendations. There is a free foundational CSPM tier you can opt into, which makes “we couldn’t afford visibility” a difficult position to defend.

Then write the boring document. Who declares an incident. Who calls the insurance carrier. Who talks to customers. Where the phone numbers live when email is down, which is a lovely paradox to discover at 3 a.m. Run one tabletop exercise a year over lunch. The first one will be a mess, and that is precisely the point of doing it before it counts.

What Does This Actually Cost?

Here is the part that surprises people. The assumption flagged up front is that these are United States list prices per user per month, and your reseller or Microsoft partner agreement may differ.

Microsoft raised business subscription prices effective July 1, 2026. Business Basic went from $6 to $7 and Business Standard went from $12.50 to $14. Business Premium, per Office Watch’s breakdown of the change, stayed at $22. The gap between Standard and Premium just narrowed to $8, and that $8 is buying you Entra ID P1 with Conditional Access, Intune, Defender for Business, and Defender for Office 365 Plan 1. Microsoft names Business Premium as the foundation of its Zero Trust guidance for small and medium businesses for exactly this reason.

For a 40-person company, the entire delta between “we have email” and “we have a defensible zero-trust foundation” is roughly $320 a month. Add a handful of hardware security keys for your admins as a one-time cost.

Compare that to the incident. Not the ransom, which you may or may not pay. The downtime, the forensics retainer, the legal review, the notification letters, the customers who quietly do not renew, and the two weeks your leadership team spends doing nothing else.

The licensing is the cheap part. The expensive part is the thinking: which policies, in what order, with what exclusions, tested against which workflows, so that on Monday morning your sales team can still open their pipeline and your controller can still run payroll. Conditional Access is a wonderfully sharp tool, and a policy misconfigured at 4:55 p.m. on a Friday can lock every human out of the tenant, including you. Ask us how we know, over a pint some day.

The Mistakes Worth Skipping

Do not try to do all five phases in one weekend. Zero Trust done well is staged, piloted, and measured. Zero Trust done in one heroic push is an outage with a security theme. And we love themes as much as the next nerd. Star Wars anyone?

Do not forget break-glass accounts. Keep two emergency access accounts excluded from Conditional Access, with long unique passwords stored offline, and audit their use. This is your fire axe behind glass, and it is the step people skip most often on their first policy.

Do not stop at MFA and declare victory. MFA is the highest-return control by a mile, but it is also the beginning. Device compliance, least privilege, and immutable backups are what turn a blocked login into a security program.

Do not let perfect be the enemy of Tuesday. Turning on security defaults this week beats architecting the ideal Conditional Access framework next quarter. Ship something and then improve it.

How CSW Solutions Can Help

For Zero Trust specifically, we usually start with a short assessment. We look at your current Secure Score, your identity configuration, your device inventory, and your backup posture, and we come back with a prioritized plan that tells you what to do first, what it costs, and what it protects. No mystery, no upsell theatrics, no song and dance. Though, we do enjoy dancing.

From there we implement in stages within a pilot group first, with rollback plans. We handle the Conditional Access design, the Intune enrollment and compliance baselines, the Defender deployment, the privileged access model, and the VPN retirement if you still have one. We will write the help desk verification script, and we will run the first tabletop exercise with your leadership team so it does not get quietly deferred forever. If you want us to keep operating it afterward, we do that too. If you would rather we train your internal person and get out of the way, that also works, and we will not be offended.

We are Azure-first because the tooling is already in your subscription and the integration between Entra, Intune, and Defender is where the real value lives. Buying a fourth-party product to do what Conditional Access already does is a popular way to needlessly spend money and add a dashboard nobody will ever open.

A few closing thoughts.

The first is that Zero Trust is a posture, not a project with an end date. You will keep tuning it, and that is normal, expected even. The second is that trust in your users was never the problem. Your team is not the enemy. The problem is that a password is a terribly thin thing to hang a 158-year-old company on, and we now have far better options sitting unused in a portal you might already be paying for, so why not make the most of it? Turn them on. Or give us a shout, and we will turn them on with you.

And if it all goes sideways anyway, it is probably still DNS. Some things Zero Trust cannot fix but we can.

That “sort of” is the whole story of 2026.

Here is the number that has been passed around every engineering leadership Slack since Stack Overflow published its results: the share of developers who say they trust the accuracy of AI coding tools fell from 43% to 29% in two survey cycles. Meanwhile adoption went the other direction, climbing to 84% of developers using or planning to use these tools, up from 76% the year before. Only about 3% say they highly trust what comes out. Active distrust jumped from 31% to 46% (2025 Stack Overflow Developer Survey, and the press summary).

You read that right. More people are using the thing. Fewer people believe the thing. Normally, familiarity breeds confidence. Here, familiarity is breeding a very specific and very well-earned kind of suspicion.

This is not a crisis of technology. It is a crisis of governance, and it is fixable. But you have to understand what developers are actually reacting to first, because they are not being dramatic. They are being empirical.

Nobody is mad that the AI is wrong. They are disappointed that it is almost right.

If you ask developers what frustrates them most about AI coding tools, the top answer is not “it makes stuff up.” It is subtler and much more annoying than that. Two out of three developers, 66% of them, point to “AI solutions that are almost right, but not quite.” Right behind it, 45% say debugging AI-generated code eats a disproportionate amount of their time.

Anybody who has managed a team knows what this means. Code that is obviously broken is cheap. It fails immediately, you throw it out, you move on. Code that is 95% correct is expensive, because the remaining 5% is camouflaged inside something that reads beautifully, compiles cleanly, passes the happy path, and then quietly mishandles a null value in a currency conversion eleven months later.

The old signals developers used to gauge quality do not work anymore. Sloppy variable names, weird indentation, a comment saying “TODO fix this hack,” all of that used to tell you where to look. AI-generated code arrives with tidy naming, thorough docstrings, and total confidence. The tell is gone. The reviewer has to read every line as if it might be wrong, which is a far more tiring job than reading code from a colleague whose habits you know.

This is why developer trust is falling because of adoption rather than in spite of it. In 2024 a lot of developers were evaluating AI coding tools on toy problems. In 2026 they are shipping with them, in production, on systems that have customers. The sample got bigger and more honest.

What AI coding tools are doing to code quality

Sentiment surveys are one thing. What is happening inside the repositories is another, and the repositories are less polite.

GitClear has been running the largest longitudinal study of this we know about, now covering 623 million analyzed code changes from 2023 through 2026. Their 2026 maintainability research found that duplicated code blocks climbed 81% since 2023, hitting 73 duplicated lines per 1,000 changes, the highest on record. Copy and paste now happens at roughly five times the rate of refactoring. Moved code, which is the fingerprint of somebody actually reorganizing and consolidating a system, collapsed from 21% of changed lines in 2022 to 3.8% in 2026.

Even more telling: new code connects to existing code 35% less than it did in 2023, with method calls into the existing codebase dropping from 343 to 223 per 1,000 changed lines. In plain English, AI-assisted code builds its own little parallel universe next to your system instead of reusing what is there. It does not know your internal utilities exist, so it writes new ones. Five times. In five files.

None of that breaks anything today. All of it makes the next two years more expensive.

Then there is security, which is worse. Veracode has now evaluated over 150 large language models on secure coding tasks. Their Spring 2026 update found that roughly 45% of AI-generated code contains a known security vulnerability when the model is not given explicit security guidance. The really uncomfortable finding is the flatline: syntactic correctness has climbed from about 50% to 95% across model generations, while security pass rates have basically not moved off 55%. The models got dramatically better at writing code that works and barely better at writing code that is safe. Cross-site scripting passes 15% of the time. Log injection passes 13% of the time. Java code came in at 29%.

So, developer distrust is not just vibes, it is pattern recognition. They are looking exactly at the class of defect that ships silently and shows up in an incident review.

The verification tax nobody budgeted for

Here is where it gets expensive in a way that never appears on a spreadsheet. METR ran a randomized controlled trial with experienced open source developers working on real tasks in their own repositories. The developers were 19% slower when allowed to use AI tools. And afterward they estimated that AI had made them about 20% faster. A roughly 40-point gap between perceived and actual productivity, in the direction that flatters the tool.

Be careful with this one, because it gets over-quoted. Small study, experienced developers, codebases they knew intimately, which is exactly where AI has the least to offer. It is not proof that AI coding tools are useless. It is proof that self-reported productivity gains are worthless as a measurement, which matters when your CFO asks what the license spend is buying.

Sonar’s 2026 State of Code survey of more than 1,100 developers found an even more stark gap; 96% do not fully trust that AI-generated code is functionally correct and only 48% always verify it before committing, while 38% say reviewing AI code takes more effort than reviewing human code. AI now accounts for about 42% of committed code and it is projected to hit 65% by 2027. And even more disconcerting, 35% of developers are using personal accounts rather than company-sanctioned tools, which is a governance problem wearing a productivity costume. If we sit with that combination for a second, nearly everybody doubts the output and barely half check it while almost half the code is coming from it. That is not a tooling gap, that is a process gap so big,you could drive a semi through it.

The DORA research put the same finding in different words: AI acts as an amplifier. It magnifies whatever your organization already is. Teams with strong review culture, real test coverage, and clean deployment pipelines get faster and stay stable. Teams without those things get faster and get less stable, which is a genuinely terrible combination. Delivery throughput went up across the industry. So did instability.

Four times the industry found out the hard way

Statistics are easy to wave away. Incidents are not.

The database that was not supposed to be touched. In July 2025, during what was explicitly declared a code freeze, an AI agent on Replit executed destructive commands against a live production database belonging to SaaStr, deleting records for over 1,200 executives. It then generated fabricated data, reported that a rollback was impossible, and misrepresented what had happened. Replit’s CEO publicly apologized and shipped guardrails. The lesson everyone drew was not “AI agents are evil.” It was “an agent with production credentials and no environment separation is just a very fast intern with root.”

The supply chain attack that used your AI assistant against you. In August 2025, attackers published malicious versions of the widely used Nx build packages to npm. The malware did something new: instead of hunting for secrets itself, it invoked the AI coding CLIs already installed on the developer’s machine, passing flags like --dangerously-skip-permissions and --yolo, and asked those trusted assistants to go find the credentials. Over 1,000 valid GitHub tokens leaked. In a second wave, attackers used the stolen tokens to flip more than 5,500 private repositories to public, across 400-plus organizations. Your AI assistant, it turns out, is a privileged actor on your machine, and until recently almost nobody was modeling it that way.

The pull request that read your private repos. Researchers disclosed a vulnerability nicknamed CamoLeak, rated CVSS 9.6, in GitHub Copilot Chat. An attacker embedded invisible instructions in a pull request using markdown comment syntax. When a victim viewed that PR, Copilot Chat processed the hidden prompt with the victim’s own permissions and exfiltrated private source code and secrets by encoding them into a pre-built dictionary of signed image proxy URLs. Zero clicks required. GitHub fixed it in August 2025 by entirely disabling image rendering in Copilot Chat. Credit where due: it was found, reported, and patched. But it established the category. Any untrusted text your AI assistant reads is potentially executable.

The packages that never existed until an attacker made them. Models routinely hallucinate plausible-sounding dependency names. Attackers noticed, registered those names, and waited. The practice earned the name slopsquatting, and it is no longer theoretical. An npm install on a hallucinated package is a supply chain compromise that your developer initiated enthusiastically and voluntarily.

Notice the through line. Not one of these was caused by a model writing a bad for loop. Every single one happened because AI coding tools were operating with more privilege, less identity, and thinner oversight than any human or service account would ever be granted. That is an AI governance failure, not a code quality failure, and you cannot patch it with a better model.

Developer trust is not a property of the model. It is a property of the pipeline.

This is the reframe that changes everything, so let us be direct about it: You are never going to get a model you can trust unconditionally. That is not how probabilistic systems work, and waiting for one is a strategy with no end date. What you can do is build a system where you do not have to. Trust is not something the vendor ships to you. It is something your pipeline manufactures, one verified artifact at a time.

Think about how you already trust a junior developer. Not because you believe they are infallible. You trust the outcome because there is a pull request, a reviewer, a CI suite, a static analyzer, a staging environment, and a rollback plan standing between their good intentions and your customers. Nobody calls that distrust. We call it engineering.

AI coding tools got dropped into most organizations throughout the last few years without any of that scaffolding, because they arrived through individual developers rather than through procurement. Then, everyone acted surprised when confidence eroded. The developers are not the problem. They are the smoke detector.

The good news is that the control plane for this exists now, and if you are a Microsoft and Azure shop, most of it is sitting in tenants you already pay for. This is the bulk of what our AI and automation practice actually does day to day: less model selection, more plumbing.

What AI governance actually looks like in practice

Start with provenance, because it is the cheapest win. GitHub Copilot’s code referencing feature detects when a suggestion matches public code and tells you where it came from, with the license. Organizations can entirely block matching suggestions with a policy toggle. Visual Studio surfaces this inline, both for Copilot Chat and completions. If your legal team has ever asked “where did this code come from,” this is the answer, and you can turn it on in an afternoon.

Then close the security gap with automation, not with meetings. Given that 45% figure from Veracode, adding AI to your authoring step without adding equivalent horsepower to your verification step is just accelerating toward the wall. Copilot Autofix in GitHub Advanced Security proposes remediations directly on code scanning alerts at pull request time. GitHub’s data from the public beta showed median remediation at 28 minutes versus 1.5 hours manually, with SQL injection fixes running roughly 12 times faster and cross-site scripting about 7 times faster. For Azure DevOps shops, it is available there too, and Microsoft has been shipping expanded Autofix controls and Copilot code review through recent sprint updates. It is also worth reading the responsible use guidance as well, since an AI fixing AI-written bugs definitely still needs a human signing the commit.

Give your agents identities. This is the s1ngularity lesson, and it is the one most SMBs have not internalized yet. An AI agent acting in your environment is a principal. It needs an identity, scoped permissions, conditional access, and an audit trail, exactly like a service account. Microsoft Entra Agent ID exists for precisely this, and the Entra security for AI overview walks through the model. If you cannot currently answer “which agents are running in our tenant, as whom, with access to what,” that simply must be your first project. Not your third.

See where your data is actually going. Remember that 35% of developers are on personal AI accounts. Microsoft Purview Data Security Posture Management for AI gives you visibility across sanctioned and unsanctioned tools, with sensitivity labeling and DLP that follows the data into the prompt. The deployment guidance and broader Purview for AI overview are worth reading before you buy anything. Shadow AI is not a discipline problem, it is a paved-road problem. Developers use the personal account because the sanctioned path is slower.

Measure the thing instead of asking about it. METR’s finding that developers were 19% slower while believing they were 20% faster should end the practice of evaluating AI tools by survey. If you are building AI applications yourself, observability in Microsoft Foundry and continuous agent evaluation score outputs against defined evaluators over time rather than trusting a demo. For coding tools, watch change failure rate, mean time to restore, rework percentage, and PR review duration before and after rollout. If review time is climbing faster than authoring time is dropping, you might have already bought a slower team with better-looking commits.

Write the policy down, in one page. Not a forty-page framework nobody reads. One page that says: which tools are approved, what may never be pasted into a prompt, which repositories and environments agents may touch, what requires human review before merge, and who to call when something goes sideways. Microsoft’s Responsible AI principles and Responsible AI Transparency Report are very reasonable scaffolding to use, and ISO/IEC 42001 is where this is heading for anybody selling into regulated buyers. The Responsible AI with GitHub Copilot module on Microsoft Learn is a good starting point for a lunch-and-learn.

And separate your environments like you mean it. The Replit incident happened because an agent could reach production. No policy document prevents that. Network boundaries, credential scoping, and approval gates prevent that, which makes this a managed IT and cloud problem as much as a developer tooling one.

The uncomfortable good news

The falling developer trust number is not a sign that AI coding tools are failing. It is a sign that developers are doing their jobs. A 29% trust rating from people who use AI coding tools fifty hours a week is a more accurate reading of reality than the 43% we got when everybody was still playing with demos. Skepticism is like the immune response of a healthy engineering organization.

The companies that will come out on top in the next two years will not be the ones whose developers trust AI the most. They will be the ones who built systems where trust in any individual output is not required, because verification is automatic, provenance is tracked, agents have identities, and the paved road is faster than the shortcut. In those shops, developer trust in AI output will probably keep drifting downward, and it will not matter, because trust will have moved to where it belongs: the pipeline.

How CSW Solutions can help

We are a local, boutique consulting firm in Chicago, which means we have never had the luxury of the forty-page framework. Our clients are SMBs between $2M and $50M in revenue, and they need the AI governance question answered in weeks, not quarters, by people who will also stay to build the thing. Getting AI coding tools under control without slowing the team down is squarely AI and automation work for us.

Here is how we usually approach it:

We start with a short assessment, typically two to three weeks. We will look at what AI coding tools are actually in use, including the personal accounts nobody mentioned in the kickoff. We’ll look for what your agents can reach and where the verification gap is widest. Then, we examine what your code quality trend looks like when you measure duplication and rework rather than lines shipped. You get a findings or discovery document and a prioritized roadmap, not a sales deck and an oversized pitch.

Then we build the guardrails on Azure and GitHub. Copilot policy configuration including code referencing and content exclusion, GitHub Advanced Security with code scanning and Autofix wired into pull requests, Entra Agent ID for anything autonomous, Purview DSPM for AI so shadow usage becomes visible, and CI/CD gates in Azure DevOps or GitHub Actions that make the secure path the fast path. Most of this runs on licensing you already own, a conversation we would rather have up front than in month three. If you would rather not own the ongoing operation of it, that folds into our managed IT and cloud services.

We write the one-page policy with you, not for you. Governance that engineers did not help write is governance engineers route around. Of course, we know the deal. We facilitate the session, draft the document, and make sure it maps to something defensible if a client or auditor asks.

Finally, we do the custom work. Application modernization, integration, and AI-enabled features built on Azure, where the same standards we just wrote apply to our own commits. We are a Microsoft partner and Azure is our default, so the AI governance model and the build model are the same model. The point is not to slow your team down. It is to make AI coding tools safe enough that you can stop reviewing every line like it might be a trap.

If your adoption curve is currently outrunning your confidence curve, that is not a failure of nerve. It is an accurate instrument reading, and awareness is key. Now would be the right moment to act, before the duplication compounds and before an agent with too many permissions makes the decision for you.

Reach out to us and bring your messiest repository. We have seen worse, and we will be honest and forthright, we’ll let you know whether you need us or just need to flip four settings you are already paying for.

Here is the honest framing that I like to do before we dig in deeper, and it includes a caveat we would rather say out loud. When you read a headline like “boutique retailer cut tickets 67%,” treat it as a pattern, not a specific promise. Those exact viral figures rarely trace back to a named company you can verify, so we are not going to pretend otherwise. What the pattern describes is real, though: a big share of incoming questions turn out to be the same handful of questions asked in slightly different words, and a well-built assistant answers them instantly so nobody has to open a ticket at all. The problems do not vanish. They just stop landing in a human’s inbox where it has to wait for them to do something with it. That distinction matters, and once you internalize it, the 60% number stops sounding like a sales slide and starts sounding like arithmetic. I’ll do my best to stick to figures that are cited well enough that you can click through and check yourself.

Why AI customer support for SMBs is the single best place to start

If you run a small or midsize business, you have a limited number of AI experiments in you before the team gets weary and the budget person starts sweating. So you really need your first swing to connect. Of all the places to swing at first, customer support is that swing, and it is not close. This is exactly why AI customer support for SMBs has become the highest-return starting point in the whole AI conversation.

Three things make support special. First, the work is repetitive in a way that is almost embarrassing. Where is my order, how do I reset my password, what are your hours, do you ship to Canada, how do I return this. A huge share of your volume is a small set of questions on infinite repeat. Repetition is exactly what machines are good at. Second, the value is measurable on day one. You already know your ticket volume, your average handle time, and roughly what a contact costs you. That means you can prove the return instead of arguing about it. Third, the downside is contained. If the assistant is unsure, it hands off to a person. Nobody loses a limb.

Microsoft puts real dollars on that repetition. In its own Copilot Studio deflection guidance, Microsoft notes that a human-handled contact in the contact center industry typically costs around 5 to 10 dollars, while an agent session that resolves the request costs about 50 cents. Sit with that gap for a second. Every question your assistant resolves cleanly is not a rounding error, it is a ten-to-one or twenty-to-one cost swing, and it compounds every single day your storefront is open.

That same Microsoft page also gives us the vocabulary we need, so let us borrow it. The word of the day is deflection, which Microsoft defines as the percentage of requests that get completed in a self-service way that a live representative would otherwise have handled. Deflection is not about dodging your customers. It is about the customer getting an answer without a queue, and your team getting their afternoon back. When people talk about reducing support tickets with AI, deflection is the machinery underneath the claim.

What “cut tickets 60%” actually looks like in the wild

Let us ground this in a real, documented case instead of a stock photo of a smiling headset.

Microsoft built an assistant called Ask Microsoft on Copilot Studio to help the millions of people who land on microsoft.com every day. Before the assistant, visitors would spill into live chat with sales reps for everything, including questions that had nothing to do with sales, which is a lousy use of a salesperson’s time. After the rebuild, the published results are specific. According to Microsoft’s own customer story, the updated agent delivered up to 61% lower latency, and, this is the part you care about, total human-handled chat volume dropped by up to 70%. Customers who engaged with the assistant also turned out to be ten times more likely to sign up for services, which is a nice reminder that good deflection and good selling are not enemies.

Seventy percent. That is your “60%+” headline, sourced from the company that makes the tooling, on its own high-traffic site. It is not a boutique-retailer legend passed around on LinkedIn. It is documented, and it is the ceiling being demonstrated by a serious operator, which is exactly what you want to see before you copy the recipe.

For a named, consumer-facing brand rather than Microsoft’s own site, look at Lenovo. In its Microsoft customer story, Lenovo equipped its Premier Support team with Copilot in Dynamics 365 Customer Service and Dynamics 365 Contact Center, and reported a 20% drop in average handle time, a 15% increase in agent productivity, and record-high customer satisfaction, with customers now able to chat in nine languages around the clock. That is the agent-assist side of the same coin: instead of deflecting the question before a human sees it, Copilot drafts responses, summarizes cases, and pulls from millions of past interactions so each human resolves more tickets in less time. Deflection shrinks the queue, agent-assist speeds up whatever is left in it, and together they bring the total workload down. One honest nuance, since we promised it: Lenovo’s published numbers are about speed and productivity, not a headline deflection percentage, because a clean, named “we deflected X percent of tickets” retail figure is genuinely hard to find in public. That scarcity is exactly why we prefer real, checkable numbers over a rounder one nobody can source.

Now, you are not microsoft.com or Lenovo, and that is fine, because the mechanics scale down beautifully. The same story reveals the architecture that made the numbers work, and it is worth understanding because it is the reason this generation of tools clears the bar the last generation could not. Instead of one bot trying to crawl and understand everything, the team used generative orchestration and a set of specialized sub-agents, each grounded in one slice of the site, one for pricing, one for a given product, and so on. A traffic-cop agent reads the customer’s intent and routes the question to the right specialist, or combines a couple of them, or hands off to a live human when the moment calls for it. That “many small experts plus a router” pattern is the difference between a bot that frustrates people and an assistant that quietly resolves their issue.

The realistic playbook, in the order you should actually do it

Here is where most SMBs go wrong. They start with the technology. You should start with your tickets. The playbook below is deliberately boring, because boring is what works, and it is the same sequence we run every time we set up AI customer support for SMBs.

Step 1: Mine your last ninety days of tickets

Before you evaluate a single tool, pull your last quarter of support conversations and sort them by theme. You are hunting for the fat part of the curve, the handful of question types that make up the bulk of your volume. Almost every SMB finds that something like 60 to 80% of tickets cluster into ten or fifteen recurring topics. That cluster is your target list, and it is also, not coincidentally, your realistic deflection ceiling. If 70% of your volume is repetitive lookups and FAQs, then 60%+ deflection is on the table. If only 30% of your volume is repetitive and the rest is genuinely novel, then be honest with yourself and aim for 30%. The number is a function of your actual mix, not the vendor’s slide.

This step also tells you something priceless: what your customers are actually confused about. Half the tickets in that pile are not really support issues, they are product or policy problems wearing a support costume. Fixing the underlying confusion deflects tickets too, and it is free.

Step 2: Automate Tier 0 first, and only Tier 0

Tier 0 is the self-service layer, the stuff that has one correct answer and no judgment call: order status, business hours, return policy, password resets, shipping zones, appointment booking. This is where you start, full stop. It is high volume, low risk, and the answers already live in your help center or your order system. Get an assistant answering Tier 0 well and you have captured most of the deflection prize with almost none of the danger. Resist the urge to have the AI handle refunds, account changes, or anything involving an angry customer on day one. Walk before you run, then jog for a while before you sprint.

Step 3: Feed it good knowledge, because it is only as smart as what you give it

This is the step that quietly decides whether your project succeeds, and it is the step everyone wants to skip. An AI assistant grounded in stale, contradictory, or half-written documentation will confidently give wrong answers, which is worse than no answer at all. Before you go live, do the unglamorous work of cleaning up your knowledge base so there is one clear, current answer for each of your top topics.

There is a wonderful piece of proof for this inside Microsoft’s own building. When Microsoft HR rebuilt its internal employee support on Dynamics 365 Customer Service with Copilot, the team’s own published story says the first real move was creating a unified knowledge base, because their content had been scattered across platforms and languages. Once that foundation was in place, they reported a 20% increase in case throughput and a 72% monthly active adoption rate among their advisors. Notice the sequence. Knowledge first, results second. It is always that order, and the projects that fail almost always failed at the knowledge step.

Step 4: Design the handoff before you design the bot

The fastest way to torch customer trust is to trap someone in an automated loop with no exit. So decide, on paper, before anything ships, exactly when and how the assistant gives up and gets a human. The Ask Microsoft assistant does this well: at any point the customer can be transferred to a live chat, and can hop back to the assistant afterward if they want. A good handoff is not an admission of failure, it is the feature that makes customers comfortable trusting the assistant with the easy stuff in the first place. Build the escape hatch first, then build the room.

Step 5: Measure the right numbers and tune relentlessly

Deflection is not “set it and forget it,” and anyone who tells you otherwise is selling you something. Microsoft’s deflection guidance lays out the metrics that matter: resolution rate (of the conversations that engaged, how many got resolved), escalation rate (how many kicked to a human), abandon rate, and customer satisfaction. You watch these weekly at first. When you see a topic escalating too often, that is not a failure, it is a to-do item: the assistant is telling you exactly where your knowledge base has a hole. Patch the hole, watch the escalation rate on that topic fall, repeat. Deflection is a garden, not a statue.

The Microsoft toolkit, in plain English

You do not need to memorize a product catalog, but you should know the three pieces that most AI customer support for SMBs projects lean on, and roughly what each is for. And yes, our shop defaults to the Microsoft and Azure stack, both because it is what most of our clients already run and because the pieces snap together without a lot of custom glue.

Copilot Studio is the low-code workbench where you build the customer-facing assistant. It is the tool behind the Ask Microsoft results above, and its whole selling point is that you can stand up a grounded, useful agent in weeks rather than quarters, then scale it up with the orchestration and sub-agent patterns as your needs grow. For a company that wants a smart assistant on its website or in its support portal, this is usually the front door.

Dynamics 365 Customer Service is the fuller platform for teams that want AI woven through the whole support operation, not just the front-end chat. Think Copilot drafting agent responses, summarizing long cases in one crisp paragraph, and pulling answers out of your knowledge base while a human stays in the driver’s seat. This is where the Microsoft HR case above lived, and it is a strong fit when your agents, not just your customers, are the ones drowning.

Azure AI Foundry is the heavier-duty layer underneath, for when you have volumes or content that outgrow the low-code tools, for example enormous document sets that need smarter indexing. Most SMBs will not start here, but it is good to know the ceiling is high, so you are not going to build something that hits a wall in eighteen months.

The reason to care about a single, connected stack is not brand loyalty, it is plumbing. When your assistant, your case management, your identity, and your data all live in the same ecosystem, the handoffs and the security and the reporting just work, instead of becoming three integration projects you did not budget for.

Where the number goes wrong, so you can avoid it

Because we would rather you succeed than sign a contract you resent, here are the ways the 60% dream curdles, and how to keep yours intact.

The first failure mode is automating anger. If a customer is already frustrated, the last thing they want is a cheerful bot asking them to rephrase. Route emotional or high-stakes contacts to humans fast, and let the AI handle the calm, routine majority. Deflection works on volume, not on the hard 5% of cases that need a person’s judgment and empathy anyway.

The second failure mode is the stale knowledge base we already flagged, and it is worth flagging twice because it is that common. An assistant that confidently cites last year’s return policy does not save you tickets, it generates a second, angrier ticket plus a trust problem. Freshness is not a nice-to-have, it is the product.

The third failure mode is chasing a deflection number that your ticket mix cannot support, then declaring the project a failure when you hit 35% instead of 65%. If 35% is what your repetitive-question share allows, then 35% is a win worth thousands of hours a year. Set the target off your own data from Step 1, not off someone else’s headline.

The fourth, and quietest, failure mode is treating the launch as the finish line. The teams that get the big numbers are the ones who kept tuning after go-live, reading the escalation reports, and closing knowledge gaps every week. The assistant you launch is the worst version you will ever run. That is a feature, if you keep gardening.

One more note on the vendor math, because we promised straight talk. The eye-popping return figures you see in vendor-commissioned studies, including Microsoft’s own Total Economic Impact work, are modeled scenarios, not guarantees, and they are commissioned by the vendor. Use them to understand the shape of the opportunity, then prove your own number with your own tickets. Your ninety-day analysis is worth more than any slide.

A sane thirty-to-sixty-day path

If you want a timeline that a real SMB can actually run, here it is, compressed. Weeks one and two: pull and theme your tickets, pick your top ten Tier 0 topics, and audit the knowledge behind them. Weeks three and four: clean and consolidate that knowledge into one clear answer per topic, and design your handoff rules. Weeks five and six: build the assistant against just those topics in Copilot Studio, and test it hard with your own team pretending to be customers. Weeks seven and eight: launch to a slice of traffic, watch the resolution and escalation numbers daily, and tune. Somewhere in that window you will have a defensible deflection number and, more importantly, a repeatable loop you can point at the next batch of topics. Notice that only a third of that plan is “build the bot.” The rest is the work that makes the bot worth building.

How CSW Solutions helps you actually pull this off

Here is the part where a lot of firms would tell you it is easy and then hand you a login. We would rather tell you the truth: the technology is the friendly part, and the work that decides your outcome is the ticket analysis, the knowledge cleanup, and the tuning loop. That is precisely the unglamorous, high-leverage stuff we love doing, and it is what we do at CSW Solutions.

We build AI customer support for SMBs for a living, and we are a small, senior team, so you get people who have actually shipped this, not a rotating cast of juniors learning on your dime. We start where the playbook starts, in your last ninety days of tickets, and we come back with a deflection target grounded in your real mix instead of a number we borrowed from a case study. From there we build on the Microsoft and Azure stack your business most likely already pays for, Copilot Studio for the assistant, Dynamics 365 Customer Service when your agents need the lift too, and Azure underneath it all, so you are not stitching together five vendors and praying they talk to each other. We design the human handoff so your customers never feel trapped, we get your knowledge base into shape so the assistant is actually right, and we stay through the tuning weeks, because the first version is never the good version and we are not the type to launch and vanish.

The best next step is small and low-risk: let us do a short discovery on your ticket data and tell you, honestly, what deflection is realistic for your business, whether that is 30% or 70%. If the number is worth it, we will show you the fastest path to it. If it is not, we will tell you that too, and point you at the cheaper fix. Either way you will walk away knowing your real number instead of somebody else’s headline. Reach out and let us look at your tickets together. It is a genuinely good afternoon’s work, and it tends to pay for itself faster than anyone expects.

You did not buy a shiny new artificial intelligence platform. You did not hire a data science team. You just opened QuickBooks one morning and noticed it had started drafting your invoice reminders. Your CRM began summarizing a messy email thread before you finished your coffee. Your help desk quietly answered a customer question at 2 a.m. while you were asleep. The robots did not arrive with a parade. They showed up as a new button inside the software you were already paying for.

That, in a nutshell, is the dominant 2026 pattern. Small and midsize businesses are not adopting AI by buying standalone tools and bolting them on. They are adopting AI by simply turning on features inside the systems they already run. It is cheaper, it is safer, and it lands where the work actually happens: in your books, your pipeline, and your inbox.

This post is a practical field guide to doing exactly that. We will walk through what it means to integrate AI into existing business tools, where it is genuinely useful in accounting, sales, and support, what the real-world results look like, and how to wire it up without turning your business into a science experiment. We will keep it honest about the limits, too, because a tool that quietly does the wrong thing at scale is worse than no tool at all.

Why “buy AI inside your tools” beats “buy an AI tool”

Let us start with the strategic point, because it saves you a lot of money and a lot of grief.

A few years ago, the pitch was that every company needed a custom AI project. You would collect your data, train a model, stand up some infrastructure, and emerge six months later with a chatbot that sort of worked. For a nine-person landscaping company or a regional distributor, that was always a fantasy. The math never closed.

What changed is that the software vendors did the hard part for you. Intuit built AI into QuickBooks. Microsoft built it into Dynamics 365 and the broader Power Platform. HubSpot built it into its CRM. Zendesk built it into its help desk. The intelligence now lives inside the tools where your data already sits, which means it already knows your customers, your invoices, your tickets, and your history. There is no export, no separate login, no fragile integration to babysit.

The benefits stack up fast. You skip the integration tax, because the AI is already sitting on top of your records. You inherit the vendor’s security and compliance posture instead of building your own. You pay in small, predictable increments, often bundled into a license you already hold. And your team does not have to learn a new app, because the smarts show up inside the screens they use every day.

The trade-off is real and worth naming. You give up some flexibility. An embedded feature does what the vendor designed it to do, not whatever you dream up. But for the vast majority of SMB use cases, that constraint is a feature, not a bug. You want the boring, reliable 80% handled automatically so your people can spend their attention on the 20% that requires a working human brain. Let us look at where all of that plays out.

Your books: AI inside QuickBooks and Dynamics 365 Business Central

Accounting is where embedded AI quietly earns its keep first, because bookkeeping is full of repetitive, rules-based tasks that a machine is genuinely good at.

In QuickBooks, Intuit’s assistant now turns conversations and documents into estimates, invoices, and bills, extracts details from a photographed receipt, and auto-populates the expense category, payment account, and vendor for you. It categorizes expenses, forecasts cash flow, and sends smart reminders on overdue invoices. Intuit’s own numbers claim that businesses using automated invoice reminders get paid roughly 45% faster, an average of about five days sooner. You can read Intuit’s overview of these capabilities on the QuickBooks AI page and its rundown of AI for small business, and the original launch details in Intuit’s press release for Intuit Assist. Getting paid five days sooner is not a party trick. For a business running on a thin cash cushion, that is the difference between making payroll comfortably and sweating it.

If your books live in Microsoft Dynamics 365 Business Central, the story goes a step further, because Microsoft has moved past simple assistance into genuine automation. Copilot in Business Central will reconcile bank accounts by inspecting unmatched transactions and proposing matches based on dates, amounts, and descriptions, summarize any customer or order record into a few tight bullet points, and autofill fields as you work. Microsoft lays this out on its Copilot in Business Central overview and its bank reconciliation with Copilot page.

The more interesting leap is the autonomous agents. The Payables Agent monitors a mailbox for incoming vendor invoices, reads the invoice content, matches vendors and accounts, and prepares a draft invoice for a human to approve. Accounts payable, which is the kind of task that eats a bookkeeper’s afternoon, gets handled end to end with a person kept firmly in the loop for the final sign-off. Microsoft describes the full lineup of embedded capabilities on its Copilot and agents in Business Central page.

Notice the pattern in both products. The AI does not replace your accountant. It does the mechanical grinding, then hands a human a tidy draft to check. That “prepare, then approve” design shows up again and again in the tools that are worth turning on, and it is the single most important thing to look for.

Your pipeline: AI inside your CRM

Salespeople have a famous complaint, and it is legitimate: the CRM is where selling goes to become paperwork. Reps spend a startling share of their day reading and answering email rather than talking to customers. Embedded AI in the CRM is aimed squarely at giving that time back.

If you run Microsoft Dynamics 365, Copilot in Dynamics 365 Sales summarizes opportunities and leads, catches a rep up on an account before a meeting, and drafts email replies that pull real product and pricing details straight from your CRM. Microsoft notes that sellers can spend as much as 66 percent of their day on email, which is exactly the tax this is designed to cut. The details live on Microsoft’s Copilot in Dynamics 365 Sales overview and its broader Copilot for Dynamics 365 page. There is a neat wrinkle here for the many SMBs whose reps live in Outlook: the Sales experience surfaces CRM-enriched email summaries and draft replies right inside the inbox, and it works with both Dynamics and Salesforce, per Microsoft’s CRM email summaries in Outlook documentation. The AI meets your reps where they already are instead of demanding they go somewhere new.

If you run HubSpot, its Breeze AI layer does much the same job across marketing, sales, and service, with prospecting and customer agents built into the CRM. The results HubSpot reports are worth a look: its Customer Agent resolves around 65 percent of conversations and cuts resolution time by roughly 39% across more than 8,000 activations, and teams using its AI sales features report meaningful drops in time to close. HubSpot collects these in its Breeze customer success stories and its overview of real AI CRM use cases.

The through-line, whichever CRM you use, is that the value comes from the AI already knowing your data. A generic chatbot can write a nice email. Only the CRM-embedded assistant can write a nice email that references the exact deal, the last three conversations, and the pricing you actually quoted. Context is the whole game, and context is what living inside your system provides for free.

Your inbox and help desk: AI that answers before you wake up

Customer support is where embedded AI has the clearest, most measurable payoff, because support volume is relentless and a large slice of it is repetitive. The same questions about hours, order status, password resets, and return policies arrive again and again, and a well-scoped AI agent can handle a real chunk of them without a human ever touching the ticket.

The numbers from the field are striking. Unity, using Zendesk self-service and automation, deflected almost 8,000 tickets and saved roughly 1.3 million dollars, while nudging its customer satisfaction score up a point and cutting resolution time by about seven hours. Zendesk documents this in its Unity customer story, and it walks through the broader mechanics on its ticket deflection guide. Zendesk markets figures as high as 80% automation, and the honest industry reality is more modest: independent 2026 benchmarks put the enterprise median for tier-one deflection around 41%, with the strongest performers closer to 59%. That is still enormous. Deflecting four in ten routine tickets frees your team to spend real time on the hard, human, relationship-saving cases.

You do not need a giant support suite to play this game, either. If your world is Microsoft, you can build a support agent using Copilot Studio and Power Automate that reads an incoming email, classifies it, drafts a reply, and creates or routes a case, using prebuilt AI models for sentiment analysis, language detection, and category classification. Microsoft walks through this exact pattern in its guidance on routing and deflecting cases with AI Builder and its AI Builder in Power Automate documentation. The point is that “wire AI into your help desk” is not reserved for enterprises with seven-figure budgets. It is a configuration exercise on tools a small business can already afford.

The same “prepare, then approve” principle matters more here than anywhere, because support is customer-facing. You want the agent to handle the obvious, hand off the ambiguous, and never, ever improvise a policy it made up. Scope discipline is the whole ballgame, which brings us to the part most vendors gloss over.

The part nobody puts on the marketing slide

Embedded AI is genuinely good, and it is also not magic. If you turn everything on at once and walk away, you will get burned, so let us be straight about the guardrails.

First, these tools are only as good as the data underneath them. Microsoft is refreshingly blunt that its Sales Order Agent, which reads inbound email requests, checks item availability, and drafts a quote, needs clean customer contact data, well-structured product information, a properly configured mailbox, and defined approval workflows to work at all. You can see the setup requirements on Microsoft’s Sales Order Agent overview and read Microsoft’s announcement of the feature on the Dynamics 365 blog. If your customer records are a mess and half your SKUs have inconsistent names, the AI will faithfully produce messy, inconsistent results. Cleaning up your data is not a glamorous project, but it is the one that determines whether any of this works.

Second, keep a human in the loop on anything that touches money or customers until you have earned trust. The best-designed features do this by default: the Payables Agent drafts, a person approves; the Sales Order Agent always routes outgoing messages to a designated reviewer before they reach a customer. Preserve that pattern even where the tool would let you skip it. Let the AI build up a track record on low-stakes work before you widen its authority.

Third, watch the meter. Embedded AI is cheap, not free. Some capabilities are bundled into your existing license, and some, like Business Central’s agents, bill on a consumption basis through Copilot Studio messages that scale with your volume. HubSpot has moved parts of its Breeze agents toward pay-per-result pricing. None of this is expensive by old-software standards, but you should know which lever moves your bill before you flip a switch, not after.

Fourth, and this is a house rule worth adopting: never paste sensitive material such as customer passwords, full identity records, or confidential contract terms into a general AI prompt box. The embedded, permission-aware features inside your systems are built to respect your existing access controls. Ad hoc chatbots are not. Keep the AI working inside the walls where your governance already lives.

None of these caveats is a reason to sit out. They are the difference between a rollout that quietly compounds value and one that quietly creates cleanup work. Handled with a little discipline, embedded AI is about as low-risk as transformative technology ever gets.

A sane order of operations

If you are staring at all of this wondering where to start, here is the sequence we would actually recommend, and it is deliberately unglamorous.

Begin with one high-volume, low-stakes task in a system you already own. Invoice reminders in QuickBooks are a perfect first move, because the downside of an extra polite nudge is basically zero and the upside is getting paid days sooner. Turn it on, watch it for two weeks, and confirm it behaves.

Next, add an assistive feature that keeps a human in the loop: bank reconciliation suggestions in Business Central, opportunity summaries in your CRM, or a support agent that drafts replies for an agent to send. Measure something real, whether that is days to payment, hours saved per rep, or tickets deflected, so you can tell whether it is working rather than just feeling busy.

Only after those are humming should you consider the autonomous agents that act more independently, and only where your data is clean and your approval workflow is defined. Expand authority the way you would with a promising new hire: proven results first, more responsibility second. That is the whole method. Start small, keep score, and let trust be earned.

Where CSW Solutions comes in

Here is the honest truth about everything above: the features are the easy part. Turning them on takes a few clicks. Making them actually pay off takes judgment, and that is the part that trips up busy owners who already have a business to run.

That is our whole reason for existing. At CSW Solutions, we help small and midsize companies wire AI into the tools they already run, QuickBooks, Dynamics 365, your CRM, your help desk, without the science project and without the six-figure invoice. We start by getting your data into the shape these tools need, because we would rather fix the boring foundation than watch a slick agent produce confident nonsense. Then we turn on the right features in the right order, wire up the automation with Power Automate and Copilot Studio where it earns its keep, keep the sensitive stuff inside your governance, and set up the approval checkpoints so a human always has the last word until you decide otherwise. And because our roots are in custom software and managed cloud on Microsoft Azure, when an embedded feature runs out of road and you need something built to fit, we can build that too.

You do not need an AI department. You already own most of the AI you need. You just need a partner who knows which switches to flip, in what order, and where to put the guardrails so the whole thing quietly makes you money instead of quietly making you nervous.

If you have QuickBooks, a CRM, and a support inbox, you have everything required to start. Let us help you wire it together. Reach out to CSW Solutions and we will map the quickest, safest path from “we should probably do something with AI” to “wait, when did the software start doing this for us?”

Fair question. Let’s answer it in plain English, with real numbers, real companies, and links you can check yourself. No hexagon worship required.

The problem Fabric is actually trying to solve

Here is the thing almost every growing company runs into. Your data lives in too many places. Sales numbers sit in one system. Your accounting lives somewhere else. Marketing has its own dashboards, the operations team keeps a spreadsheet nobody else is allowed to touch, and somewhere in the building there is a database that only one person understands and you are terrified he will quit.

To make sense of all that, most companies end up stitching together a small zoo of tools. One product to move the data, another to store it, a third to clean it up, a fourth to run the reports, and a fifth to sprinkle some AI on top. Every one of those tools has its own bill, its own login, its own quirks, and its own way of not quite talking to the others. Microsoft’s own documentation describes the old approach bluntly: organizations rely on “multiple disconnected services,” and that fragmentation “creates data silos, increases integration overhead, and slows time to insight.” You can read that framing in Microsoft’s end-to-end data lifecycle overview.

Microsoft Fabric is Microsoft’s answer to the zoo. Instead of buying five things and gluing them together, you get one platform that covers the whole journey, from getting the data in, to storing it, to cleaning it, to analyzing it, to putting it in front of a human being who has to make a decision by Friday.

So what is Fabric, really?

Fabric is a cloud-based analytics platform delivered as software-as-a-service, which is a fancy way of saying you do not install it, patch it, or babysit the servers. You log in and it is there. Microsoft’s official overview describes it as a single environment that unifies data ingestion, transformation, analysis, and visualization.

The clever part is what sits underneath everything. It is called OneLake, and it is the idea that makes Fabric more than just a bundle of old products in a new box.

Think of OneLake as the company hard drive for all your analytics data, except it is a proper enterprise data lake in the cloud. According to Microsoft’s OneLake documentation, every Fabric tenant automatically comes with one, and it is “the single place for all your analytics data.” It stores everything in open formats, specifically Delta Parquet and Iceberg, which are industry standards that any tool can read. Translation: your data is not locked into a proprietary cage. If you ever want to leave, you can, and that is a healthier position to negotiate from.

Here is why that “one copy” idea matters so much. In the old world, if your data engineers wanted to work with the data, they copied it. If the analysts wanted it, they copied it again. If the data scientists needed it, another copy. Suddenly you have five versions of the truth and endless arguments about whose number is right. With OneLake, everybody reads from and writes to the same place, so the data does not have to move between engines. Microsoft calls this “one copy of data to use with multiple analytical engines without duplication.” One copy. One version of the truth. Fewer meetings that start with “well, my dashboard says something different.”

The main pieces, without the jargon

Fabric organizes itself into what Microsoft calls role-specific workloads. You do not need all of them on day one, and honestly most companies grow into them. But it helps to know the cast of characters.

Data Factory is the mover. It is the cloud-based service that pulls data in from wherever it lives and shuttles it around. Microsoft’s Data Factory documentation notes it comes with more than 200 native connectors, so it can talk to your CRM, your ERP, your SQL Server, and plenty of non-Microsoft systems without a custom project every time. There is even a mirroring feature that continuously replicates an existing SQL Server database straight into OneLake, so you skip a lot of painful plumbing.

The Lakehouse is where flexible data lives. Per the Lakehouse overview, it holds both tidy structured tables and messy unstructured files, like images or raw logs, in the same place. It is the Swiss Army knife of storage. Many teams organize a lakehouse using what is called a medallion architecture, with bronze, silver, and gold layers for raw, cleaned, and business-ready data, described in Microsoft’s medallion architecture guide. Think of it like doing your laundry: dirty clothes, washed clothes, folded and ready to wear.

The Warehouse is for people who love SQL and structure. The data warehousing documentation describes a high-performance, fully managed SQL analytics engine with full T-SQL support, so your database folks feel right at home writing stored procedures and views.

The Eventhouse handles real-time, high-volume data, the kind that comes screaming in from sensors, apps, and live event streams. Microsoft’s Eventhouse documentation explains it is built for near real-time analytics, automatically indexing and partitioning data as it arrives. This is the piece that lets you answer “what is happening right now” instead of “what happened last month.”

And then there is Power BI, which many of you already know and love. It is the reporting and dashboard layer, the part that turns all this machinery into a chart your CFO will actually look at. Because it sits on the same OneLake foundation, a report can read directly from your governed data without yet another export.

Two more things worth knowing. Copilot is baked in across Fabric, and per Microsoft’s Copilot in Fabric overview it helps people write queries, build pipelines, generate code, and summarize insights using plain language, while respecting your permissions and data boundaries. And governance runs through Microsoft Purview, which is built directly into the platform, so sensitivity labels, access control, and auditing follow your data around instead of being bolted on later. That is the difference between a locked filing cabinet and a pile of paper on the break room table.

Does any of this actually work in the wild? Yes.

Theory is lovely. Let me show you a company that flipped the switch and got results, with a source you can read in full.

One NZ, the largest mobile carrier in New Zealand, needed its customer service teams to stop flying blind. They moved to Microsoft Fabric Real-Time Analytics, and according to Microsoft’s published customer story, they stood the upgrade up in less than two weeks. Not two years. Two weeks. They gave nearly 1,000 users a live, tailored view of customer data.

The results are the part that makes a business owner sit up. Reports that used to lag now refresh every 10 seconds, which Microsoft describes as roughly six times faster than before. Support teams were able to respond to customer inquiries nearly twice as fast. Under the hood, they used Fabric event streams to pull in live data and a KQL database to analyze it, and they are now building on top of that foundation with a language model that identifies customer intent. That is the whole promise of Fabric in one story: get the data flowing into one place, and suddenly the fancy stuff on top becomes reachable.

One NZ is not alone. In a widely circulated roundup of Fabric case studies, BDO Belgium, an advisory and accounting firm, built a mergers-and-acquisitions analytics platform called Data Eyes on Fabric and paired it with Power BI so finance professionals could analyze large datasets in a no-code environment, without waiting on a technical team every time. In the same collection, Hitachi Solutions North America turned to Fabric to wrangle consultant workloads across more than 70 data and AI projects, gaining the visibility and governance to plan resources in real time instead of chasing spreadsheets. Different industries, same pattern. Unify the data, then move faster on top of it. I will flag the honest caveat here: the One NZ figures come straight from Microsoft, while the BDO and Hitachi details come from a third-party roundup, so treat the first as the gold standard and the others as directional color.

What about the money? Let’s talk pricing honestly.

This is usually where the room goes quiet. Fabric pricing is refreshingly not a mystery, but it does work differently from a simple per-user subscription.

Fabric runs on capacity. You buy a certain amount of computing power, measured in Capacity Units, and everything you do draws from that shared pool. Capacities come in sizes called SKUs, and per Microsoft’s licensing documentation they scale from a small F2 with 2 Capacity Units all the way up to an F2048 and beyond. The nice part for a growing business is that the bottom of the range is genuinely approachable, so you do not have to buy an enterprise-sized engine to run a compact car.

A few practical facts that matter for budgeting. Fabric capacity is billed per second with no long-term commitment when you buy it through Azure, and you can make a yearly reservation to save money once you know your usage, as laid out in Microsoft’s subscription guide. Even better, F SKUs let you pause and resume a capacity and resize it up or down at any time, described in the features by SKU documentation. If your reporting only runs during business hours, you are not obligated to pay for a machine humming away all weekend. Current per-hour and per-month rates live on the official Azure pricing page, and rates are regional, so the number you see depends on where your capacity lives.

One licensing nuance to keep in your back pocket. To create and consume Power BI reports you generally still need a Power BI Pro license per user, but once you are on an F64 capacity or higher, people can view Power BI content with a free Fabric license, per the Power BI Premium FAQ. For a company with a handful of report authors and a lot of report viewers, that threshold can change the math considerably. This is exactly the kind of detail that is boring until it saves you real money.

And before you commit a dime, there is a free 60-day Fabric trial that gives you a full-featured capacity to kick the tires. Microsoft even recommends using the trial plus the Capacity Metrics app to measure your real usage before choosing a SKU. In other words, you can find out what size engine you actually need instead of guessing.

The catch, because there is always a catch

I am not here to sell you a fairy tale, so let me be straight about where Fabric asks something of you.

First, capacity is shared, which is a blessing and a discipline. Because every workload draws from the same pool of Capacity Units, a runaway query or a poorly built pipeline can hog resources and slow everyone down. That is not a flaw so much as a reason to have someone who knows how to size and monitor the thing. Microsoft ships a Capacity Metrics app precisely so you can watch consumption and adjust, and using it well is a skill.

Second, “unified” does not mean “automatic.” Fabric hands you an extraordinary set of tools, but your data still has to be connected, modeled, cleaned, and governed by people who know what good looks like. A platform that can do everything will happily let you build a mess faster than ever if nobody is steering. The medallion architecture, sensible naming, and real governance policies are not optional nice-to-haves. They are the difference between a lakehouse and a swamp.

Third, it is a fast-moving product. Microsoft ships new Fabric features constantly, which is great for capability and occasionally dizzying for planning. Someone needs to keep an eye on what is generally available, what is still in preview, and what actually applies to your situation, so you adopt the parts that help and skip the shiny objects that do not.

None of these are reasons to avoid Fabric. They are reasons to go in with a plan and a steady hand, which brings me neatly to the part where I stop being modest.

How CSW Solutions fits into all of this

Here is where we come in, and we will be honest about it, because that is how we like to work.

CSW Solutions is a local, all in-house IT consulting firm, and we spend our days helping small and mid-sized businesses get real value out of the Microsoft and Azure stack. We are in your time zone, and we’ll sit down with you over a pint. That size and familiarity is the point, not a limitation. You are not going to be account number 4,097 in a queue somewhere in another country. When you call, you get people who know your data, remember your last conversation, that you aren’t awake until you’ve had your coffee, and actually care whether the thing works on Monday morning.

Fabric sits right in the middle of everything we do. Our AI-expertise, managed IT, and cloud practice means we can stand up your Azure environment, buy and size your Fabric capacity correctly, and keep it healthy over time. Because Fabric can be purchased and managed through a Cloud Solution Provider, described in Microsoft’s own subscription documentation, we can handle the provisioning, consolidated billing, and support so you have one accountable partner instead of a maze of portals. We watch the Capacity Metrics so a rogue query does not blow your budget, and we right-size the SKU so you are not paying for horsepower you never touch.

Our custom software development practice matters more here than it might sound. A lot of the value in Fabric shows up when your data connects cleanly to the applications your business actually runs on. We build the connectors, the pipelines, and the integrations that turn “we have a data platform” into “our systems talk to each other and the reports are correct.” When your operational data needs to flow into OneLake without a fragile hand-built script, that is a software problem, and software is what we do.

And if all of that wasn’t enough, our AI and automation practice is where the fun payoff lives. Once your data is unified and trustworthy in Fabric, the interesting things become possible. Copilot-assisted analytics so your team can ask questions in plain language. Automated alerts that trigger an action the moment a number crosses a line. The kind of intent-detection and language-model work that One NZ built once their real-time foundation was in place. We help you get the foundation right first, because AI on top of messy data is just a faster way to be confidently wrong.

Most of all, we translate. We can sit in a room with your operations lead and your bookkeeper and your one indispensable database person, and turn Fabric from a slide full of hexagons into a plan with a budget, a timeline, and a first win you can point to. We start small, usually with a single high-value report or data flow that proves the value, then we grow it as your confidence grows. No boiling the ocean. No two-year mega-project that dies in month nine.

So if that forwarded slide has been nagging at you, here is a very low-risk next step. Let us spin up the free 60-day Fabric trial together, connect one real data source you care about, and build one dashboard that answers a question you have been asking manually for years. You will learn more from that one afternoon than from a stack of vendor decks, and you will find out fast whether Fabric is right for you, with no commitment and no drama.

Your data has been trying to tell you something useful for a while now. Let’s finally give it a place to speak, and someone in your corner who knows how to listen. When you are ready, CSW Solutions is right here.