Understand
Start with the business objective, affected services and constraints.
Cisco & Meraki specialists. Across the UK.
A controlled way to deliver network change
How We Work
From the first conversation to testing and handover, we keep the requirement, responsibilities and evidence clear.
1,000+
Devices supported
across the UK
20+
Client locations
supported
Nearly 8 Tbps
Traffic handled
at peak time
3 min
Average
response time
Average response is not a resolution time or a contractual guarantee. Support scope and response commitments are agreed for each engagement.
How we work starts with understanding the problem you need to solve, not selecting equipment before the requirements are clear. MCI Network Services provides Cisco and Meraki engineering for projects, targeted investigations and ongoing management. The delivery approach should make the scope, approvals and evidence understandable to the customer as well as the engineer carrying out the work. The exact responsibilities and commitments are recorded in the relevant engagement documents.
The delivery path
Five stages, with decisions visible at each one.
Define
Agree scope, dependencies, responsibilities and acceptance criteria.
Prepare
Confirm access, approvals, backups, baselines and the recovery route.
Deliver
Implement in controlled stages with checkpoints and clear communication.
Prove & hand over
Test the service, record limitations and leave usable operational evidence.
01Understand
Establish the requirement and its boundaries
An initial discussion identifies the business objective, affected services and the people responsible for them. A new office, an unstable market-data connection and a campus refresh require different information. We ask about the existing environment, planned changes, constraints and the impact of failure. A short redacted topology can be useful once a suitable transfer method has been agreed.
We also identify what is outside the networking scope. An application owner, carrier, building contractor or security provider may control an important dependency. Their involvement is recorded early, rather than discovered during the maintenance window. Where the evidence is incomplete, an assessment or discovery stage can establish the facts needed for a reliable design and implementation proposal.
02Define
Make the proposal useful for a buying decision
The proposal should distinguish outcomes, activities and deliverables. It identifies the sites and platforms in scope, assumptions, customer responsibilities and any exclusions. Where hardware, subscriptions, carrier services or another supplier’s work are required, those dependencies are separated from the engineering service. Costs and contractual terms belong in the actual proposal, not in an unqualified promise on a service page.
Acceptance criteria explain how the result will be assessed. That might mean defined application paths, tested isolation, observed failover or a set of approved design records. A support engagement also needs service hours, incident priorities, escalation and change responsibilities. Monitoring a device continuously is not the same commitment as providing immediate on-site engineering for every alert.
03Prepare
Prepare access and authorisation before implementation
Work on production systems needs the customer’s authority and an agreed access method. We establish who can approve the change, who should be informed and who can make a decision if unexpected conditions arise. Administrative permissions should match the task. Sensitive credentials and configuration material are exchanged through an agreed process, not collected through a public enquiry form.
Preparation includes relevant backups, baseline observations and a practical recovery plan. A configuration file alone does not guarantee rollback: engineers also need access to the device, compatible software and enough time to recover safely. Where a change may affect our own management connection, alternative access or local assistance should be planned before work starts.
Before production changes
Three things should already be clear.
04Deliver
Introduce changes in controlled stages
The implementation sequence follows the approved design and maintenance constraints. A staged rollout can expose a dependency at a pilot site before it affects the wider estate. Pre-change checks establish whether the environment still matches the assumptions used in planning. If it does not, the scope or timing may need review rather than pressing ahead with an unsuitable procedure.
During delivery, verification is linked to decision points. The team needs to know when it is safe to continue, when further investigation is required and when rollback should begin. A technically completed command sequence is not the same as a successful service change. Communication should explain the observed customer impact and the next action, including any requirement for another supplier’s involvement.
05Prove & hand over
Test the service and hand over the evidence
Post-change checks cover the agreed application paths and relevant security or resilience requirements. We record what was tested, the outcome and any limitations. A fault scenario that cannot be exercised safely in production should be marked as untested, with the supporting design evidence explained separately. This avoids turning an assumption into a claim of proven resilience.
Handover material should help the people who will run the network. Depending on scope, it can include diagrams, addressing records, configuration references, monitoring arrangements and recovery procedures. Outstanding actions need owners and review dates. Any follow-on support or maintenance arrangement is agreed explicitly; project completion does not silently create an unlimited support obligation.
Bring us the requirement
You do not need a finished technical specification.
A short outline of the business change, affected sites and current platform is enough to start.
06Operate around reality
Plan delivery around the actual sites and team
Our Cisco and Meraki network services cover the UK, particularly London, Kent, Sussex, Essex and Berkshire. Most engineers are based in Kent, while remote and on-site work are combined according to the engagement. Site access, escorts, travel, maintenance windows and local assistance are practical planning inputs, not administrative details to leave until deployment day.
Your internal team can retain operational control while MCI supplies specialist design or implementation work, or we can agree a broader managed arrangement. Start through Contact Us with the requirement and constraints. We can then establish a defined piece of work, the information needed to progress and the responsibilities that will apply throughout delivery.
Ways to work with MCI
Use the level of involvement the requirement actually needs.
Design & delivery
For a defined change, migration, rollout or new network with agreed acceptance criteria.
Escalation & investigation
Bring in Cisco or Meraki expertise for a difficult fault, review or technical decision.
Managed operations
Agree monitoring, maintenance, change and escalation responsibilities for the live environment.
Standards & partnerships
Confidence in the team behind your network.
Cisco Partner
Cisco MerakiISO 9001Quality management
ISO 27001Information security
Cyber Essentials
Cyber Essentials PlusMCI Network Services is operated by Proxar Ltd. Certifications apply to the certified legal entity and the scope of its certificates. View accreditation information
Start with a conversation
Tell us what you need the network to do.
We will help define the right engineering work, what information is needed and who needs to be involved.
Your Cisco & Meraki Partner
What does your
network need next?
Bring your Cisco or Meraki network to a specialist partner. Tell us what is changing, what needs attention or where you need a second opinion.
Talk to a specialist