An assistant that answers
before the ticket gets raised

Discovery first, and deliberately in that order: version 3 of a portal arrives with a long list of requested features, and the fastest way to build the wrong one is to start from the list. Six interviews and a survey came before any screen. The pattern they produced — find, ask, escalate, track — became the information hierarchy, and the hierarchy is what the rest of the design hangs from.

The portal serves Surface field staff worldwide, so the study was built around region rather than role. Six interviews were completed across Japan, China, the United Kingdom and the Netherlands, covering presales, technical support, device specialists and public-sector service. The US round was still outstanding when this deck was assembled — a real gap, and the largest single market.

The tone of the interviews mattered as much as the content. People were not defending the old portal or bracing against a new one — they were volunteering. What they asked for was unglamorous and consistent: make the daily work easier, make help easy to get, and fix ticket tracking. The one feature request that came up repeatedly was search with ticket history in it, which is a search problem and a tracking problem stated as one wish.

Alongside the interviews ran a twenty-question satisfaction survey on the current portal, which took people just under six minutes and came back from most of the group it was sent to. It did the job interviews are bad at: it told us which complaints were widely held rather than strongly held.

The personas were split by region rather than seniority, because that is where the behaviour actually diverged. Both people are new to the portal — three months and six months — which is its own finding: the portal was being judged by people still forming habits on it, and it was losing them to SharePoint before those habits set.

Written down together, these stop looking like six complaints and start looking like two. Everything above the last line is one problem — the portal cannot find the thing you need, in your language, in a form you can take away. The last line is the other one.

Mapping it across six stages — awareness, landing, search and knowledge article, escalation, tracking progress, and the dashboard people fall back on for self-help — put the drop where nobody had been looking. Not at the start. Satisfaction held up while people were searching and reading, and fell off after the escalation was raised, in the stage where the portal stopped talking back.

The hierarchy is where the research turned into structure, and it is the artefact the rest of the project was built against. Two audiences enter it — Microsoft staff and external users — and from the landing page it splits three ways rather than into a feature menu: the knowledge portal, a personal dashboard, and escalation.

Escalation is the half that had been missing. Every request is filed against a real category — warranty and repair, proposals, IRT, CSS, knowledge-portal content, customer questions, and everything else — and every one of them carries the same four verbs at the end: track it, get its status, take an action on it, assign it to someone. That symmetry is deliberate. The old portal let you create in one shape and follow up in another, which is how a ticket goes quiet.

The portal got an assistant. It appears in the file under two names — Genie in the research deck, Mirage in the design work — and it is not a chatbot bolted to the corner of the page. It is a layer over search and request creation that watches what someone is doing and offers the thing they were about to go looking for.

Four visual directions were explored for it: an illustrated character, a plain animated dot, a lamp, and an abstract waveform orb. The character reads friendliest and is the riskiest — this is a tool people use under time pressure in front of customers, and a mascot that is charming on the first day is an obstruction on the thirtieth.

Someone with a question does one of two things: they start typing in the search bar, or they hit “Request help”. Both were mapped against the same scenario — a customer asking whether repeatedly draining and charging a Surface Pro 7 will damage it — and both were designed to end in the same place.

Down the search path, trigger words in the query bring up the answer alongside the results, with the sources it came from. Down the request path, the assistant reads the title and description as they are being written and surfaces the tickets and articles that already match. Then it makes the offer that matters: rather than filing another request, add your customer to the one that already exists — and here is how many other people have done exactly that.

That is the whole idea. A support queue does not get shorter because tickets are answered faster. It gets shorter because the fifth person to hit a known issue joins the existing thread instead of starting a sixth.

Its interventions are placed at the four points in request creation where people stall, and each one has a different job. At the description it offers tips for writing one that can actually be actioned. At the device picker it narrows to the product families that match the trouble described. At the resolution date it explains why the date is being asked for, which is the field people leave blank because it looks like paperwork. At the customer step it matches against MSX opportunity, account ID or name, and offers to add another customer once the request is filed.

The flows also name the exit: machine-to-man transition. The assistant is designed to hand over, not to hold on. In a tool where the person on the other end has a customer waiting, an assistant that cannot get out of the way is worse than none.

The search page had to carry two different kinds of answer without letting either pretend to be the other. Recommendations sit in their own accordion, each with a confidence meter and a thumbs up or down on “was this information helpful?”. All results sit in a second one, filtered by date and split across articles, news feeds and help requests. Both expand into the same tabbed view, so switching between the machine’s pick and the full list does not mean learning a second layout.

The confidence meter is the honest part. A recommendation that is rendered exactly like a search result claims a certainty it does not have, and the first time it is confidently wrong the whole feature loses the room. Showing the strength of the match, and taking a rating on it, is what lets someone use it and disbelieve it at the same time.

The page also keeps the two rails the research asked for: open requests and resolved requests, always visible, so the answer to “what happened to my ticket” is on the screen rather than at the end of a navigation path. And when nothing matches, the page says so and offers to raise the request from there.

The rest of the portal exists to keep people inside it. The landing page leads with the search field and the two things people arrive to do — request help, or learn the portal — then runs a news carousel of product launches and events tagged by team. The footer is doing quiet, deliberate work: popular articles, the resources people were leaving to find, and direct links to the marketing and commercial SharePoints. The links out are still there. They are just no longer the only way through.

Quick links sit above the footer for the four things that were being raised most often anyway — a sales question, a warranty need, a feature request, a messaging request — which turns the four most common escalations into one click instead of a form.

A local library sits in the file behind all of it — an icon set, the header, primary and secondary navigation, the footer, and the colour ramp. It is not a design system in the governed sense and does not pretend to be. It is the amount of structure a portal of this size needs so that three people drawing different screens produce one product.

A portal this size is run by someone, and that someone had no view of it. The admin side was specified as its own piece of design work: what to measure, and what each measure is for.

The segmentation is behavioural rather than demographic — power, normal and casual users by frequency; new, regular, dormant and resurrected by recency — because the question worth answering is not who someone is but whether they are coming back. Alongside it sit the two operational numbers the research demanded: how long it takes to create a ticket, and how many steps it takes to reach a search result.

The frustration metrics are the ones I would defend hardest. Rage clicks, dead clicks, bounces and exits are how a portal tells you it is failing without anyone filing a complaint about it — and the people using this one are busy, in front of customers, and far more likely to leave than to report. A behavioural flow diagram sits beside them to show the path taken to reach a goal, so a spike in frustration can be traced to the screen that caused it.

A user interest score was specified on top of these, computed from those signals rather than self-reported. That one is a proposal, not a finding: a model that labels people positive, neutral or negative carries real risk of being wrong about someone in a way that affects how they get supported, and it would need a lot more thought before it ran on real staff.

The US interviews were never completed, and the US is the largest market the portal serves. Everything on this page about how Surface field staff work is grounded in Japan, China, the UK and the Netherlands, and a fifth region could have moved it.

Localisation was the first pain point recorded and the one the design answers least. Nothing in this work makes content appear in a specialist’s own language; it makes the English easier to find. That was the right sequence, but it means the top complaint from the research is still the top complaint.

And the assistant was designed against a scenario, not against logs. The battery question is a good scenario — it is a real question, asked often, with a real answer — but designing recommendation behaviour without query data means the confidence meter is an interface for a system whose accuracy nobody had measured yet.

This work was done for Microsoft through Neudesic and is covered by a non-disclosure agreement. What is described here is the design process and the reasoning behind it. Performance figures are deliberately absent, and the content visible in any mockup is placeholder — the deck states this itself, and the numbers in the admin screens were written to size a chart, not to report a result.