The customer signs in and sees their own month

In most working systems the customer signs in nowhere. They get a report at the end of the month, sometimes as a file, and ask about it on the phone. Here they sign in and see the same month themselves, at the same moment we see it.

What is there in the first second

The first screen is the month's activity report. Work is grouped by department, each department carrying its own hours and its own amount; a department can be opened to see what exactly was done inside it. Recurring payments such as hosting and subscriptions stand apart from hours: they answer a different question, and mixing them into the same line would be wrong.

Every line of work also carries the number the customer knows, not only ours.

A monthly summary that writes itself

Above the report sits a short summary of the month. It is written automatically from the data of that same report: the main directions, the volume, the comparison with last month. It is not a text somebody typed at month's end, and it is not a guess: when there is not enough data it says so plainly rather than inventing. There is a button to refresh it.

The summary exists for one quite specific moment: when the customer needs to show their own manager, in a sentence, what happened this month.

Questions in ordinary words

The portal has a chat over the project's knowledge base. You ask in plain words: what failures happened this month, what a given system cost, what was done last quarter. The chat keeps the context, so you can follow up with "and in May?" without repeating the question. There are ready-made questions in one click as well, such as "make a summary for my manager".

What the chat will not answer, and why that matters

The customer's chat is not our chat with a hide button. It is built differently, on three lines of defence.

• The search is always confined to their project, and that is not a condition somebody can forget to add;
• the kinds of material they can reach are set by a whitelist, so anything not on the list is invisible by default, including internal kinds written later that nobody will remember to block;
• the customer sees the sources of an answer, and each one opens right there as the text of the fragment the answer was built on; what they do not get is a link into the internal task screen: that screen is not theirs, and a link there would promise a door that will not open.

And above all of it, text leaving for an external model passes through masking of personal identifiers.

Export, when a file is needed

The report exports to Excel and to PDF in one click, ready to show without further editing. The export itself is recorded: in the customer's activity journal, and on our side as data leaving the system.

The customer sees what was done with their data

The portal has an access journal page with two filters. It states what the contractor did with their data: what was created, changed, deleted and exported. This is not a statement of intent in the terms of use; it is a list.

The menu entry for this page was removed (customers opened it a handful of times); the page itself is alive and reachable by its address.

The portal carries the mark of whoever does the work

At the top of the portal stands the mark of the company working with the customer, not ours. This is the contractor's instrument in conversation with their own client, not our advertising in somebody else's house.

What is not there yet

The entry to "specification request" was removed from the menu while the customer's workspace is off, and the screen itself is alive at its address. Browser notifications exist in the code and have not been confirmed by us in production, so we do not promise them.

Frequently asked questions