Customer requests and remote hands

Most of a colocation technician's working day is spent on customer requests. Customers own the servers, storage and network equipment in their racks, but they are rarely on site: Corvid AI's engineers are in another city, Bayview's IT team visits once a month, and the cloud tenant runs Halls B and C almost entirely remotely. When they need hands in the building, they raise a request and a Stonebridge technician does the work. This lesson covers the kinds of requests, how to check that a request is genuine and authorized, how to do and record the work, and where the limits of a technician's role lie.

Kinds of requests

Stonebridge's service catalogue lists the requests customers can make, each with a standard form, a price band and a completion target. The most common are:

• Remote hands: simple physical tasks on the customer's equipment under their direction: power-cycling a server, reseating a cable or module, reading a front-panel display, swapping a labelled drive with a spare they have shipped, taking photos.
• Smart hands: more skilled work, such as replacing a server component following the customer's instructions, connecting a console cable and running commands the customer dictates, or racking and cabling new equipment (DCT-130).
• Cross-connects: a new cable between the customer's equipment and another customer, a carrier or the meet-me room (DCT-210).
• Shipping and receiving: accepting deliveries, holding them, unpacking and moving them to the cage, and returning failed parts (DCT-130, DCT-310).
• Access: adding or removing people from the customer's authorized visitor list, escorting visitors, issuing temporary badges.
• Reports: power, temperature or environmental data for the customer's space, usually from DCIM (lesson 5).

Each request type has a defined scope. A remote hands request covers simple tasks of up to about 30 minutes; anything more becomes smart hands or a project. The catalogue matters because it sets the customer's expectations and the technician's limits at the same time.

Is the request genuine and authorized?

Before any work, the technician must confirm two things: that the request really comes from the customer, and that the person asking is allowed to ask for it. This is a security control, not a formality. A request to power off a server, add a visitor or move a cross-connect, made by someone pretending to be the customer, could be part of an attack on the customer's systems or the facility. Social engineering, persuading staff to do something by pretending to be someone else, is one of the most common ways attackers get into buildings and systems, and a busy, helpful desk is an attractive target.

Stonebridge's rules are:

• Requests come through the customer portal, which requires the customer's login, or by phone or email from a person on the customer's authorized contact list.
• Each authorized contact has a role that says what they may request: some may request remote hands only; some may also authorize access and cross-connects; only a few may authorize equipment removal.
• Phone requests are verified by calling back the number on file, not the number that called, and by a passphrase or a PIN where the customer has set one.
• Requests to remove equipment, add a new authorized contact or grant someone access always need written authorization through the portal from a contact with that right.
• Anything unusual, urgent and from an unexpected person ('I'm new, the usual contact is away, we need this server unplugged and shipped to a new address today') is stopped and checked with the shift lead and the customer's known contacts.

# Checking a request against the customer's authorized contact list
contacts = {  # customer: {name: set of rights}
    "Corvid AI": {"Carmen Ortiz": {"remote hands", "smart hands", "cross-connect", "access", "removal"},
                  "Priyanka Rao": {"remote hands", "smart hands"},
                  "Night NOC": {"remote hands"}},
    "Bayview Credit Union": {"Mira Sandoval": {"remote hands", "access", "cross-connect"}},
}
requests = [
    ("REQ-88141", "Corvid AI", "Night NOC", "remote hands", "portal"),
    ("REQ-88142", "Corvid AI", "Priyanka Rao", "removal", "portal"),
    ("REQ-88143", "Bayview Credit Union", "Alex Moreau", "access", "phone"),
    ("REQ-88144", "Corvid AI", "Carmen Ortiz", "cross-connect", "email"),
]
for num, cust, who, kind, channel in requests:
    rights = contacts.get(cust, {}).get(who)
    if rights is None:
        verdict = "STOP: not an authorized contact; verify with the customer's listed contacts"
    elif kind not in rights:
        verdict = f"STOP: {who} may not request {kind}; needs an authorized contact"
    elif channel != "portal":
        verdict = "verify: call back the number on file before starting"
    else:
        verdict = "authorized: proceed"
    print(f"{num} {cust:21s} {who:13s} {kind:13s} -> {verdict}")

REQ-88141 Corvid AI             Night NOC     remote hands  -> authorized: proceed
REQ-88142 Corvid AI             Priyanka Rao  removal       -> STOP: Priyanka Rao may not request removal; needs an authorized contact
REQ-88143 Bayview Credit Union  Alex Moreau   access        -> STOP: not an authorized contact; verify with the customer's listed contacts
REQ-88144 Corvid AI             Carmen Ortiz  cross-connect -> verify: call back the number on file before starting

The removal request is the one that matters most. Priyanka Rao is a real Corvid engineer with remote and smart hands rights, but removing equipment from the building needs an authorized contact with removal rights, because equipment leaving the site is how data and hardware are stolen. Jamal holds the request, tells Priyanka why, and asks Carmen Ortiz to authorize it through the portal. She does, the same afternoon.

Doing remote hands work

Remote hands work is done with the customer on the phone or chat, or from clear written instructions. The technician is the customer's eyes and hands, not their engineer. The steps are always the same:

• Read the request and confirm the location in DCIM: cage, rack, U, device, port. Check that the device label matches before touching anything.
• Contact the customer if the request needs real-time direction, and confirm the device again with them by serial number or asset tag: 'I'm at rack D-3-07, U22, asset tag CAI-07-22, serial ending 4471. Is that the node you want reseated?'
• Do exactly what is asked, nothing more. If the instructions are unclear or seem risky, stop and ask.
• Take photos before and after where useful: front panel lights, cable positions.
• Record what was done, the times and the result in the ticket's work notes, and attach the photos.
• Confirm with the customer that the result is what they expected, then resolve the ticket.

Confirming the device twice, once from records and once with the customer, is the habit that prevents the most damaging remote hands error: power-cycling or unplugging the wrong server. Racks full of identical servers make this easy to do. Stonebridge's remote hands procedure requires the technician to read out an identifier from the device itself, not the rack position alone, before any power action.

What technicians do not do

The limits are as important as the tasks. Stonebridge technicians do not log in to customer systems with their own accounts, do not choose what to do to customer equipment, do not open customers' equipment beyond the documented field-replaceable parts, and do not move or remove customer equipment without authorization. They do not give opinions about a customer's equipment to another customer, and they never discuss one customer's equipment, traffic or problems with anyone outside that customer. If a customer asks for advice beyond the request, the technician can describe what they see; any recommendation goes through the account team.

Data protection matters here too. Failed drives from customer equipment contain customer data. They are handled under the chain of custody covered in DCT-130: either returned to the customer, destroyed under their instructions with a certificate, or shipped to the vendor only if the customer has explicitly authorized it.

Shipping, receiving and access requests

Deliveries for customers arrive at the dock with a reference number that should match an open receiving request. Tomás Reyes's receiving team checks every delivery against its request, as DCT-130 described; a delivery with no matching request is held, not accepted into a cage. Outbound shipments, usually failed parts going back to vendors or equipment leaving after decommissioning, need a removal authorization in the ticket before they leave the building, and security checks the authorization at the exit.

Access requests are handled with security. An authorized contact asks for a visitor to be added for a date; the visitor must show photo ID that matches the request, is badged and, depending on the customer's arrangement, escorted. Technicians escort visitors in shared halls, as DCT-110 lesson 9 explained, and do not let a visitor into another customer's cage, however friendly or senior they seem.

Completion targets and measuring the service

Each request type has a target time. Stonebridge's are: remote hands started within 30 minutes of a portal request, 24 hours a day; smart hands within 2 hours during business hours; cross-connects completed within two business days; access additions within four hours. As with incidents, the ticket timers track these. Monthly reports show each customer how many requests were made, how fast they were started and finished, and how many met their targets. Customers judge a colocation provider largely by these numbers and by how well the technicians communicate.

# Monthly remote hands report for one customer
from statistics import median
start_targets_min = 30
jobs = [  # (request, minutes to start, minutes on task, first-time right)
    ("REQ-88010", 12, 8, True), ("REQ-88033", 25, 15, True), ("REQ-88051", 41, 10, True),
    ("REQ-88072", 9, 22, False), ("REQ-88090", 18, 6, True), ("REQ-88104", 27, 12, True),
    ("REQ-88119", 15, 9, True), ("REQ-88141", 11, 7, True),
]
met = sum(1 for _, s, _, _ in jobs if s <= start_targets_min)
print(f"Requests: {len(jobs)}; started within {start_targets_min} min: {met} ({met / len(jobs) * 100:.0f} %)")
print(f"Median time to start: {median(s for _, s, _, _ in jobs)} min; median time on task: {median(t for _, _, t, _ in jobs)} min")
redo = [r for r, _, _, ok in jobs if not ok]
print("Needed a second visit:", redo)

Requests: 8; started within 30 min: 7 (88 %)
Median time to start: 16.5 min; median time on task: 9.5 min
Needed a second visit: ['REQ-88072']

The one request that needed a second visit, REQ-88072, is worth reading. The customer asked for a cable to be reseated in 'port 12'; the technician reseated port 12 on the patch panel, but the customer meant port 12 on the server. The work notes recorded exactly which port was touched, so the mistake was found in minutes and fixed. Since then, Stonebridge's remote hands form asks for the device as well as the port.