Service and the customer portal

A target counted in elapsed time punishes you for having a weekend

An organisation agrees to respond within four hours. A customer raises something at four o'clock on Friday. In a system counting elapsed time, that is breached by eight on Saturday morning, when no one was ever going to be working and when no one, including the customer, expected a response. Consonas counts that target against the week your organisation is actually open, so the same promise falls due on Monday morning.

What happens next is the interesting part. The organisation does not start working weekends. It stops believing the targets. Within a couple of months the breach figure is a number everyone knows to ignore, which means it has stopped functioning as a measure of anything, and the genuine breaches are hidden among the artificial ones.

Counting in working hours fixes it completely and is not difficult. Four working hours from Friday afternoon is Monday morning, which is what both parties meant when they agreed it. The measure then reflects reality, which is the only condition under which anyone acts on it.

A customer who cannot see anything will telephone

The second failure is that the customer has no way of knowing what is happening. They raised something, they heard nothing for two days, and their only option is to ring and ask. That call costs you more than the update would have, and it arrives at whoever picks up rather than whoever knows.

A portal where they can see their own matters removes most of those calls, and the ones that remain are usually the ones worth having. It also changes the tone of the relationship: someone who can see that their problem is being worked on is considerably more patient than somebody who cannot see anything at all.

And the third one, which is quieter

Support knows things the commercial side does not. The account that has raised eleven problems this quarter is known to whoever answers and unknown to whoever prepares the renewal, because they live in different systems.

Matters attached to the relationship, on the same timeline as everything else, closes that gap without anybody having to remember to mention it.

Viewing, working on, and managing

There are three permissions here instead of one. Viewing lets someone read matters and the correspondence on them. Working lets somebody raise one, write back, add an internal note, move a matter between states and change who it is assigned to. Managing is the smaller and more consequential one: it is what lets someone give a customer access to the portal, or take it away again.

The split exists because those are three different levels of trust. A great many people in a small organisation should be able to see what support is dealing with. Rather fewer should be able to answer a customer in the organisation's name. Fewer again should be able to decide which customers can sign in and read things.

Viewing a matter also means seeing the week it was measured against

Anybody who may see a matter may also see the working hours screen: the days the organisation is open, the time zone the targets are counted in, and the closed dates that were left out of the arithmetic. That is on purpose. A target is a claim about time, and a claim about time that cannot be checked is one someone will argue with until it is switched off. The closed dates are read from the published bank holidays for the nation the organisation chose, so they are not a list here that quietly goes stale. Changing which nation applies is a different permission again: it belongs to whoever administers the organisation, not to whoever works on matters.

Attaching a matter to a relationship checks the relationship permission

When a matter is raised against a customer record, the check performed is not a service permission at all. It is the ordinary permission to see that relationship, the one defined in administration. Somebody restricted to their own accounts therefore cannot open a matter against an account they are not allowed to see, and cannot reach it afterwards by finding it in a list of matters instead.

Sensitivity works the same way. A matter about a relationship marked sensitive is itself sensitive, and is excluded from lists, from search results and from the record view for anybody who may not reach sensitive records.

A portal user is not a member with fewer permissions

A customer with portal access is a separate kind of principal. They are held in their own table, not in the staff table with a flag on it, and none of the staff permissions apply to them at all. They never appear in the member list, they are never counted against the number of users on your plan, and there is deliberately no route that takes a customer's identity and reaches anything a colleague would see.

The flag on the accounts table is the cheap version of this and it is the version that eventually goes wrong, because a flag is one forgotten condition away from a customer appearing in a list of colleagues. The cost of doing it properly is that a portal user cannot be given a role, cannot be granted anything, and cannot be dealt with by the tools that manage members. That is the intended cost.

Which plans carry it

Matters, the portal and the article store arrive together on the Professional plan and above. They are not on the free plan and not on the plan below. If service is the reason you are looking at this, that is the plan to price, and it is better to know it on this page than after a trial.

The obligations are not part of that. The audit trail, the consent records, the tooling for answering a subject access request as the Information Commissioner's Office describes it, two factor sign in and the complete export are on every plan including the free one, permanently. Everything a matter records about a person is covered by them, whatever you pay.

Not a full service desk

No queue routing. No escalation matrix. No shift rota or coverage planning. No automatic assignment by skill or workload. No telephone integration. A matter is assigned by a person choosing a colleague, which is fine at ten and wrong at forty.

For an organisation of ten to a hundred people where service is part of what everyone does, matters with targets attached to relationships is usually more than enough. For a support operation with forty agents and a queue discipline, it is not, and a dedicated product is the right purchase.

Reporting across matters is thin

The overview counts what is past its response and resolution targets, and the portal records a score when a matter closes. What is not written is the breakdown a service manager wants: by team, by target, by month, with a trend. That is a real gap for anyone managing service as a function rather than as something everyone does, and it is on the roadmap by name.

Define your working hours before anything else

Everything that counts time here counts it in your hours rather than elapsed ones, so this one setting decides whether every target in the product is honest.

Get it right including the parts people forget: the day you close early, the fact that Saturday is not a working day for you even though someone occasionally works it, and the holidays. A business with elapsed time targets does not start working weekends. It stops believing the targets, and then the genuine breaches are hidden among the artificial ones.

Start with two targets, not six

One for how quickly someone hears back, and one for how quickly the thing is resolved. Those two answer almost every question a customer actually has, and they are the two anybody can remember without looking them up.

Priority tiers can come later, once you have a quarter of data telling you whether the distinction is real. Most organisations that begin with four priorities discover that three of them behave identically and the fourth is used for whoever complained loudest.

Set them from what you already achieve, then improve

Not from what would sound good on a website. Look at what actually happened over the last month, take the number you hit most of the time, and set the target there.

A target set at what you currently achieve is immediately credible, and it produces the one thing you want from a first quarter: a breach means something went wrong rather than meaning the target was always fictional.

Decide what a matter is

Not every question is one. If someone rings and the answer takes forty seconds, that is a conversation and it belongs in the timeline. A matter is something you owe an answer on that you cannot give immediately.

Getting this line wrong in either direction is the usual reason the numbers stop being useful. Too broad and the volume is meaningless. Too narrow and the work people actually spend their day on is invisible.

Decide about the portal separately

On the plans that carry it, a customer can sign in and see their own matters and nothing else. Whether you want that is a judgement about your business instead of a feature question.

It removes a category of telephone call that costs more than the update would have. It also means your progress is visible, which is uncomfortable on the weeks when there has not been any. Both of those are true and the second is the reason to decide deliberately rather than by default.

What is open, and how old the oldest is

The count on its own says very little. The age of the oldest thing in the queue says a great deal, because a queue with a healthy count and one item that has been there for five weeks has a problem the average is hiding.

What breached, and where in the process

A breach on first response is a capacity problem. A breach on resolution with a prompt first response is usually a dependency problem: you are waiting for someone else, a part, or a decision. Those are entirely different failures and the total conceals both.

What reopened

The most honest measure of whether the work was actually done. It is also the one most likely to be low for the wrong reason, which is customers giving up rather than being satisfied.

What came in, by cause

Over a quarter, the reasons matters are raised are a description of your product or service rather than of your support. Read together they usually name one thing that, fixed at source, removes a category of work permanently.

The two that mislead

Average resolution time. Dominated by whatever is easiest, so it improves when you handle more trivial matters and worsens when you finally clear something difficult. The oldest open item is a better question.

Volume, on its own. Falling volume is as likely to mean customers have stopped bothering as it is to mean things are working. Read it against reopened matters and against how many customers raised anything at all.

Friday, twenty to five

The owner of a coffee shop, invited to the portal from her contact record, goes to the organisation's portal address and types her email address. She is told that if that address belongs to a customer here, a link is on its way, and she is told the same thing whether or not it is, because answering differently would turn the page into a way of asking whether a named person is a customer of this firm. The link that arrives lasts fifteen minutes. Spending it leaves her signed in to that browser tab and takes the link back out of the address bar, so it is not left behind in a history or a bookmark.

She raises one thing: the grinder stops halfway through a shot. What is written at that moment is a matter with a new reference, her first message recorded as being from the customer, a line on her relationship timeline naming the reference and the subject, and an entry in the audit trail attributed to her, with the role recorded as portal rather than as any colleague. The two deadlines are worked out and stored. Twenty minutes of Friday remain, so the response deadline falls at twenty to one on Monday, and the resolution deadline falls at twenty to five on the following Friday. Nobody is asked to do anything over the weekend and nothing is breached during it.

Monday, and the part that is easy to get wrong

Because she raised it herself, the matter has no owner. That is the first thing the engineer on duty does at five past nine: take it. He then writes an internal note to himself and a colleague, saying that the same model did this in March and it was the hopper switch rather than the burrs. That note does not touch the response clock.

At twenty to ten he writes back to her properly, and that message sets the first response time. The record now says it was answered in an hour of working time. Sixty five hours of clock time have passed. Both numbers are true and only one of them is about how the firm performed.

Wednesday, and an assumption that does not hold

A part is ordered and he moves the matter to waiting on the customer while she confirms a morning he can visit. The resolution deadline does not move. Waiting is a state, not a pause, and Friday afternoon is still the number the matter is measured against. If that is the wrong behaviour for your business, it is better to find out here than in a report.

He visits on Wednesday, replaces the switch, and marks the matter resolved. She sees it in the portal as resolved and awaiting her confirmation, and she can see the whole conversation apart from the internal note, which she has never had any way of reaching.

Thursday, when it happens again

She writes back on the matter to say it did it twice that morning. Her reply reopens it: a resolved matter that the customer answers goes back to open, because a customer writing again is the plainest possible evidence that it was not finished. No one has to notice and reopen it by hand, which is the version that depends on somebody being conscientious on a busy day.

He returns on the Friday, finds the grinder burrs were the cause after all, and resolves it a second time. She opens the portal and confirms it. Only then does the matter close, and the time she confirmed is written on to the record next to the time it was resolved.

Three months later

Somebody preparing her renewal opens the relationship rather than the service screen, and the timeline carries that matter among the appointments, the notes and the correspondence. They can see that she had a problem, that it took two visits, and that she confirmed the end of it herself. None of that required anybody in support to remember to mention it to anyone in sales, which is the entire point.

The relationship timeline gets a line, not a copy

Raising a matter against a customer writes an entry on that customer's timeline naming the reference and the subject, sitting alongside the stage changes, the correspondence, the appointments and everything else. The matter itself continues to live in service. The timeline holds the fact that it happened and when, which is what somebody reading the relationship needs, and it links to the record for the part they do not.

Search finds it by reference, under the same rules

A matter is indexed under both its reference and its subject the moment it exists. Search results are then judged record by record against the permission that governs that kind of record, so a matter appears in a colleague's search only if they could have opened it from the service screen. That sounds obvious and is the exact place where permission models usually leak: the second route in, which someone forgot to check.

The audit trail records the customer as the customer

Raising, replying and every change of state are written to the audit trail. When the action came through the portal, the trail names the customer, with the role recorded as portal, and a note saying it was raised through the portal by the customer. It is never attributed to a colleague who happened to be looking. An audit trail that mistakes who did something is worse than no audit trail, because it is confidently wrong in the one situation where someone is relying on it.

The working week decides more than targets

The same schedule that a response target is counted against is what the workload view uses to work out how much capacity a period holds. A closed day is therefore a day without capacity and a day that no target runs through, from one definition, and the two views cannot come to disagree about how long a week is.

The arithmetic itself is walked day by calendar day rather than by adding hours to an instant. That sounds like a detail until a clock change, when adding twenty four hours skips a local day and every target in the week after it is quietly wrong.

Retention names matters by name

Matters are one of the record kinds a retention rule can be written against, which means the decision about how long you keep what a customer told you when they were upset is made in the same place as the decision about correspondence, leads and the audit trail. It is not a service setting, and it is not a thing anyone has to remember to do by hand.

A matter raised in the portal announces itself

A matter raised by a customer raises an event that the automation and webhook machinery can act on, carrying the matter and the relationship it belongs to. That is the hook for the two things organisations want first: telling somebody, and putting it in front of the right person before anybody has opened the service screen that day.

The trades where a customer is waiting on you

Response targets matter most where someone cannot work until you answer. Maintenance and facilities lives on agreed response times against a working week, technology holds support alongside the commercial relationship it affects, healthcare administration handles enquiries where sensitivity is the first question, and local service businesses field the calls that a portal removes. The targets that suit each are set out on those pages.