Connect. Secure. Manage.
Network Documentation Services
Create and maintain Cisco and Meraki network diagrams, address records and service dependencies that support engineering work and incident response.
Devices supported
across the UK
Client locations
supported
Traffic handled
at peak time
Average
response time
Average response is not a resolution time or a contractual guarantee. Support scope and response commitments are agreed for each engagement.
Network documentation services create records your engineers can use during changes and faults. We map the actual Cisco and Meraki estate, including physical links, traffic paths and service owners. The records need a way to stay current. Sensitive details are limited to what the work needs and shared through the agreed access arrangements.
Useful visibility
Monitor service-relevant conditions rather than collecting alerts without ownership.
Controlled change
Keep maintenance, automation and configuration work reviewable and recoverable.
Clear escalation
Connect incidents to the right engineering, provider and business contacts.
Decide what the records need to support
We start with the audience and the operational questions. A service desk needs different information from an engineer planning a routing change, while a business owner may need a clear view of dependencies and resilience. The documentation scope is designed around those uses rather than a generic need to produce a large network manual.
Existing records are reviewed before new ones are created. They may contain useful design intent even when details are outdated. We preserve what can be supported, identify contradictions and distinguish checked facts from assumptions that still need access or investigation.
Standards & partnerships
Confidence in the team behind your network.
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
Reconcile the estate with evidence
Device inventories, dashboard information, settings and authorised site observations help establish the current state. We check identifiers, locations, software and network access rather than relying solely on procurement records. A replacement device may have inherited a name while changing its capabilities or physical connections.
Discovery has limits, particularly where equipment is inaccessible or another supplier owns part of the path. Those gaps are recorded clearly. Documentation should not invent a cable route, office location or provider dependency simply to make a diagram appear complete.
A useful starting point
Tell us what is happening.
A short description of the problem is enough for an initial discussion.
Separate physical and logical views
Physical records describe devices, racks, ports, media and relevant power or cabling dependencies. Logical views explain VLANs, routing, gateways, security boundaries and service paths. Combining everything into one dense diagram can make both kinds of information harder to use. So we choose views suited to the actual estate.
The views are linked through consistent names and identifiers. An engineer should be able to move from an app path to the relevant device and interface without guessing. We also show where the diagram stops at a provider or platform boundary and identify the owner of the missing internal detail.
Different environments. The same care.
Built around the work
your network supports.
Finance, banking and the wider private sector. We start with the systems and people that depend on your connections.
Finance & banking
Market-data paths, routing and provider coordination on clients’ behalf.
Financial-market services ↗Offices & multi-site teams
Reliable access between people, workplaces and business applications.
Office network design ↗Data centres & cloud
Network boundaries, workload connections and operational ownership.
Data centre networks ↗Capture addressing and policy ownership
Address registers, routing-domain records and key setup standards help control growth and reduce accidental overlap. We document the purpose and owner of important networks rather than recording only a subnet and VLAN number. Shared-service access and route-exchange boundaries receive particular attention because they often create hidden dependencies.
Security-sensitive detail is handled proportionately. A general operational diagram may identify a firewall boundary without exposing every rule or secret. Detailed settings and credentials remain in appropriately restricted systems, with references that authorised engineers can follow when needed.
Make resilience and recovery understandable
Documentation should explain what happens when a component fails, not merely show two lines and label the design redundant. We identify shared dependencies, expected alternate paths and any known limitations. Tested behaviour is distinguished from design intent that has not been exercised.
Recovery records connect diagrams with access methods, setup protection, replacement needs and escalation contacts. The aim is to help an engineer make a safe decision under pressure. A list of device names is not a recovery procedure, and an old screenshot of a dashboard is not proof that current access remains available.
Validate records with the operating team
We review representative paths and records with the engineers and service owners who will use them. This can reveal terminology differences, omitted dependencies or details that are technically correct but operationally confusing. The handover is an opportunity to test usability, not just get approval of the document’s appearance.
Open questions and unverified sections remain marked. The customer receives an action register identifying the evidence needed to close them. This avoids treating a document delivery as a claim that every physical and logical element of the estate has been independently confirmed.
Establish maintenance and version control
The final package identifies the authoritative location, editing rights and review process. Approved changes should update the relevant records as part of completion. Version history makes it possible to understand what was known at the time of an incident and prevents several conflicting copies from becoming competing sources of truth.
MCI can document an inherited estate or provide records as part of network operational assurance. Formats and detail are agreed for your team, with customer ownership and secure access preserved. The outcome is a practical engineering resource that remains useful after the original project and author have moved on.
Talk to a specialist
Need a specialist view?
Tell us what is affected, what changed and what your team has already checked. A short outline is enough to start.
+44 203 196 6566Choose option 1
sales@proxar.co.ukUK-wide service.
Most of our engineers are based in Kent, with a focus on London, Sussex, Essex and Berkshire.
Existing customers should use their agreed support and escalation channels. This form is for service enquiries, not a monitored emergency ticket.
Tell us what you need.
A short outline is enough. Please do not include passwords or sensitive network details.
Thank you. Your enquiry has been submitted.
Please check your name, email and message, then try again.
Your form session expired. Please try again.
Please wait a minute before sending another enquiry.
We could not submit your enquiry. Please call or email us instead.