White-Label Delivery & Bespoke Consulting

What can we actually deliver under your brand?

Broadly, the service lines we already run for our own clients, delivered by the same engineers with your name on the output. In practice the work that gets asked for most is: managed IT and service desk cover; Microsoft 365 and Azure project work, meaning tenant builds, migrations, SharePoint and Teams structure, and security hardening; security delivery including managed firewall, EDR and XDR rollout, Conditional Access design and Cyber Essentials preparation; backup and recovery design plus restore testing; application packaging and MSIX, including App Attach image builds; Azure Virtual Desktop and Windows 365 design, build and cost optimisation; legacy Windows and Windows Server migrations; and legacy application capture and repackaging where the original install media has gone.

That work happens in the background and lands as material you can put your own cover on. Where you want it delivered live, we can join a client session under your branding, described as your engineer or as your named specialist partner, whichever suits the relationship.

Bespoke consulting for vendors and partners, not just delivery capacity

Not every gap is a delivery gap. Sometimes a vendor, MSP or partner needs one specific, bounded piece of expert judgement rather than an ongoing bench, and that is a genuinely different engagement to scope for. A software vendor preparing to sell into Microsoft-centric enterprise accounts might need a technical reviewer who can sanity-check how their product actually behaves inside Conditional Access, Intune or an Azure Virtual Desktop estate before a customer's own architects ask the question.

Which engagement model fits: fully white-label, co-branded or overflow?

Fully white-label is the default. Your brand is the only one the client sees, we never appear in the room or on the documentation, and everything we produce is written in your templates for you to issue as your own. It suits contracts you have won on your reputation where the delivery skill happens to sit outside your team, and it is the model most vendors and MSPs ask for first.

Co-branded is the honest alternative when the client is buying the specialism as well as the relationship. Some end clients specifically want to see who is doing the work, particularly on Azure Virtual Desktop, Windows 365 or security engagements where a named credential carries weight in their own governance process. In that model you stay the contracting party and the account owner, and we are introduced as your named specialist partner rather than hidden.

Overflow is different again: not a skill gap but a capacity gap, where our engineers work inside your existing ticket queue, project tooling and processes to absorb a peak, a holiday period, a backlog or a project running hotter than planned. The right model is usually obvious within one scoping call, and it can change between engagements.

How does an engagement start, and what happens before we get any access?

A mutual non-disclosure agreement comes first, before any detail about your client, their estate or your commercial position is discussed. That is standard on every engagement, including ones that never proceed past a scoping conversation, because the useful conversation cannot happen while both sides are being careful. If you have your own NDA template, we are happy to work to yours rather than insisting on ours.

After that the sequence is deliberately boring, because boring is what stops disputes later. A scoping call establishes what the client actually needs, what you have already committed to in writing, and what your delivery team is keeping. That becomes a written scope naming the deliverables, the exclusions, the assumptions the estimate depends on, who owns each part, and how the work will be handed back.

Access is granted only after the scope is agreed, is limited to what the work genuinely requires, and is documented so both sides know exactly what we hold. Then delivery starts. The step partners tell us is most often skipped elsewhere is the assumptions list, and it is the one that determines whether a change in the environment becomes a conversation or an argument.

How do branding, tooling and communication work in practice?

Communication runs through one agreed channel with a named owner on each side, rather than through whichever engineer happens to be reachable. Most partners run a shared Teams channel or work into their own ticketing system, and where you want us in your tooling we work in your tooling: your ticket queue, your project board, your documentation platform, your naming and change conventions. That matters more than it sounds, because work delivered into your own systems is work your team can support after we step away.

Where you need us on a client call, we attend as part of your team and follow whatever description you have set with them. Anything that would put our brand in front of their brand is your decision to make, not ours.

How does escalation work when something goes wrong on your client's estate?

Through you, always. You own the client relationship and therefore the client communication, so our job in an incident is to give you an accurate technical picture fast enough that you can be the one telling them something useful. An arrangement where the subcontractor starts talking directly to the end client during an incident is exactly the failure that makes brands nervous about subcontracting in the first place.

We will not quote you a response target here that has not been agreed against real scope, because a number published on a web page is worth nothing when your client is asking you a question at eight on a Friday evening. Ask for it in writing, from us and from anyone else you are comparing.

Who uses white-label delivery, and why?

Hiring for it makes no sense when the requirement appears twice a year, and turning it down costs the contract and sometimes the account.

Software vendors use us for the deployment and integration layer around their own product: getting it packaged, delivered and supported cleanly in a customer's Microsoft estate, dealing with the identity, device and virtual desktop questions their support team is not staffed to answer, or standing behind a proof of concept in an enterprise environment.

IT resellers and consultancies use us for delivery capability behind a sale, so they can bid on work that includes implementation rather than restricting themselves to supply. In all three cases the pattern is the same: the brand and the relationship are already yours, and what is missing is the bench.

What goes wrong when subcontracting is done badly?

The failure modes are predictable and almost all of them are commercial rather than technical. A subcontractor turns up in front of the end client without warning, or worse, is recognised by them. Scope exists only as a verbal understanding, so every discovery becomes an argument about who agreed to what.

Nobody is named as owner on either side, so questions sit unanswered for days. Engineers rotate through the work with no continuity, and each new one asks your client's IT manager the same questions the last one did, which is what makes the arrangement visible.

Then there is the ending, where the real damage happens. The work completes but the documentation never arrives, so your team cannot support what was built and has to call the subcontractor every time something breaks, which is either an accident or a business model. Administrative access granted for the project is still live months later, on your client's tenant, in your name.

Or the subcontractor approaches the client directly once the engagement ends. Every one of these is preventable in writing at the start: named owners, a written scope with exclusions, handover documentation as a defined deliverable rather than a courtesy, an access removal step at the end, and a non-solicitation clause you should insist on from any partner, including us.

Where does our scope end, and what do we not do?

We do not hold your client contract and we do not carry your obligations under it. Whatever we deliver, you remain the supplier your client bought from, which means their commercial terms, their service commitments and their regulatory accountability stay with you. We can build to a standard you have committed to and give you the evidence that it was built that way; we cannot sign your commitment on your behalf.

Our certifications are ours and do not transfer. Systech's ISO 27001, ISO 9001 and Cyber Essentials certificates cover how Systech operates, so they are a fair statement about the processes your delivery runs through, and they are not a certificate you can present as your own.

The same applies to independent penetration testing, which we deliver with our CREST-approved partner Punk Security: that approval belongs to them, so it is disclosed rather than absorbed into somebody else's brand. And there is a practical boundary worth stating plainly, because it comes up: if a scope has been sold that cannot be delivered as described, we will tell you during scoping rather than after you have taken the money.

What sits behind the delivery, stated honestly?

We are not going to quote you a partner count or show you logos, because white-label work is confidential by definition and any firm willing to show you their other partners' names is telling you exactly how they will treat yours. What we can point you at is verifiable instead.

Systech is founder-led by Ryan Mangan, a Microsoft MVP renewed specifically for Azure Virtual Desktop and Windows 365, a Chartered Fellow of the BCS, and the author of Packt's two-edition Mastering Azure Virtual Desktop, with articles published in the BCS's IT Now and in Computer Weekly and a public MSIX App Attach reference wiki that other engineers use when they get stuck.

For a partner assessing us that combination is the point. It means the supply-chain questions your own client's procurement team will ask about us have answers you can evidence, rather than answers you have to take on trust and then repeat.

How is white-label work scoped and priced?

Per engagement, against a written scope, because the honest answer is that the same nominal task varies enormously with the estate it lands in. What we can commit to is the shape of the quote: it itemises what is included, what is explicitly excluded and what assumptions the estimate rests on, so you can price your own margin on top with confidence and compare it line by line against anyone else you are considering. A number quoted before anyone has looked at the environment is a number that will change.

Two commercial structures cover almost everything. Fixed-scope project work suits a defined deliverable with a clear end, such as a migration, a build or a packaging batch, and it is the easier one to sell on to your client because the risk is bounded.

A retained bench suits partners with recurring or unpredictable demand, where the value is knowing capability is available when a contract lands rather than paying for it while it waits. Plenty of partners start with the first, discover the demand is not one-off, and move to the second.