BT Wholesale

Client
BT Wholesale. London 2017-2019

Brief
To troubleshoot and if necessary redesign the fault reporting journey for BT Wholesale’s B2B customers across the BT Wholesale product site in order to increase the efficiency of the repairs process

Challenge
With a limited budget to fix a cumbersome and outdated system, a full rebuild was not an option. Instead, targeted troubleshooting, limited to the system’s front-end interface, driven by contextual research and BT business customer user interviews would be used to improve upon the existing journey

Solution
A seamless journey for BT Wholesale’s business customers to report faults to BT quickly and efficiently, when their end customers contact them to report service issues. The amended journey, based on key insights from research, allowed BT Wholesale’s B2B customers to skip unnecessary steps, enable fast input of data and editing of fault tickets, avoid previous issues caused by human error, and be kept up to date on any ongoing progress of faults with a design overhaul of the current communication process. This resulted in BT Wholesale’s B2B customers being able to deal with their own customer’s inquiries more efficiently without the need to chase BT Wholesale engineers directly for progress updates

Duration 
12 weeks

My Role
Lead UX Designer. My responsibilities included:

User interviews | User journeys | Working with technical teams | Contextual research | User interview scriptwriting | Design studio sketching | Wireframing | Paper prototype design | User testing | Iterations | High fidelity designs on Sketch | Design of presentation slide templates | Presenting insights from research and wireframe designs to key stakeholders

 Tools
Invision | Sketching | Sketch | Trello Kanban board | Google Drive

Methodologies Used
Stakeholder interviews | Daily stand ups | Contextual research | User research and interviews | Usability Testing | Customer journeys | Wireframes and sketches | Clickable prototypes

Team
Claire Donohue (UX/UI) and Philip Morely (PM) from BT Wholesale 

The Kick Off Meeting: What we Know and What we Don’t

The project kicked off with a number of key stakeholder meetings. We were given the opportunity to listen to stakeholders and product owners from within BT Wholesale about issues raised by their B2B customers around the fault reporting capabilities of the BT Business Zone website. During these early meetings, we were shown walk throughs of the existing fault reporting process to understand how the system was currently being used and made aware of any issues that had already been reported back to them from their business customers.

The Current Fault Raising Journey: A Lengthy Process

The existing fault-raising process consists of roughly six steps through BT’s Business Zone website, where users can log and raise faults, communicate any updates through the site’s notes feature, place new business orders and amend existing ones. However, focusing on the raising a fault process, the steps to raise a fault are as follows:

1. Business Zone - Once a BT Wholesale B2B customer (our user) is made aware of a fault on their end customer’s service. The user will log onto Business Zone, a business to business site accessible by BT and their immediate business customers in order to communicate any issues, manage existing customers and place new business orders. The user will search for their end customer in the search bar located at the top of the page and will select the customer from the displayed list.

2. Quick view - The user selects the ‘quick view’ from the search result drop-down, a pop up containing additional information on the end customer and the different levels within it (i.e. a single member experiencing problems, or an entire office or companywide problem) the user will select to ‘raise a fault’ against the correct level of user (i.e. Is the whole business internet service down or is it just an individual experiencing problems with their voicemail capabilities?). 

3. Diagnostic questions - Once the level of customer is selected, the user is displayed two or three ‘diagnostic questions’ before they can start the process of raising the fault.
a. What the ticket relates to.
b. If the fault can be fixed using external handbooks or the online help guide section on the site
c. The user is then asked ‘Is your problem solved’. where they more often than not will select ‘no’
d. They can then select ‘continue to raise fault’

4. Provide details page - The user is displayed a ‘fault or query details’ page. Where they can enter the fault title, customer reference, choose the severity (or urgency in which that fault needs to be resolved), add any notes relating to the fault, attach supporting documentation, add relevant contacts (for example the details of the end customer for BT to gain access if the fault needs to be dealt with on site directly) and click ‘next’.

5. Review page - The user is displayed an overview of fault details they have just added, and given the opportunity to make changes. They can then click ‘submit’ to send the fault to BT. 

6. KCI (Keep Customer Informed) emails and communications from BT - User will receive three emails from BT. One to say fault has been submitted, another to say fault has been accepted by BT and a third to say someone is dealing with the fault or query.

Our Process: Getting Back to the Floor With Contextual Studies, Shadowing and User Interviews

During the discovery phase of research, myself and Philip Morely travelled up and down the UK to visit over 14 of BT Wholesale’s business customers, including larger scale businesses such as Virgin Media, Claranet and Daisy Communications and some of the smaller outfits such as Aastha and IDNet which consisted of solo offices supplying local businesses with communication hardware, phone and internet systems. 

I carried out user interviews with team leaders, managers, service desk analysts, specialists, engineers and system coordinators in their places of work. We observed them as they carried out their usual tasks to help their end customers with connectivity and hardware issues, using BT Wholesale’s Business Zone website in order to communicate these issues back to BT Wholesale’s engineers to be fixed within a fixed deadline. In addition to the contextual studies and user interviews, we also asked the interviewees to carry out tasks and walk us through their process in order to uncover any unknown issues and pain points as well as gain clarity on why issues that had already been reported back to BT Wholesale were happening.

Guided by the early kick off stakeholder interviews, we would focus our user interview questioning around the following touch points:

• How faults are raised

• How faults are tracked once raised 

• If there is an escalation process for faults that are not resolved

• Positive and negative experiences with fault reporting

• Systems used to raise and track faults

We would later use the findings unearthed from this research to create wireframes and prototypes, targeting key pain points and providing a smoother journey for business customers to raise any faults back to BT Wholesale.

User Interviews and Contextual Studies: Uncovering the Root of Known Issues and Unearthing new Ones

To ensure we were covering all areas of the journey and fault reporting process, I drafted a user interview script to guide the session. This contained targeted questions around known issues, requests to walk us through how they would report a fault, as well as looser open questioning to shake out any issues that the stakeholders may not already be aware of to help us improve the journey for their business customers. Additional time was also added to the interviews with each employee to allow for more exploration of unknown problems during the session.

Analysis: Telling a Story Through Collated Quotes

Once the interviews were complete we documented pain points across from each company into a spreadsheet to show the issue, any quotes from interviews relating to them, together with time stamps for the recordings and suggestions to be implemented.

Experience Map: Highlighting six key Pain Points From our Study

Key pain points and user issues uncovered during our research were highlighted to stakeholders through the use of experience maps, user quotes, and presentations.  

Key Areas of Focus and Pain Points from User Interviews and Contextual Studies

While there were many areas of focus to improve the journey for users to submit faults and communicate updates to BT. There were a few that stood out and needed urgent attention which had been causing particular frustration for users. I highlighted these to the stakeholders who agreed that these would have the biggest impact on customer satisfaction. These are listed below:

Pain Point Example One: Unnecessary Hurdle of Diagnosis Questions

Users felt that these questions did not relate to their fault and slowed them down. Users would not look at help and tips or the document center at this point as they would have already tried to troubleshoot any issues before contacting BT, instead, these questions, especially the one asking if the fault had been resolved felt like unnecessary steps to get to the ‘provide details’ page. 

User Comments:

“These are just steps I've got to do to get where I need to be”

“From my point of view, all of that is irrelevant, I just want to raise a fault. I just want to get to the point where I can raise a fault, I don't want to be asked has this resolved your question, yes there are help and tips here, but with the knowledge that our team and support team has, I've already been through all of that” 

“I've just been given four steps that slow me down”

Pain Point Example Two: No Helpful Company Information at the top of the ‘Provide Details’ Page

Display information at the top of the ‘provide details’ page showed the B2B customer’s own details and reference, not that of the end customer experiencing the fault. Therefore information was geared towards helping BT’s staff and was not helpful to the user themselves. It was easy for the user to forget which customer they were even raising a fault against if they become distracted during the process of raising a fault.

User comments:

“There is nothing on that screen to tell you which company we are talking about. There is nowhere in there that tells you who I've opened it up against”

Pain Point Example Three: Misalignment of ‘Severity’ Level Understandings Across Customer Base

The severity drop-down on the ‘provide details page’ gave four options of severity one to four. A ‘severity one’ requiring immediate attention to a ‘severity four’ which had no urgency and was usually reserved for general queries. Each individual we spoke to appeared to have a different understanding of what each of the severities represented. Additional user frustrations arose when BT would then lower the severity from their end as they felt the fault did not match the assigned level. There were a wealth of discrepancies when speaking to users about their understanding of what the different severity levels actually meant. 

User comments:

“I don't actually know what the severities are, I mean if I select one, will BT come out, sirens blazing? If I pick four, will BT ignore my ticket?”

“Giving someone the option of 1,2,3,4 - if they personally think it's a big issue they'll choose number 1, as it's the highest priority”

Missing notes when unattached to ticket

Users would often write notes in the open text field on the page and click ‘next’ forgetting to click ‘add note’ next to the text field. The ticket would then be sent across to BT without the note details, these would be lost. The user would not be able to re add the note until the fault was live on the system by which point, BT will have already alerted them to the fact that there are no notes attached to outline details of the fault. Something that infuriated users.

User comments:

“If you put your notes on there and just carry on [without clicking ‘add note’], it doesn't give you a warning or anything, it just carries on. I did this like twenty times when I first started using it!”

Unclear overview of notes

Users found the current layout of existing notes difficult to read and expressed not being able to see a clear overview of historical notes which contained back and forth dialogue between themselves and BT engineers dealing with the fault. The character limit per note meant that notes were often spread across multiple entries with odd spacing making them difficult to read and only being able to open one note at a time made it hard to locate a particular entry.

User comments:

“The character limit could do with being increased I think, when you've got a particularly awkward fault”

“Note 1’ doesn't tell you anything. You can imagine, when this starts to build up and there are 20 notes interlaced with their responses, we have no idea of what the dialogue is and where we have to jump in?”

Pain Point Example Four: Users Inadvertently not Submitting Fault Due to Hidden Call to Action and a Hard-To-Differentiate Submit and Review Page

Even experienced users would occasionally assume the review page was the submitted fault and miss the ‘confirm’ button at the base of the page (hidden beneath the fold), meaning the fault was not logged at all with BT. Users only realised this when no KCI email was received and the reference pulled up no results when later searching for it. 

User comments:

“So many times I thought I had logged a ticket, and then I'd call them up [BT] and have to ask them where it had gone, they would then ask me if I had clicked confirm”

“I press next, get distracted by something else, then two days later I can't find the ticket. I've got a reference but why can't I find it? Because I never clicked confirm”

Solutions: How Might we Minimise Human Error and Reduce User Frustration?

After reporting our research findings through presentations back to the directors and stakeholders at BT Wholesale, we suggested ways to resolve the various issues being experienced across their business customer base. Based on our findings and improvement suggestions, BT Wholesale made the decision to significantly increase the budget to allow us to make the necessary changes to the site to create a fit for purpose tool, removing frustrations, minimising human error, and allowing a smooth and snag-free experience when raising a fault. This would significantly increase productivity levels and communication lines between BT engineers and BT Wholesale’s B2B customers.

The following solutions were suggested to BT Wholesale and implemented into the Business Zone site.

Solution One: Removal of Diagnostic Questions

Solving the issue of unnecessary steps prior to accessing ‘raise a fault’ page

New designs allowed the user to skip diagnostic questions and go directly to the ‘raise a fault’ page to start the process. The diagnostic questions were deemed irrelevant and were viewed across the board as slowing the process down unnecessarily. Users could now use the master search tool (Marked as 1 in wireframes below) or inventory tab to locate the customer. Click ‘view details’ (Marked as 2 in wireframes below) in order to open the ‘quick view’ and select the customer level (Marked as 3 in wireframes below) where they can then select ‘raise a fault’ (Marked as 4 in wireframes below). This will skip the diagnostic questions seen in the existing journey and take them directly to the ‘raise a fault’ page.

Solution Two and Three: New Customer Information Display and Severity Level Indicator

Solving the issue of the user losing track of which end user they are raising the fault against

A new customer information and ticket information display at the top of the ‘raise a fault’ page was added in order to keep both users and BT engineers informed of who the fault was being raised against (marked as 1 on the wireframes below).

Solving the issue of the user raising the fault under the incorrect severity level

The format of BT Wholesale’s long misused level one to four severity system was exchanged in favour of a descriptive selection drop down. In-page help was also offered to the user through a help icon sitting alongside the drop-down (marked as 2 on the wireframes below), which when clicked would open up an in-page pop up (marked as 3 on the wireframes below) detailing further information and examples of what the different severity types could relate to.

Solution Four and Five: Notes and Submit Buttons

Solving the issue of notes spread across multiple entries and human error of submitting a fault without attaching the note to the ticket.

In our proposed designs we made allowances for a much larger character limit of 3,000 up from 500, which we based on note length data provided by BT Wholesale. This would avoid the need to spread notes across multiple entries and therefore this feature could be removed. The new design meant that any notes entered in the field when the fault was submitted would be automatically uploaded to the ticket (marked as 1 on the wireframes below) and there was no longer the need to click ‘add note’ before doing so.

The redesign of how historical notes were displayed was also changed to avoid the user having to needlessly search across entries unhelpfully marked as ‘note 1, note 2’ etc, this would now be a scrollable text display where users could easily scroll through note entries in date order, displayed with the together with the title of the note, to easily get an overview of a conversation between themselves and BT engineers working on the fault (marked as 3 and 4 on the wireframes below).

Solving the issue of users accidentally not submitting the ticket to BT.

Where accidental non submission of the ticket was concerned, we redesigned the journey so that there was no longer a need for this page additional step to submit a fault. Instead, the user could submit the fault directly from the ‘raise a fault’ page where we added an additional submit button to the top as well as the bottom of the page so the user could scroll back up to check their entries before proceeding to click ‘submit’ (marked as 2 on the wireframes below). The confirmation page which followed (not pictured) would then allow them to either return to the home page, print the details, or return to see an overview of the fault, where they would be able to make amendments without the need for BT to formally accept the fault first (the view fault page is shown below on the right).

The Final Design: Keeping the User Informed With Clearer Data Display, a Faster Streamlined Journey and Transparency Between BT and their Business Customers as Faults are Being Resolved

The final designs allowed for faster and more efficient input of data, with helpful display information to ensure the user was always kept aware of what process they were carrying out and for whom.

By removing unnecessary hurdles which created allowances for human error and the removal of redundant additional steps we increased productivity and communication clarity between BT engineers and their business customers, ultimately shortening the timeframe in which faults were actually being dealt with for the end consumer. Delays due to snags in the journey such as information not being carried across within the ticket notes section or misaligned understandings of severity levels between BT and their users were also rectified in the new designs and therefore also minimised any delays in faults being dealt with. While the new easily digestible historical notes view meant that a user checking the progress of another user’s reported fault, could quickly understand the progress with a clear overview of progress and communication.

The final designs were tested internally with users and proved to be very popular with BT Wholesale’s business customers, a design specification and Invision prototype were provided to the BT digital development team in order to be built into the Business Zone site.

Next Steps

As with any end to end process, there can be certain aspects of the journey that fall out of scope. Even with the addition of a significant budget increase to accommodate the additional and very important findings that came from our two months of research, there were still a couple of additional fixes I would have loved to have seen implemented.

• Severity override - Even with users and BT engineers now aligned on severity level meanings, I felt it important to add the ability to override this, in rare instances where a certain customer might need something dealt with with more urgency than is usual. For example, a phone system feature down such as automatic recording of calls on BT equipment might not be deemed as a major issue where severity is concerned. However, should that end customer be a law firm that relies on recordings from calls for legal purposes, then this can be detrimental to their business and should therefore be treated with a higher severity level than is the norm. My suggestion would be to add an override option with a text box to explain the reasons within the ‘raise a fault page’.

• KCI Emails - The ‘Keep Customer Informed’ emails that the user received in their inbox as their fault was accepted and progressed by BT was deemed by users to be unhelpful and overwhelming. With three emails being issued before the fault had even been accepted, this was clogging up the user’s inbox and not even providing enough information to be useful. I would have loved to have had the opportunity to explore this further and streamline these emails, make them more informative to remove the need for the user to have to log into the fault ticket to see what update had been made. This was raised with BT as a future project to budget for.