“Everything starts with the customer.”
It just dawned on me today that OSS requirement definition never seems to start with the customer. It always starts with the CSPs operators and their needs.
That sounds logical, since they’re the ones who will use it the most.
But how many customers have had terrible experiences with their CSP, including the following examples:
- If a fault exists with your service, it’s your fault (ie it’s wiring at your house, you’ve incorrectly set up your device, you’ve tampered with something, etc)
- You’re asked to punch in your phone number or account number before being put in touch with the CSP’s operator and you spend the next X hours being re-directed from one operator to the next, each re-asking your number, your details, your problem, etc
- You’re given vague service times (eg Wednesday am), yet the technician misses the time, multiple truck rolls are required, etc and your planned schedule has been blown apart and now has to revolve around the CSP until they are finally able to deliver
- Your issue is logged, a ticket number is assigned, but then mysteriously lost and then has to be re-logged with the SLA clock re-started (the KPI shuffle anyone??)
- Your CSP is unaware that your experience has been so poor because it has no ability to track across separate operators, channels or systems
- Your CSP will almost never issue any apology or seek to make up for the inconvenience caused
So, should a CSP implement an extensive mystery shopper survey to find out where their systems and processes are broken as the first step of defining their OctopOSS requirements?
Is it up to the CSP to initiate with their customers or can the implementation team (eg vendors / integrators) build their own market by improving the experience of their customer’s customers? Do they take the CSP down this path as one of the project deliverables?
When a vendor or integrator is analysing UX (User Experience), is it imperative to look at the UX of the customer’s customer or just the customer’s operators?