|
EE creates multi-tiered customer experience with 50p call queue-jumping charge |
||||||||
The mobile operator Everything Everywhere has recently caused a bit of controversy by introducing a 50 pence call fee for customers who want to jump the call waiting queue. This is available for Pay monthly (Contract) and sim only customers.
This raises some interesting questions and issues, specifically about the split in the customer base because of this. EE have effectively created a tiered customer service system with this move. Intentional or not they now have priority customers and second class customers.
Why not allow this for all your customers?
This is likely due to the spending profile, when you look at the different spending profile for Contract and pay-as-you-go customers the latter are far less likely to spend money on a premium service. Their PAYG habits mean that they are less likely to require support, and far less likely to pay for it, it typically has a more independent nature.
The dangers of a two tiered customer experience
Allowing some customers to jump the queue raises difficult questions around customer priority, and service levels. If I already have a contract that I am paying reasonable money for, why should I pay more for a support service?Also is this queue jumping pushing other customers back? Probably. At the same time, if this is viewed as a revenue stream to EE, doesn't that encourage them to present the outward view to the customer that they are very busy, and that you should be paying for a premium service? Chances are the call centre staff are being measured on how many 'paid customers' they service rather than 'free' this will be a new KPI. By creating a bigger gap between the paid and non-paid service they can outwardly justify the fee. You can call them and receive free service, but you might be waiting a REALLY long time.... Or you could pay 50p to skip the REALLY long queue and talk to an agent sooner.
Whether this is real or not is debatable, but it does show that by creating two customer experiences ('we a care a lot because you paid' and 'we don't care because you're free') you are creating a dangerous class divide.
I'm really hoping that this isn't a trend and that other call centre providers don't follow suit. News article here: http://www.mobiletoday.co.uk/news/industry/30471/ee-introduces-50p-call-queue-jumping-charge.aspx
|
The difference between Architecture and Design |
||||||||
In the last few weeks I've had many conversations with Architecture colleagues about the differences between Architecture and Design. These conversations don't typically start with this question, but more likely about the content of specific deliverables such as documents or strategy papers. Typically as an Architect you are required to deliver guidance on solutions as part of a project cycle, or as part of a larger overall programme. The point at which that guidance changes from 'Architecture' into 'Design' can be quite a contentious one.
For me, as an Architect, my responsibility is to guide the Strategy and direction of a project in terms of the technical aspects. I am effectively the technical manager, governing the direction that a project proceeds in. So how is that different from designing the solution yourself?
I like to think of Architecture as:
"Performing Governance and assurance around a solution to ensure that it aligns to Architectural principles, Strategic concerns and established patterns, in an elegant and cost effective way."
In plain English this is formulating which architectural principles are relevant and applicable, which patterns (in terms of both technical design patterns or business process patterns) are relevant and lastly whether there is an overarching strategy or strategies that drive the direction. It is effectively a set of rules, constraints and measures to guide the further direction of a solution (whether that is a project or a programme). It IS NOT the actual design of a solution but rather the instruction set that a design should use to build their design. When Architectural Governance kicks in and I review a designers design documentation, this is the rules set that I use to effectively 'mark their homework'.
Now, if we have defined the Architecture side of this argument, we should really do the same for the design side. This is a lot more real-world and far less abstract, normally because it is much easier to visualise than 'Architecture' is.
"Design is the process of collecting and placing business and technical building blocks to enable business capabilities."
Again, in real terms this means finding vendors, products and technical elements that fulfil as many of the identified requirements as possible, and arranging them in such a way as to enable an end to end business capability, usually by combining many simpler capabilities into a larger one.
Thinking of Architecture and design in this way makes it very easy to see where the boundary between these separate activities lays, which in turn means it becomes far simpler to see where any handover between resources should be, or where responsibility within a project lies. This sort of clarification also really helps to define the boundaries of an Architectural role, allowing them to focus on specific Architectural deliverables.
