Store · IT services implementation
The prevention your company contracted begins at implementation.
Before a service can prevent a problem, the environment has to be prepared for it: technical alignment with your team, an execution plan, configuration of the items in scope and follow-up during execution. That work is what decides what the contract will be able to prevent later. When it is done halfway, the service keeps being paid every month, but stops acting exactly where no one looked.
Scope is the list of what the service will look after. Everything left out of it remains the company's risk, not the contract's.
An incomplete implementation raises no alert. The report shows in good order exactly what was implemented, and silence about the rest.
The window in which this gets decided happens once. After the operation starts, what was left out rarely comes back to the table.
If one day the service your company pays for every month does not act where it was needed, the reason will not be in the service. It will be in what was decided, or not decided, when it was implemented.
The real problem
The service was under contract. It just was not acting where it needed to.
None of the situations below show up as a failure. They raise no alert, appear in no report and bother no one for months. They are all born in the same place, a rushed implementation, and the bill only comes due on the day of the problem:
The item that never made it into the scope
A server, a workstation or a mailbox that no one listed at the start. The service works perfectly across everything that was implemented, and that item simply does not exist for it. No one notices, because an item that is not being tended raises no alert either. Default configuration is one of the ten most common network misconfigurations, according to the 2023 joint assessment by the NSA and CISA, and it shows up even in large organizations with mature security postures.
The rule that only half took effect
The policy was agreed and applied, but reached only part of the environment. Half the company is the way it was agreed, the other half stays as it was. In the reports everything looks fine, because what gets measured is what was implemented.
The routine that never actually ran
The task was scheduled, but never checked actually running. Because of a permission or timing detail, it fails silently from day one. The service is contracted, it shows up on the invoice, and it never produced the result it should have.
The temporary exception that stayed
During implementation someone had to open an exception so an old system would work, meaning to close it later. Later has no owner and no date. Months on, that door is still open, and no one remembers why it was opened.
The step left with no owner
A step depended on someone on the company's side: granting an access, confirming a list, approving a time slot for the work. The item had been listed from the start, but since it was not clear whose the step was, it became no one's. The service goes live with everything else, the reports arrive complete from its point of view, and nothing points to the piece left waiting.
Notice what the five scenes have in common: in none of them did the service fail. It did exactly what it was implemented to do. What was missing was the work of deciding, together with your team, what is included, under which rule and whose each part is. That is the work Implementation and Activation delivers.
What it is
The work that turns a contracted service into a service that acts
Implementation and Activation is the service where Zamak puts into operation, in your environment, what your company has contracted. The contract may cover one item or ten: the implementation covers exactly what is in your proposal. In practice, it is the work of sitting down with your team to understand the operation, defining what is included and which rules will apply, running the configuration of each item, following along while that happens and recording everything before the ongoing cycle begins. Managed services, in the end, are these: services that start being run continuously inside your environment, such as protecting your data, securing the equipment and operating the servers. None of them starts acting on its own.
Run as a project, not as an install
Each stage has its moment and its owner on both sides: what is aligned first, what is planned, what is executed, what is followed and what marks the entry into operation. It is not someone applying loose configuration and reporting at the end.
The scope is the one in your proposal, no more and no less
There is no closed implementation package, because no two companies have the same environment. The implementation is the activation of what you contracted: if it was two services, it is those two; if it was the whole operation, it is the whole operation. The size of the work follows what is in scope.
It truly enters operation, with a record
The implementation ends when the service is acting and there is a record of what was configured, which rules apply and what was agreed. Your team keeps that record, and it becomes everyone's reference from then on.
The implementation is run alongside your team and your IT partner, with decisions made together with whoever knows the operation.
What is included
What you get, and what comes off your plate
Implementation is not a bureaucratic step before the service starts. It is what determines the reach of the service from then on, and that is why it carries a value of its own, separate from the monthly fee.
What you get
The contracted services running in your environment.
- Technical alignment meetings with your team, to understand the operation before touching anything.
- An execution plan with what will be implemented, in what order, with which owners on each side and in which execution windows, the agreed time slots for touching the environment without stopping your operation.
- The configuration of every item in scope, with the agreed rules applied across the whole environment they are meant to reach.
- The scheduling of the routines that start running on their own, checked actually running and not merely scheduled.
- The record of what was configured and of the rules that apply, handed to your team at the start of the ongoing operation.
What comes off your plate
The concentrated effort at the start is Zamak's to run.
- You do not have to figure out alone what goes into scope and what can be left out without risk.
- Execution windows are coordinated according to what your operation allows, with any necessary pauses agreed beforehand.
- Checking item by item what was agreed stays with whoever runs it, not with your team.
- What comes up along the way is handled during execution, which is where an implementation usually stalls.
- What was done is on record, instead of relying on one person's memory.
The five fronts
The five fronts of a managed implementation
Running the implementation as a project is not a formality. Among complex projects, which according to the Project Management Institute are already more than half of all projects, those that handle complexity well reach an 88% success rate, against 14% for those that handle it poorly or barely at all (Pulse of the Profession 2026). The difference is not in the tool or the ambition, it is in how the work is run. That is why Zamak's implementation is organized into five fronts, each with its own moment.
Technical alignment
Meetings with your team to understand how the operation actually works, settle what goes into scope and define the rules that will apply. This is where the reach of everything that follows is decided, with the people who know the environment at the table.
Execution plan
What will be implemented, in what order, with which owners on each side and in which windows. The plan exists so the work happens in the windows your operation allows, and so no one discovers midway that a step belonged to someone else.
Execution
The configuration of each item in scope, the application of the agreed rules and the scheduling of the routines that start running on their own. This is the front that turns what was decided into something that actually acts inside the environment.
Follow-up
Checking what is being delivered as it goes, correcting whatever comes up along the way. Every implementation runs into something no one foresaw, and the difference is handling it right away instead of leaving it until it becomes a problem.
Entry into operation
The record of what was done and the start of the ongoing cycle. From here the service is acting, your team knows what is covered and under which rule, and day-to-day operation takes the place of the concentrated effort of the start.
The five fronts are run on the same structure Zamak already operates every day, with tools certified in SOC 2 Type II, ISO 27001 and ISO 9001 and professionals who serve in Portuguese, English and Spanish. That is what separates a managed implementation from a sequence of settings applied in the dark.
Not sure how big your implementation is? Zamak sizes it together with you, from the items in your proposal and the environment they will reach.
Why it is charged separately
The work in a contract is not flat over time
Every service contract has a concentrated effort at the beginning and a steady regime afterwards. Understanding, deciding, configuring and putting into operation concentrates, right at the start, an amount of work the ongoing operation does not repeat in any month that follows. That peak is what the implementation covers.
Implementation
Ongoing operation
The peak at the start
It concentrates the understanding of the environment, the scope and rule decisions, and the configuration of each item. It is work that happens once and defines what the contract will be able to prevent from then on.
The steady regime
After entry into operation, the effort levels off and becomes the ongoing routine the monthly fee covers: operating, following along and correcting what comes up day to day.
This peak exists in every new contract. What changes is who absorbs it: with no one running it, it falls on the team whose day is already full, and whatever is left out no one notices. Charging that effort separately is what keeps your monthly fee as the real number of the ongoing operation: work that happens once is paid once, and not spread across every month that follows it.
Take this documentation to present to decision-makers.
Comparison
Three ways to put a new service into operation, side by side
When a company contracts a new service, there are three paths for it to start acting. See what each one actually delivers, without rhetoric.
What goes into the scope
Zamak's choice
Implementation run by Zamak
Defined with your team, item by item, before starting
Activating on your own, amid day-to-day work
Whatever can be mapped between the day's urgencies
Turning it on with factory defaults
Whatever the factory default already has ticked
The rules that will apply
Zamak's choice
Implementation run by Zamak
Agreed with the people who know the operation and applied across the whole environment
Activating on your own, amid day-to-day work
Set in the gap between two tickets, with no time to settle them with everyone
Turning it on with factory defaults
The ones the vendor chose as the default for everyone
Who runs the configuration
Zamak's choice
Implementation run by Zamak
Professionals who do this every day, backed by Zamak's structure
Activating on your own, amid day-to-day work
Your team, split between this and the operation that cannot stop
Turning it on with factory defaults
No one: whatever comes ticked is what stays
What happens to the surprise midway
Zamak's choice
Implementation run by Zamak
Handled during execution, corrected before entry into operation
Activating on your own, amid day-to-day work
Becomes a temporary exception that is almost never revisited
Turning it on with factory defaults
It does not show up, because no one is looking
The record of what ended up in force
Zamak's choice
Implementation run by Zamak
Handed to your team at the start of the ongoing operation
Activating on your own, amid day-to-day work
Lives in the memory of whoever took part, until that person changes roles
Turning it on with factory defaults
There is none: a default does not document your company
What the service can prevent afterwards
Zamak's choice
Implementation run by Zamak
What was decided in scope, across the whole agreed environment
Activating on your own, amid day-to-day work
The part there was time to configure before the next urgency
Turning it on with factory defaults
What the generic default covers, which is rarely your case
A comparison of ways to put a service into operation. Each company weighs its own case; a managed implementation exists so that the decision about what the service will cover is made, rather than inherited from a default.
Risk and response
From the detail that slips by to an operation that starts whole
An item is left out of scope with no one noticing
The company pays for the full service and gets partial coverage, finding the gap only during an incident
With a managed implementation
Scope is settled against what actually exists in the environment, not against a list someone typed
The agreed rule reaches only part of the environment
The report measures only the implemented half, and the next decision is made on a picture that is not the real one
With a managed implementation
The rule's application is checked across the environment it should reach, not just assumed applied
A routine is scheduled and never actually runs
Months of fees for a routine that never produced a result, and the discovery happens on the worst day
With a managed implementation
A routine only counts as delivered once it has produced its first real result
A step depends on your team and is not made clear
The service goes live incomplete and the fix ends up with no owner
With a managed implementation
No stage starts without a named owner on both sides, so nothing waits on an assumption
Each row is a common implementation situation, not a hypothesis. The answer is not more technology: it is deciding, together with the people who know the operation, what is included, which rule applies and whose each part is.
For every role
What a well-run implementation changes for each person who decides
From the owner to the IT partner, what gets decided at implementation matters differently to each one.
Owner or partner
What is decided here defines what the contract will be able to prevent later.
You are not paying for an administrative step before the service starts. You are paying for the work that determines the reach of everything that follows: whether the service will act across the whole environment or only on the part that made it onto the list. It is the point in the contract with the greatest effect on the risk your company carries.
C-level or manager
You know what is included, in what order, and your monthly fee stays the number you defend.
You know what is included, in what order and in which windows, so the work happens when your operation allows it, not in the middle of your day. And since the concentrated effort of the start is charged separately, the monthly fee remains the real number of the ongoing operation, which is what you take to the spreadsheet and defend internally.
IT leader or team
The rules are decided together with the people who know the operation: you.
Zamak comes in adding trained, experienced people to the process, and the technical alignment exists precisely because no one knows the environment better than your team. What will apply in the environment is still decided by you; what comes in addition is the concentrated effort of the start, which your team could not absorb without stopping day-to-day work, and the record of what was configured, which stays with them at the end.
IT partner and provider
The structure comes in on the plan and in the windows you define.
When you take a new service to a client of yours, implementation is the moment of greatest effort and greatest exposure. Zamak runs that entry at your side, on the plan and in the windows you define, so your delivery starts whole. You keep the client and the relationship; the structure comes in as the backline.
The difference is in how it is run
Why Zamak
Anyone can apply a setting. What carries the weight in an implementation is what comes before and after it: the conversation that uncovers how your operation really works, the plan that avoids stopping your day-to-day, the check on what was applied and the record your team keeps. Zamak runs that work adding to what your team already does, with decisions made together with whoever knows the environment.
In the end, it is the difference between a service that exists in the contract and a service that acts in your environment on the day it is needed.
Serving companies that cannot stop · Microsoft Solutions Partner · Addee (N-able) Elite Group · Great Place to Work.
Professionals who serve in Portuguese, English and Spanish, backed by the same operation and security structure that already tends to clients' day-to-day.
Frequently asked questions
Frequently asked questions
See also Managed Service Plans · Dedicated IT Professional
Start now
Start your operation on the right footing.
A rushed implementation charges nothing on the day it happens. It charges months later, in the item no one listed and the rule that reached half the environment, when there is no longer anyone to ask why it turned out that way. Talk to Zamak and size, from the items in your proposal, the implementation your environment calls for.
Request a proposal
In a few fields, tell us what your company plans to put into operation. If you already have a Zamak proposal in hand, a Zamak Technologies specialist in your country sizes the implementation from the items in it.
Talk to a specialist
Prefer to talk first? Book a conversation and Zamak understands your environment and what needs to go live.
Take it to the decision-maker
Download this page as a PDF and show whoever approves the contract what the implementation decides about what the service will be able to prevent.