Taking the Signal to the Owner Without Making an Enemy

Thursday, 15:45, at Bluewater Bank. Lena has the evidence and it is good. Sixty-one tickets in a quarter from the lending team about a loan report that fails whenever the month-end batch is running. The batch runs on the last two working days. The report could run on the first working day of the next month instead with nobody worse off. The schedule belongs to Gareth, the operations manager, whom Lena has met twice. She has drafted the e-mail. The first draft begins "Your team's month-end report has caused sixty-one tickets this quarter." She reads it back, hears it in Gareth's voice, and deletes it. The second draft begins "We've noticed something that might save your team a couple of hours a month." That one gets sent. The two drafts contain the same sixty-one tickets, the same schedule and the same ask. The difference between them is this article.

Taking a signal to its owner means handing a pattern the desk found in the queue to the person outside IT who can change the thing causing it. It means doing so in a way that gets the change made and leaves the owner glad the desk told them. The first half is a document and the second half is a manner. Desks that are good at the document and bad at the manner get a reputation for being right in a way nobody wants to hear from again. This article is part of our Ticket Data as Organisational Intelligence series. The three signal articles before it each end with a brief, and this one is about what happens to the brief once it leaves the desk.

It starts with why the desk arrives as an auditor whether it means to or not, finding the right owner, and the brief. Then come the tone, in five rules, the ask that is small, and the meeting, if there is one. Next are the follow-up, the path drawn as a picture, and what to do when the owner says no and the signal keeps coming. A short war story and the signal handover note to copy finish the article.

Why the Desk Arrives as an Auditor

The desk has data about another team that the team's own manager has never seen. There is no way to present that which does not feel, for a moment, like an inspection. The manager hears "we have been counting your team's tickets" and the counting is the problem, before a single number is read. Managers are used to being measured by their own boss. Being measured by a department they thought of as the people who fix laptops is new, and new is alarming, and alarmed people defend first and read second.

Three sentences turn a colleague into an auditor, and most first drafts contain all three. "Your team keeps raising tickets about this" makes the tickets the team's fault. "We have had to deal with sixty-one of these" makes the desk the victim. "This is costing IT twelve hours a month" makes the cost IT's and the manager's team the cause. Each is true, and each tells the manager that the desk has arrived with a grievance. A manager who hears a grievance looks for the flaw in it, finds one, and the sixty-one tickets go unread.

The manner that works is the one a good colleague uses when they have noticed something: "I saw this, I thought you'd want to know, here's what I've got, here's one thing we could try." The desk is not reporting the team. It is reporting a pattern that is costing the team time, to the person who can stop it, with the desk's own part already done. The data is the same. The desk has simply decided whose side it is on, and said so first.

Finding the Right Owner

The owner is the person who can change the thing, not the most senior person near it. For a schedule it is whoever sets the schedule; for a form it is whoever maintains the form. For training it is the manager of the people who need it; for an application it is the business owner who pays for it. Sending the brief one level too high gets it forwarded down with a note that reads as a reprimand to the person who should have received it directly. That is a poor start. Sending it one level too low gets a sympathetic reply from someone who cannot act, and a second brief later.

When the owner is unclear, ask your own manager to find out, and never guess upward. When the owner turns out to be a peer of your own manager, or above, send the brief through your manager. That way it crosses at the same level and arrives as a conversation between managers rather than a technician's note to a director. The brief itself does not change. Who signs it does, and the signature is most of what decides whether it is read as help or as audit.

Never go around the owner. If the owner is briefed and declines, the next step is the quarterly review, which the owner knows exists and can attend. It is not an e-mail to the owner's boss. The one exception is where the owner cannot be found at all. In that case the brief goes to the nearest manager with a line that says the desk could not identify who owns this process. It says the desk would be grateful to be pointed at them. That line is often the most useful thing in the brief. Many processes have no owner until someone asks.

The Brief: One Page, One Ask

The brief is one page, because an owner reads one page between two meetings and files two pages for later, where later does not come. Its shape is the decision brief in Explaining Technical Things to Management, with the technical mechanism left out entirely. The owner does not need to know how the desk found the pattern, only that it is real. The three signal articles each give a brief tuned to their signal. The shape underneath is the same: what we are seeing, what it costs you, what it costs us. What we have already done, the one thing we are asking, when we will count again.

What goes in: the pattern as a count per run or per quarter, with the period. The cost in hours to the owner's team first and the desk second, as ranges. Three example tickets with requester names removed and dates left in. The desk's own part, already done; the single ask; the date of the re-count. The language is the owner's, not the desk's. Translating "sixty-one tickets" to "about two hours a month of your analysts' time, and a report that is late to the credit committee three months in four" is the subject of Translating Tickets into Business Language. Write the brief in the words the owner would use to describe the problem to their own boss, and they will.

What stays out: every name except your own; every adjective; the desk's theory of why the team does what it does. Any comparison with other teams; any second ask; and any sentence that would make sense only to someone who runs a help desk. If the desk has a theory, it goes in one line at the bottom marked as a theory. That gives the owner something cheap to disagree with and leaves the count untouched. The count is the brief. Everything else is packaging, and packaging is what gets the brief opened.

The Tone: Five Rules

Five rules govern the tone, and they can be applied to any draft in ten minutes with a pen. Lead with their time, not yours; the first number in the brief is the owner's team's hours. Counts, not adjectives; "sixty-one in a quarter" rather than "constant", "a median of four working days" rather than "ages". The process is the subject, never a person; a sentence whose grammatical subject is someone's name is rewritten until its subject is a step. Offer, never demand; every ask is phrased as something to try, with a date to look again. And assume they did not know, because they did not. Nobody downstream has counted this before, and the brief can say so, which turns the surprise from an accusation into news.

Read the finished draft aloud in the owner's voice, as Lena did, and listen for the sentence that makes you wince. There is nearly always one. It is usually the sentence that was most satisfying to write.

The Ask That Is Small

The ask is one change, small enough to say yes to without consulting anyone, reversible, and dated so it can be counted. "Run the report on the first working day instead of the last" is small. "Add a deputy approver for this request type" is small. "A start-date field on the form" is small. "Review the month-end process" is not small, and will be agreed to warmly and never scheduled. It has no date, no owner of its own and no way to tell whether it happened.

Small works for three reasons. A small yes costs the owner almost nothing, so the brief's first outing ends in a yes rather than a debate. A small change produces a count within a run or a month, so the desk comes back with a result rather than a reminder. And a result builds the credit for the next ask, which can be larger. The owner has now seen the desk be right once and leave them looking good for it. The large ask, the redesign or the replacement, comes after the second or third count, from an owner who now brings the desk's numbers to their own meetings. Nobody has ever been talked into a redesign by a stranger. Plenty have asked for one after a stranger made them look thoughtful.

Where the small ask is refused, offer a smaller one, down to "could we count it for one more quarter and look together?" That is an ask almost nobody refuses and it keeps the finding alive without any change at all. The desk's patience is its main advantage in this work. Processes do not change at the speed of a brief. They change at the speed of a count that keeps arriving.

The Meeting, If There Is One

Many briefs are settled by reply and need no meeting, and the desk should not ask for one unless the owner does. When there is one, it is twenty minutes. It has the shape the hotspot article describes for the owner conversation in Application and Process Hotspots: the count, the ask, the offer to count again, and the brief left on the table. The desk does not argue. If the owner objects, the objection is written down as data, because it usually is. "It works fine for me" is a per-user reading waiting to happen, and "we tried that" is a history the desk did not have.

Bring the three example tickets and nothing else. The temptation to bring the full export, the spreadsheet with the pivot tables and the chart is strong, and it should be resisted. A spreadsheet in a meeting is an invitation to audit the desk's method rather than read its result. If the owner wants the method, they will ask, and it can be sent afterwards. (They will not ask. They will ask what the three tickets were about.)

The Follow-Up

The follow-up is the count after the change, on the date the brief promised, sent either way. If the change worked, the message says so, in counts, and thanks the owner. In that case the desk also tells someone else, which is where the credit does its work, as Making the Invisible Work Visible describes. "Finance moved the report and the month-end tickets dropped from twenty to three" is a sentence worth saying in a leadership meeting with finance in the room. It costs the desk nothing and buys the next brief a reader.

If the change did not work, the message still arrives, still in counts, with no comment beyond "we're not seeing the drop we hoped for; would it be worth looking together?". A change that was tried and failed is a finding of its own and belongs in the quarterly record. A follow-up that only arrives when the news is good teaches owners that silence means failure. They will start to dread the desk's e-mails, which is the opposite of the point. Send the count every time, on the date, whatever it says. Reliability is most of what makes the desk worth listening to, and it is built one unremarkable follow-up at a time.

The Path, Drawn

The picture below draws the whole path from a pattern in the queue to a brief in the owner's hands. It shows the three gates a finding has to pass on the way. The first gate asks whether the pattern is real: enough tickets, not one week, repeating across people and surviving a per-head check. The second asks whether it is the desk's to fix: if the desk can fix it, it does, and if not it names the owner who can change the step. The third asks whether the ask is small: one change, one owner, a date and a re-count, with the owner's hours before the desk's. The dashed line is the edge of IT, which the brief crosses and the desk's opinions do not. The arrow back from the owner to the pattern is the follow-up, which is the only part of the path that runs in both directions.

Most findings fail at the first gate, which is the correct place for them to fail, and go back to the watch list to be counted for another quarter. A finding that passes all three and still does not get its change has not failed; it has met an owner who said no, which is the next section.

When the Owner Says No and the Signal Keeps Coming

Owners say no, and the first no is accepted without argument. "Thanks for looking; we'll keep counting and let you know if it changes" is the whole reply. The desk's own part continues, the known-error article, the template, the form field, because those are the desk's to do regardless. The standing ticket stays open. The count keeps arriving, monthly, into the spreadsheet, and the finding sits on the quarterly list with the status "briefed, declined" and the hours per quarter beside it.

The second quarter is where patience pays. Suppose a finding was declined and its count has not moved. It is reported in the quarterly intelligence review, in the same neutral line as every other finding. The pattern, the cost, the owner by role, the ask, the status. Leadership sees it beside the findings that were accepted and fixed, which is the most persuasive context a declined finding can have. The owner has not been gone around; the review is a standing forum the owner knows about and can speak in. If you run QuerySolv, the standard report on volume, filtered to the department, shows the count month by month. Then the second brief carries a trend line rather than a complaint. Most tools can produce something similar from an export, and the trend is what moves a second conversation that the first could not.

Some findings stay declined for a year, and that is an outcome, not a failure. Leadership has seen the cost and chosen to carry it, knowingly, which is a decision the organisation is entitled to make and which the desk has made visible. The desk records it, keeps the workaround efficient, and moves its attention to the findings that can move. A desk that spends its credibility fighting one declined finding has none left for the five that would have been accepted. Pick the battles the count can win. Let the review carry the rest.

A Short War Story: The Nightly Export at Greyfriars Hotels

Greyfriars Hotels ran a booking system whose nightly export to the accounts package failed roughly two nights in three. Each failure meant a night porter phoning the on-call technician and the technician restarting the export by hand. The porter re-keyed the day's arrivals for about an hour while it ran. Ola, who ran the desk, took it to the revenue manager by e-mail with the line "your team's nightly export is breaking most nights and we are tired of restarting it at one in the morning". That was true. The revenue manager, who had not known the export ran at night, read it as an accusation and did not answer. The export kept failing for six more months. It cost about sixty hours of on-call time and something like a hundred and eighty hours of night porters' time before Ola left and Dev took over the desk. Dev rewrote the same finding as a one-page brief that opened with the porters' hour a night. It listed the count from the ticket history, attached three tickets and asked for one thing. Could the export run at eleven, before the accounts package's own overnight job, for a month? The revenue manager changed the schedule the following week. The export failed twice in the next month, and she asked Dev whether the desk had noticed anything else about her systems. The finding had been the same for seven months; only the first sentence had changed, and the first sentence had cost two hundred and forty hours.

The Signal Handover Note

The note below is the short form of the brief, written as the e-mail that carries it, for the many findings that do not need a meeting. It is six short paragraphs and it follows the five rules in order. Their time first, counts not adjectives, the step not the person, an offer not a demand, and the assumption that the owner has not seen this before. Fill the blanks from the signal brief and delete any sentence you added that contains a name or an adjective. Send it from whoever sits at the right level to be read as a colleague.

SIGNAL HANDOVER NOTE — THE E-MAIL THAT CARRIES THE BRIEF
To: ______________________ (owner, by role)     From: ______________________
Subject: Something we noticed about ______________________ that may be costing your team time

Hello ______________,

We've noticed a pattern in the help desk tickets that touches your team, and
I thought you would want to see it before anyone else does.

Over the last ____________, ______ tickets have come to us about
______________________________________. Looking at them together, they seem to
be about ______________________ (the step, the task or the system, not a person).

From the tickets, this looks like roughly ____ to ____ hours of your team's
time per ____________, and ____ to ____ hours of ours. Three examples, with
names removed, are #______, #______ and #______.

On our side we have already ______________________________________, which
makes each one cheaper but does not stop them.

One thing we could try: ______________________________________________, for
____________ (one run / one month). If it works, your team gets the hours back;
if it does not, we have lost nothing and learned something.

I will count the same tickets again on ____________ and send you the result
either way. Happy to talk it through for twenty minutes if that is easier.

Thanks,
______________________

Lena's second draft went to Gareth at ten to four and was answered at twenty past, with "I didn't know it ran during the batch. Moving it to the first. Send me the numbers." The sixty-one became four the following quarter, three of them from a month in which the first working day was a bank holiday. Gareth noticed that before Lena did and fixed it himself. He now sends her the month-end schedule in advance, unasked. The first draft is still in her drafts folder. She keeps it as a reminder of the e-mail that would have cost her the next three years of that relationship.

Frequently Asked Questions