An organization with several departments, many systems, and a monthly report built by hand

The customer is not named, and figures are given as shares. This is an Israeli organization with several departments and many internal systems, working with us on a long-running development contract. Before SLAtech Vantage the monthly report was assembled by hand, hours were not tied to tasks, and we heard about failures from users. Today almost every task arrives by sync, every hour sits on a task, and the customer sees the month themselves.

What it looked like before

Hours were kept in spreadsheets, month after month: a row with a date, a description, a department and a number of hours. No task appeared on the row, so the question "what did these hours go on" was answered from memory.

The monthly report was built by hand at the end of each month, from the spreadsheet, the mail and the tickets. Correspondence sat in one mailbox, and decisions made in conversation were recorded nowhere.

We heard about server failures mostly when a user got in touch. There was no list, only stories.

What we connected

We asked nobody to move to a new tool. We connected the places where the work already happened:

• The customer's ticket system. Every ticket arrives by sync as a task, with the original text, the number the customer knows and the status in their own words.
• The project mailbox, with selection rules by address or domain, attachments included.
• Messaging conversations, as an export file loaded by hand, with no connection to a phone.
• The system's error feed, collected with no agent and no change to the code.
• The hour history from the spreadsheets, loaded once.

What the customer sees today

The customer signs in to the portal and sees the month's report, grouped by department. Each department has its hours and its amount, and can be opened to show the tasks inside it. Every line carries the customer's own ticket number, not only ours.

Above the report sits a monthly summary written automatically from the same data. Beside it is a chat that answers questions in ordinary words, and its search is confined to the customer's project and to the kinds of material explicitly opened to them.

Before text leaves for an external language model, names, ID numbers, phone numbers and email addresses are replaced with labels.

What changed, in shares

We have no reliable measurement of "before", so there is no "we saved this many hours" here. There are shares that can be checked:

• About 98 tasks in 100 arrive by sync from the ticket system. The rest are opened from mail, from a conversation or by hand, and none is typed twice.
• Every hour recorded in the system is recorded against a task. An hour without a task simply has nowhere to go.
• More than 99% of correspondence participants are recognised as people on the project rather than address strings.
• Almost half of the questions to the chat come from the customer's side.
• About seven in ten of the customer's actions in the portal are opening the monthly report.

Failures: a short list instead of stories

Server errors are grouped by signature, and each group gets a kind and a severity. The difference from a raw list is large:

• On average, more than a thousand occurrences of the same error count as one group.
• About 98% of groups are classed as real errors; the rest are noise or an external service.
• Fewer than one group in fifty is rated above "low". That is what needs attention.
• A new group produces one letter, and a group that returns after being closed produces a separate one.

What did not work, and what is not there yet

• Departments. A ticket that arrives by sync arrives without a department. In practice only about one task in ten has been given one: it is a human step, and no sync does it.
• Solutions to failures. There is a solution field and a mechanism that looks for similar solved groups. No solution has been recorded for any group yet, and a single task has been opened from error monitoring so far.
• Where in the code an error came from is recognised for only about two groups in five, because not every error arrives with a stack.
• The knowledge base is empty. The chat answers from tasks, mail and conversations.
• Month closing with submission and acceptance exists in the system, and has not been switched on for this project.

What we learned

1. Connect, do not ask for reports. What is recorded anyway in the working tools reaches the report without anyone remembering to write it.
2. Label history honestly. Years of months loaded from the spreadsheets are marked "approved (history)", a state separate from acceptance done in the system. Nobody pressed a button there and there is no report snapshot, so they are not presented as if there were.
3. A mechanism without material is empty. Solutions and articles are written by a person, or not at all.
4. The customer comes for the report. The access journal in the portal was opened so rarely that its menu entry was removed. The page itself is still reachable at its address.

Frequently asked questions