Colocation Onboarding: From Quote to Racked

The gap between a signed colocation contract and a customer whose hardware is racked, powered, connected and billing correctly is where most datacenter operators lose time, and occasionally lose the revenue entirely. It is not one handover — it is a sequence with a physical dependency at every step.

Here is the sequence, and the four places it usually stalls.

The sequence

1. Quote. Space, power commit, connectivity, IP allocation, cross-connects, remote-hands terms, contract length and any escalator. The quote is the document everything downstream is reconciled against, so every recurring line has to appear on it — including the ones people forget, which are always IPs and cross-connects.

2. Reservation. The moment the quote is accepted, the rack units and the power capacity must be reserved, not merely intended. An unreserved commitment is capacity you will sell twice.

3. Provisioning the space. Rack assigned, PDU outlets allocated, network port assigned, cross-connect ordered, IP subnets allocated from the correct pool for that site.

4. Access. Badge or biometric enrolment, authorised contact list, escort rules. This is a security process with its own lead time and it is not owned by billing, which is exactly why it slips.

5. Delivery and installation. Inbound hardware received, checked against a manifest, racked, cabled, powered.

6. Verification. Power draw confirmed within commit, connectivity tested, IPs routing, monitoring registered.

7. Billing start. The clock starts. Which date it starts on is a commercial decision that must be written down.

The four places it stalls

Capacity reserved in a conversation. Sales commits 5 kW in a rack; nothing in a system records it; two weeks later another deal is quoted against the same circuit. This is the most expensive failure on the list because it is discovered at installation, in front of the customer.

Access enrolment forgotten until arrival. The customer turns up with hardware and cannot get into the building. Start enrolment at contract signature, not at delivery.

Cross-connect lead times. Ordered from a carrier or the facility, they can take weeks. Order at reservation, not at installation, or the rack sits populated and unconnected.

Nobody owns the transition. Sales considers it closed at signature, operations considers it started at delivery, and the two weeks in between belong to no one. Name an owner per order.

When does billing start?

This is the question that generates the first invoice dispute, and it deserves an explicit contractual answer rather than a habit. The four common positions:

• Contract date. Cleanest for you, hardest to defend if installation is delayed by something on your side.
• Space-ready date. Rack, power and connectivity provisioned and available, whether or not the customer has installed. Defensible, because you have reserved and can no longer sell the capacity.
• Installation date. Customer-friendly, and it puts the delay risk on you even when the customer is the one who is late.
• A fixed date agreed in the contract. Removes the argument entirely.

Space-ready with a notification is the position most providers land on, and it works if — and only if — the notification actually goes out. "We were ready on the 3rd" is a weak argument if nothing was sent on the 3rd.

What has to be recorded, not remembered

The through-line of every failure above is the same: a commitment that exists in a person's head or an email thread rather than in a system. The records that need to be real objects are the rack units reserved, the power capacity reserved against the specific circuit, the IP allocations, the cross-connect order and its state, the access list, and the billing start date with its trigger.

If those live in the billing system, the first invoice is generated from the same records that provisioned the service, and it matches. If they live in a spreadsheet and get retyped into an invoice, the first invoice is a fresh opportunity to be wrong — and the first invoice is the one the customer reads most carefully.

The first-invoice checklist

Before the first invoice goes out, reconcile it line by line against the quote. Every recurring item present, at the quoted price. Any partial-month proration correct and explained. Setup and installation fees as agreed. Cross-connects included, and only the ones actually installed. IP allocations matching what was assigned. The billing start date matching the contractual trigger.

Ten minutes, once, per customer. It is the cheapest credibility you will ever buy in this business, because a colocation customer who finds an error on invoice one will check invoice two through twelve just as carefully.

How FluxBilling fits

Rack and U-space, power allocation, hardware inventory and IPAM are in the same records as the customer's service and their invoice, so a reservation is an allocation rather than a note — and capacity that has been committed is visible before it is sold again. IP pools are scoped to deployment locations, so a site's addresses are drawn from that site. The lifecycle run generates recurring invoices from those service records, so the first invoice comes from the same objects that provisioned the space.

Honest limits: FluxBilling does not manage physical access control or badge enrolment, and cross-connect lead times are not tracked as a workflow with carrier states — those sit outside the platform today. Model them as tasks alongside it rather than expecting the platform to drive them.

See DCIM, IPAM and billing colocation.

Closing thoughts

Write the sequence down with an owner and a system-of-record for each step, then check one recent onboarding against it. The steps that turn out to have no owner and no record are the ones that will cost you a reserved rack or a month of unbilled power — and they are almost always steps 2 and 7.