I have watched a lot of fiber operators go through OSS/BSS vendor selection, and the pattern is almost always the same. The RFP goes out. Vendors return feature matrices full of checkmarks. Demos happen. Everyone says they can do everything. Six months after go-live, the operator realizes the platform cannot actually do the thing they bought it for, at least not without custom development that was never quoted.
The issue isn't that vendors lie. The issue is that feature checklists measure the wrong thing.
What you actually need to know is whether the platform handles your workflow end to end, whether it scales with your operation, and whether the deployment timeline you've been quoted is realistic. None of that shows up in a feature matrix.
Here are the questions I'd be asking, organized the way your subscriber journey actually runs.
Coverage and Order Capture
Every order starts with a serviceable address lookup. If that step breaks, everything downstream breaks with it.
Can your platform ingest our GIS and planning data as the source of truth, or do we maintain address serviceability in a separate system?
Operators who end up with two sources of truth for serviceability end up with sales reps quoting service to addresses that aren't serviceable, and techs rolling to locations where fiber hasn't been built yet. You want one address database, updated from build data, queryable by every sales and service channel.
How do you handle pre-build areas? Can we capture leads against mapped properties before the network is live?
A good platform lets you capture pre-orders against properties in your planned footprint, then automatically converts those pre-orders to active orders the moment the address becomes serviceable. If the answer is "we integrate with a third party CRM for that," you're going to carry handoff risk on every deal.
What channels can capture an order? Door to door, call center, online portal, all with the same address validation?
Multi-channel order capture matters more than most operators realize at selection time. You want sales reps at the door, call center agents on the phone, and customers on your website all pulling from the same serviceability data and creating orders in the same system.
Scheduling and Field Execution
This is where a lot of platforms look strong on paper and fall apart in production.
Is your scheduling optimization AI-powered or rule-based, and can you demonstrate it on a real workload?
Rule-based scheduling works fine for small teams with predictable jobs. It breaks the moment you have to balance technician skills, parts inventory, drive time, and appointment windows at scale. Ask for a demo against a realistic scenario, not a scripted one.
Can technicians work offline and sync when connectivity returns?
Fiber installs happen in rural greenfield areas and inside basements. Connectivity drops. If your field app loses data when the signal does, you are going to lose completions.
How does parts inventory track in real time against scheduled jobs?
Truck rolls that don't complete because a tech arrived without the right ONT are one of the most expensive failure modes in the business. Your platform should know what's on every truck and factor that into dispatch. Everything I've written about removing field service bottlenecks in fiber operations traces back to this visibility problem.
Here's the rewritten provisioning section, clean and ready to paste.
Provisioning and Activation
This is the stage where platforms genuinely differentiate.
Is your provisioning engine hardware-agnostic? Walk us through the OEMs you currently support in production.
You want to hear a clear list of currently supported OEMs across GPON and XGS-PON hardware, with a defined process for adding new ones. A vendor that cannot name the manufacturers they support in production today is telling you something important. Single-vendor provisioning engines also make future network acquisitions and equipment refreshes far more expensive than they need to be, so ask specifically how the platform handles mixed-vendor environments.
How long does service activation take from the technician's mobile device, and what percentage of installs complete same-visit?
Activation time is a real metric. Operators on modern platforms are activating service in minutes while the tech is still on site. Operators on legacy platforms are sending techs back two and three times to complete what should have been a single visit.
Do you support zero-touch provisioning, and what does that actually mean in your platform?
Every vendor says they support zero-touch. Ask them to define it. Ask whether the subscriber's device auto-configures or whether someone in the NOC has to click something. Ask what happens when it fails.
Billing and Revenue
Billing is where most operators underestimate complexity at selection time and overpay for it at deployment.
Can you handle recurring, prepaid, postpaid, and wholesale billing from a single platform?
If you ever plan to offer bulk billing to MDU partners or act as a wholesaler on an open access network, you need this flexibility from day one. Adding it later is a replatforming event.
How does the platform handle promotional pricing, bundle discounts, and plan changes mid-cycle?
Promotional logic is where billing systems quietly break. Ask for examples of how the vendor's existing customers manage this. If the answer involves manual adjustments or custom scripts, that's your answer.
What reporting comes out of the box, and what requires a separate BI tool?
You should be able to see ARPU, churn, conversion rates, and truck roll costs without standing up a data warehouse. If the vendor tells you their reporting is "extensible through our BI partner," ask what that partnership costs.
Platform and Deployment
These questions rarely make the RFP and almost always should.
Is this one platform or multiple products stitched together?
A lot of OSS/BSS offerings are acquired product portfolios with a shared login page. Ask whether the quote-to-cash workflow actually runs through a single data model, or whether each stage lives in a different underlying system. The invisible risk that comes from OSS and BSS separation is real, and it's something I'd dig into carefully during any evaluation.
What's the realistic deployment timeline for an operator at our stage, from contract signature to first live subscriber?
For most greenfield fiber operators, this should be six to eight weeks, not six to eight months. Longer timelines usually signal either heavy customization requirements or a platform that requires significant professional services to stand up.
What happens when we need a workflow change after go-live? Is it a support ticket, a configuration change, or a custom development engagement?
This question alone will tell you more about your long-term total cost of ownership than any pricing discussion.
References and Proof
Every vendor can find one happy customer. You want to hear from customers who look like you.
Do you have reference customers operating at our scale, in our market, with a similar technology mix?
A vendor whose reference list is all tier-one carriers won't work the same way for a regional operator with 40,000 passings. Ask specifically.
Can you show measurable before and after results on metrics that matter? Cycle time, same-visit completion rate, truck roll cost, activation time?
Real numbers from real customers. If the answer comes in the form of a brochure rather than a conversation with an operator, discount it.
What does your customer advisory board look like, and how do customers influence the roadmap?
You want to be working with a vendor whose product direction you can influence, not one where your feedback disappears into a sales team's CRM.
What Good Answers Sound Like
Good vendor answers are specific, quantified, and include examples of real customers. They acknowledge tradeoffs. They're willing to say "we don't do that well, here's what we'd recommend instead." They introduce you to customers without being asked twice.
Bad vendor answers are full of "yes, we can do that" without definition, heavy on future roadmap items, and light on current production functionality. They dodge reference customer requests. They quote professional services hours as the answer to every gap.
The difference shows up within two or three questions if you listen for it.
Frequently Asked Questions
What is OSS/BSS for fiber operators?
OSS (operations support systems) and BSS (business support systems) together manage the full lifecycle of a fiber subscriber, from address serviceability and order capture through installation, provisioning, billing, and ongoing service. In modern fiber operations, the distinction between the two has blurred, and the best platforms unify both in a single system. I covered this in more detail in what OSS and BSS look like in modern broadband operations.
How long should OSS/BSS deployment take?
For a greenfield fiber operator, a modern OSS/BSS platform should be operational in six to eight weeks from contract signature. Longer deployments typically signal heavy customization, legacy architecture, or a vendor that relies on professional services to make the platform work.
What's the most overlooked OSS/BSS evaluation question?
Whether the platform is genuinely unified or a stitched-together portfolio. Operators who buy "one platform" and discover it's actually three acquired products sharing a login page end up paying for integration work they didn't budget for.
How do I evaluate vendor-agnostic provisioning claims?
Ask the vendor to name the OEMs they currently support in production, not on their roadmap. Ask how quickly they can add a new vendor. Ask for a customer reference who has provisioned equipment from more than two OEMs on their platform.
What should vendor references actually tell us?
Before-and-after metrics on cycle time, same-visit completion, truck roll cost, and activation time. If references can only speak in generalities, the vendor has coached them too carefully. Ask specifically about what didn't go well at deployment and how the vendor handled it.
Closing
The OSS/BSS vendor you pick will shape how your operation runs for the next five to ten years. The questions that reveal real fit aren't the ones on the RFP. They're the ones that force vendors to describe your workflow in their own words.
