How to Use Claude to Turn a Network Diagram and BOM Into a Deployment Runbook

The short answer: Claude can read an exported network diagram alongside an equipment BOM and draft a sequenced deployment runbook — install order, a port-by-port cabling map, and a UAT sign-off checklist — in an afternoon rather than across three evenings. What it produces is a first draft for a deployment engineer to correct and own. It cannot see the site.

The design is signed off. The purchase order went out three weeks ago. Four pallets land at a new sixty-desk office in eleven days, and the two field engineers who will unpack them have a PDF of the network diagram, an Excel BOM with forty-three line items, and a Monday start date.

What they do not have is a runbook — the ordered list of what gets racked at which RU, which cable lands in which port, which device has to be configured before the next one can be tested, and what must be demonstrably working before anybody signs a handover sheet.

So they improvise, competently, and most of it goes fine. Then the third-floor access points come up on the wrong VLAN because the switch port template was decided on site rather than in advance, the labelling doesn't match the drawing, and six weeks later nobody can say from documentation which patch panel port feeds the meeting-room display.

That gap — between a design that is finished and an install that is sequenced — is a drafting problem, not an engineering one, and it is the part worth handing to a model.

Why "The Diagram Is Done" Still Leaves the Install Crew Guessing

A network diagram states an end state. A runbook states an order of operations. The second does not fall out of the first automatically, and the reason deployment project managers at systems integrators keep writing runbooks by hand the night before mobilisation is that the translation between the two is tedious rather than difficult.

The diagram shows a firewall with a WAN interface. It does not say that the carrier circuit has a handover date belonging to a third party, that nothing downstream can be properly tested until it lands, and that the crew therefore needs a defined fallback for day one if it slips.

And the diagram says nothing at all about the two things that consume the most site time: the labelling scheme and the port map. Both get invented on the day by whoever is holding the label printer, and both are what the next engineer to visit will depend on entirely.

The cost lands after the crew leaves. As-built documentation gets reconstructed from photographs on someone's phone. UAT becomes "we tested it and it worked." A change six months later starts with a discovery exercise that the original install should have made unnecessary.

What Claude Can Draft From a Diagram and an Equipment List

Claude reads images and documents, so a diagram exported from Visio, Lucidchart or draw.io as a PDF or PNG can go in directly, alongside the BOM pasted from Excel as CSV. It reads what is labelled on the drawing. It does not evaluate whether the design is sound, and it cannot see the building.

Within that boundary, two outputs are genuinely worth an afternoon.

A sequenced rack-and-stack and cabling checklist

Given the diagram, the BOM and your own rack elevation convention, it will produce an ordered install list: what is mounted where, in what sequence, with dependencies made explicit — power and earthing before anything is racked, the core switch before the access layer, the firewall before any device that needs to reach the internet to license itself.

The part that saves real time is the port map. From a drawing that shows which device connects to which, it will draft a checklist in the form "SW-CORE-01 port 1/0/24 to FW-01 port ge0/1, label A-24" — one line per physical connection. That is exactly the artefact nobody wants to type by hand and exactly the artefact that stops a crew guessing at 4pm.

Instruct it to mark every point where the drawing does not specify something — an unlabelled link, a device with no stated rack position — as "NOT SPECIFIED IN DESIGN" rather than choosing for you. That single instruction is most of the difference between a runbook and a liability.

A UAT test-and-sign-off checklist matched to the design's stated features

The same inputs produce a testable acceptance list, which is the document most site buildouts genuinely lack. If the design says redundant uplinks, the checklist should contain a step that pulls one and confirms failover. If it says guest Wi-Fi is isolated from the corporate VLAN, there should be a step that tries to reach a corporate resource from the guest SSID and expects to fail.

A Practical Workflow — From Diagram and BOM to a Field-Ready Runbook

1. Export the diagram as a PDF and check it is legible at the size it will be read. A model reading a drawing has the same problem an engineer does: if the port labels are four-point text under a crossing line, they will be misread. Export at a sensible scale, and if the drawing has multiple tabs, export them as separate files and say what each one is.

2. Sanitize before upload, every time. Site addresses, the client's legal name, public IP allocations, circuit reference numbers and anything resembling a credential come out first. Most of it is a find-and-replace to "Site 1" and "Client A". Make this a standing rule rather than a judgement call, because judgement is what fails under deadline pressure.

3. Give it your own conventions, not a request for best practice. Paste your firm's actual rack elevation rules, device naming standard, label format and runbook template. "Write a deployment runbook" produces something generic; "populate this template using these naming rules" produces something your engineer recognises and will actually carry onto site.

4. Generate the install sequence first, on its own. Ask for numbered steps with explicit dependencies and an owner per step. Tell it to flag any step depending on a third party — carrier handover, landlord riser access, a building electrician — because those are the steps that slip, and they need to be visible at the top of the plan rather than buried at step thirty-four.

5. Generate the port map as a second, separate pass. Narrow instructions beat one request for everything. This pass should output one line per physical connection, use the device names from the diagram verbatim, and write "NOT SPECIFIED" wherever the drawing shows no port number rather than inventing a plausible one.

6. Generate the UAT checklist as a third pass, sourced only from capabilities the design actually states. Each row is a test, an expected result and a sign-off space. Ask it to list separately anything it could not turn into a test — that list is usually a short and very useful set of questions for the designer.

7. Read it against the diagram yourself before it leaves your desk. You are checking two things: connections that are wrong, and connections that are confidently present but not on the drawing. The second is harder to spot precisely because it reads correctly.

8. Turn every "NOT SPECIFIED" into a numbered question for the design owner. This is the highest-value output of the whole exercise. Twelve specific questions answered before mobilisation is twelve decisions not made by a tired engineer at 6pm on a Friday with a label printer in one hand.

9. Print it, take it to site, and mark it up in pen. The marked-up copy is the as-built. Photograph it before you leave, then have the same model transcribe it back into the runbook document — which is how you get as-built documentation without anyone volunteering an evening for it.

An AI-Drafted Runbook vs a Certified Deployment Engineer's Runbook vs Improvising On-Site

• An AI-drafted runbook. Hours instead of evenings, exhaustive on the boring parts — port maps, UAT rows, label schedules — and consistent between sites because it is generated from a template. It has no site knowledge, no professional accountability, and it will produce a confident line about a connection the drawing never showed unless you have explicitly told it not to. Correct use: the first draft a deployment engineer edits and owns.
• A certified deployment engineer's runbook. Someone who has racked equipment in real buildings has decided the sequence will work, and has allowed for the riser that is already full, the lift that stops at the fourth floor, and the electrician who is only on site on Tuesday. That judgement is the actual deliverable — which is precisely why the transcription half is worth automating and the judgement half is not.
• Improvising on-site. More common than the industry admits, and it usually works, because good field engineers are good at it. The cost is invisible on the day and expensive later: no port map, no UAT record, as-builts reconstructed from memory, and a second site that shares none of the first site's conventions.

Where It Falls Short

It cannot see the site, and the site is where deployments fail. The riser that is already full, the comms room with one thirteen-amp socket, the fire door the cable tray was drawn straight through — none of that is in the diagram, so none of it is in the runbook. The document will look complete while omitting the constraint that determines the day.

Invented specificity is the characteristic failure mode. Asked to produce a professional-looking runbook, a model will supply plausible detail: a port number nobody specified, an RU position that follows from an assumption it made silently. It reads exactly like the correct lines, which is what makes it dangerous on a site where nobody is cross-checking against the drawing.

Safety and electrical compliance are not drafting problems. Load calculations, earthing, containment, working at height, and anything involving the building's power belong to a qualified electrician and to local regulation — not to a checklist a model produced. Keep those in the runbook as instructions to engage the right trade, never as procedures to follow.

It has no authority to sign anything off. A UAT sheet has value because a named competent person put their initials beside a test they actually ran. A generated checklist that everyone ticks at the end of a long day is worse than no checklist at all, because it looks like evidence.

Getting This Right — Design File Confidentiality, Version Control, and When to Bring in IT

A network diagram is a security document. It shows the topology, the segmentation, the management VLAN, often the addressing, and always the vendor and model of the perimeter device. It is a genuinely useful artefact to an attacker, and it routinely gets emailed as an attachment, uploaded to a chat tool, and left in the downloads folder of three laptops.

Know which tier of which tool you are actually uploading to. Consumer, team and enterprise plans differ in data retention and in whether content may be used for training, and the terms change — check the current documentation for the specific plan your firm is on rather than assuming. Then set a company-level rule about which tools may receive client design files. In most professional-services firms this is the single largest uncontrolled AI risk, and it is a governance problem rather than a technical one.

Version control matters more here than usual. This method produces early documents that look finished. Put a visible status line at the top — "AI-assisted draft, not reviewed" — until an engineer has signed it, and keep the runbook in one controlled location such as SharePoint or Confluence rather than as an attachment travelling by email. The version the crew carries onto site must be the only one anyone can find.

Choosing where AI belongs in a delivery workflow, writing the templates, and setting the rule about what may be uploaded is AI+ Support work; the access control, device management and data handling underneath it are ordinary managed IT support. The part that does not automate is the IT infrastructure deployment practice itself — the certified field engineers who rack, cable, survey and commission a site, the offsite staging that means the boxes arrive already configured, and the person who signs the UAT sheet. If you are documenting a move rather than a new build, our write-up on AI-drafted office relocation runbooks covers the migration-shaped version of this problem, and turning a scoping call into an HLD and BOM covers the design stage this runbook picks up from.

Frequently Asked Questions

Does this replace a certified field engineer?

No. What a client buys with a deployment is that someone qualified has decided the sequence will work in that building and stands behind the result at handover. A model cannot hold that responsibility. What it replaces is the two or three evenings spent typing a port map and a UAT sheet — the transcription between a design and an install, not the install.

What happens when the site doesn't match the diagram?

It usually doesn't, at least in part, and that is precisely why the runbook goes to site on paper. The engineer marks the deviation, notes why, and the marked-up copy becomes the as-built record. A runbook that cannot be contradicted on site is being used wrong; its job is to make deviations visible, not to pretend they won't happen.

How detailed does the input diagram need to be?

Detailed enough to be unambiguous about devices and connections. Port-level labelling is ideal but not required — a logical diagram with no port numbers still produces a useful install sequence and UAT list, it simply produces a longer "NOT SPECIFIED" list, which is itself useful. The one input that genuinely degrades the output is a low-resolution export where labels cannot be read.

Can it generate the as-built documentation afterwards too?

Yes, and this is the underrated half of the workflow. Photograph the marked-up runbook, feed it back alongside the original, and ask for a reconciled document showing planned versus actual with every deviation listed. That is transcription work, which is what this is good at. Have the engineer who did the install check it — the transcription is mechanical, but judging whether a deviation matters is not.

How long does this actually take in practice?

An afternoon for a single-site office buildout of the size described here, against the two or three evenings the same documents take by hand — and the first attempt will be slower because you are writing the template as you go. The larger gain is that the port map and UAT checklist exist at all, on the kind of site where the honest answer is that they usually don't.