Guides
Internet Circuit Handover: Clarify the Provider and Site Network Boundary
Separate provider provisioning, physical installation, site prerequisites and agreed checks before an internet circuit handover. Record the actual boundary and unresolved responsibilities.
DETIAN ICT · Tanzania & East Africa
Discuss your ICT project with DETIAN.
DETIAN ICT supports audiovisual, security, network and smart-building projects in Tanzania and East Africa, with design, equipment supply, installation and maintenance services.
Share your site location, required systems and available drawings or equipment list. Start a discussion about the work scope and the information still needed.
Start with a named handover point
Before scheduling a site network handover around an internet circuit, identify exactly where the provider service meets the organisation’s equipment. Record the physical location, the agreed service reference, who supplies each device and which checks each party will attend. A circuit order, an installed box and a demonstrated working service are different states; do not treat one as proof of the others.
This is a planning worksheet for an East African office or other enterprise site. DETIAN’s public services describe ICT consultation, supply, installation and support. This guide does not claim that DETIAN is your internet service provider, can activate a third-party circuit, or guarantees a connection date or bandwidth. Confirm the actual responsibilities with the relevant organisations.
Locate the boundary without guessing ownership
Ask the provider to identify the agreed demarcation or handover point in its own service documentation. Note the building, room, rack or other unambiguous location, plus a labelled photograph or drawing reference if your organisation permits it. Avoid recording merely “server room” when the site has several cabinets or entrances.
List each item immediately around that point: provider termination equipment, any separately supplied converter, the customer router or firewall and the link between them. For each, record the owner, the party allowed to configure it and the person responsible for arranging access. Do not infer ownership from the installer’s uniform, the equipment brand or where the device is mounted.
Keep unanswered interface questions visible. Ask what physical connection and documented configuration requirements apply to the supplied service and the customer equipment. Do not select a connector, module, addressing arrangement or compatibility answer from appearance alone. Send the relevant question to the party responsible for the specification; keep passwords, authentication secrets and private configuration out of a general enquiry packet.
Separate four readiness states
Use a short status record instead of one “internet ready” checkbox. Each state needs a dated source, an owner and any unresolved condition. A provider’s expected date remains a forecast until the responsible party confirms what has actually occurred. A site team’s readiness report does not certify the provider service.
Order or provisioning status: retain the service reference and the provider’s actual update, identifying whether the information is expected, scheduled or completed. Physical installation status: record which equipment and connection are present at the agreed location, and what remains to be installed. Site readiness: identify the agreed access, space, power and customer-equipment prerequisites and who has confirmed them. Test and handover status: record which agreed checks were performed, their scope and the remaining exceptions.
Keep these states separate when dates change. If a room is inaccessible, that is a site-access issue to resolve; it does not prove the external circuit is unprovisioned. If the provider reports activation, the customer network still needs its own relevant checks. This record describes observed progress rather than assigning fault.
A fictional boundary mismatch to resolve before attendance
Imagine a fictional office whose provider paperwork names a termination point in the ground-floor communications cabinet. The office team plans its customer router in a second-floor rack. Its worksheet currently says only “internet installed.” This example is invented; it is not a DETIAN installation or a measured service outcome.
The useful next question is who is responsible for the connection between those two locations, under which agreed scope, and what information is needed to confirm it. The worksheet can name the two endpoints, reference the current drawing and identify the unresolved ownership and interface questions. It cannot assume that either the provider or the site installer has already included that link.
Once the responsible parties clarify the scope, update the affected readiness items and attendance plan. Preserve the earlier open question and the dated clarification reference. Do not silently change “installation complete” into “service accepted” merely because the missing connection has been assigned to someone.
Agree what will be demonstrated at handover
Ask the parties to agree a small test record before the visit: the point being tested, the equipment and configuration in scope, the method, the expected criterion taken from the relevant agreement and the person who will review the result. This guide supplies no universal speed threshold or substitute service acceptance terms.
Distinguish a check at the provider handover point from a check through the customer router, site network and intended application. Record the actual path used. An application failing to load is an observation to investigate, not enough on its own to identify the provider, router, local network or application as the cause. Similarly, a successful check at one endpoint does not establish every user location’s performance.
For each actual test, retain the date and time, participants, scope, result and any exception in the organisation’s approved records. Record “not performed” when access, equipment or conditions prevented it. Do not fill a blank with the expected result. If a service condition is unresolved, identify the next responsible party and the evidence needed for a recheck.
Prepare the people and documents for the visit
Confirm access arrangements for the specific room and equipment, the provider’s attendance contact, the customer network representative and the person authorised to record the outcome. Ask who must be available remotely if an adjustment needs approval. A list of names does not itself authorise configuration changes; follow the organisation’s existing change and access process.
The handover packet should contain the approved boundary sketch, equipment ownership list, service reference, prerequisite status, agreed test scope and unresolved questions. Keep it limited to information necessary for coordination. Use the organisation’s approved secure channel for any confidential service details; do not include passwords in a general site worksheet or public contact form.
If this work is part of a wider changeover, use the separate go/no-go record for that overall decision. The circuit-boundary worksheet supplies one input and cannot approve the entire office migration. Likewise, a room-by-room connection schedule remains useful for local endpoints, but does not define the external provider’s contractual boundary.
Bring the unresolved boundary to an ICT discussion
For a DETIAN enquiry, prepare the site location, the intended service use, a non-sensitive boundary sketch and the specific scope questions that remain. Explain what the provider has actually confirmed and what is still a proposed date or assumption. Ask which design, installation or coordination work DETIAN can assess for your project; scope and availability require a direct reply.
A clear next step might be resolving who connects two named locations, confirming a customer-equipment prerequisite or agreeing an attendance and test record. It is not a promise of activation or a claim that every internet problem has the same cause. Keep the provider and site responsibilities explicit, then verify the agreed result in the actual handover.
