Case study
Why a client cannot find the work you delivered
A client could not see or open work we had just delivered, because the report arrived as plain text with addresses that could not be tapped. What we changed on our own portal and app, and the checks that catch it before a client does.
Key takeaways
- A client judges the delivery, not the effort behind it: if the report is hard to open, the work looks unfinished.
- Every address in a handover should be tappable on a phone, with sentence ends and file names left as words.
- Put what was done at the top of a delivered job and the history of the task below it.
- Read your own handover on a small screen before the client does; it takes a few minutes and catches most of these problems.
- A link to your own portal page is better opened inside your app than handed off to a browser.
A client wrote in to say they could not see what had been done on a job we had just delivered, and could not open any of it. The work was finished and handed over; the way we handed it over was not. That gap, between work done and work a client can find, is what turns a finished job into one that looks unfinished.
Work a client cannot find is work they think you never did
A delivered job that is hard to open reads as unfinished, and the doubt arrives before anyone looks at the work itself. The cost is a message, a call and a day of wondering, and it lands at the worst moment: when your client is forming their view of what you did. In our experience the work itself is usually fine; the delivery is where it breaks.
What our client actually saw
The report was complete. It said where the new pages were and how to use them. But on our client portal and in our app it appeared as one block of plain text in a panel of its own, with the files in a different panel, and every address in it was just words. To open one, the client had to read to the right line, copy the address by hand and paste it into a browser. On a phone, they gave up.
Why it happens to businesses like this
Our engineer opened the delivered request the way the client sees it, on the portal and in both apps. The report was right; the screens were the problem. Nothing was laying the text out, so each screen showed it exactly as typed, and no screen could turn an address into something tappable. Each of them would have needed its own way of spotting a link, so none of them had one. The result of the work also sat below and apart from the request instead of at its top, so the first thing a client met was the history of the task rather than what they had asked for.
Reading the reports we write showed how many shapes a link takes in practice: a full address, but also a bare domain, an email address, and a page in our own portal written the way its menu names it. It also showed what has to stay words — a file name with a dot in it, a version number, an abbreviation, and the full stop at the end of a sentence that mentions an address.
One more thing turned up. A website mentioned in a report only as a comparison was getting a button of its own under the result, right beside the button that opened the client's own work. And in the apps, following any address sent the client out to a browser.
What we changed
We lay out a report once now, and the portal and both apps show that same laid-out version, so they cannot disagree. Its first paragraph becomes the headline, then paragraphs, headings, lists and bold. Every address becomes a real link; the file names, version numbers and sentence ends that only look like one stay as words.
A delivered request opens on one card at the very top, in this order:
- Done, and the day it was done
- what was done, in large type
- the report
- the links to follow, as buttons
- the files
A site named only in passing stays a link where it is mentioned and gets no button. In the apps, a link to one of our own portal pages opens inside the app, other sites open inside the app too, and an email address opens the mail composer. Where a report was translated for the client, they can still switch back to the original. The list of requests now shows each one's result in a line under its title.
Where it stands now
The change went live on the client portal the same day our client wrote in. In the iPhone app it is in the next version, built the same day and on its way to the App Store; the Android app has the same change for its next version on Google Play. Older versions of the app keep working as they are.
What you can check yourself
- Open the last report you delivered on your phone, as your client would, and try to tap every address in it. If nothing opens, the report is words on a screen.
- Look at what a client sees first when they open a finished job. If it is the history of the task rather than what was done, the result is buried.
- Put an address at the end of a sentence in a test report and check that it opens without the full stop coming along.
- Check that the report and the files sit together on a small screen, rather than in panels a client has to hunt between.
- Ask one client to find last month's delivered work without your help, and watch where they stop.
What to do next
Write the handover as though the client will read it on a phone in a hurry, because often they will. Lead with one line saying what was done, then the way to open it, then the rest. Read it yourself on a small screen before you send it, and tap every address in it.
If your portal or app shows reports as a block of text with addresses that cannot be tapped, that is a thing to fix rather than a thing to explain to each client in turn. This was our own portal and app; making finished work open and readable for the person who asked for it is the kind of work our engineers do for clients.
Questions people ask
Why do clients say they can't find work I know I delivered?
Usually because the delivery is hard to open, not because the work is missing. If a report arrives as a block of text with addresses that cannot be tapped, the client has to copy each one by hand, and on a phone many people stop there. Start by opening your own last handover on a phone the way they would.
Should links in a client report open inside my app or in a browser?
Inside the app, where you can do it, because being sent out to a browser to look at your own work is where people lose their place. Links to other sites can open inside the app too, and an email address should open the mail composer. The judgement call is yours; the test is whether a client can get from the report to the thing you made without leaving.
How do I write a handover report a client will actually read?
Put the outcome in the first line, in plain words: what was done, and where to find it. Then the way to open it, then the detail. Short paragraphs, headings and lists are easier on a phone than a wall of text, and every address should be tappable.
What should appear first when a client opens a finished job?
One line saying it is done and the day, then what was done in larger type, then the report, the links and the files. The history of the task belongs further down, because it answers a question the client is not asking yet.
Do older versions of an app stop working when the handover screens change?
In this case they kept working as before, and the new layout arrived with the next version. When you change how clients see their work, it is worth asking whoever looks after your app what happens to people who have not updated yet, rather than assuming everyone sees the new screen.