Case studies

A small software agency, several clients, and a report nobody assembles any more

A composite from our practice: what was connected, what the client saw mid-month, and what it does not solve.

This scenario is assembled from our practice; the names are fictional. A small software agency works with several clients, and one of them, "Urban Retail", buys a few hundred hours of development a month. Before SLAtech Vantage the report was built by hand, and "where did the hours go" came back every month. After connecting, the client opens the month themselves, forecast to month end included.

Who is in the scenario

An agency of a few people, with several clients at once. Each client has a task tracker, time tracking, a code repository and error monitoring, and each also has a mailbox and a messaging group.

The client at the centre is "Urban Retail", the fictional name of a company with ten departments the work is split between. The pace on it is about 2.6 full-time positions.

The month before: a report that arrived too late

At the end of every month somebody at the agency assembled the report by hand: pulled hours from time tracking, matched them to tasks, split them by department and wrote a few paragraphs. The client got a file, and the following week phoned to ask about the lines they did not understand.

The problem was not that the report was wrong. The problem was that it arrived when nothing in that month could be changed any more.

What was connected

  • The task tracker and time tracking the team already worked in. Tasks and hours arrive by sync, and every line of hours keeps the rate it was recorded at.
  • The code repository, so that commits are part of the project's history too.
  • Error monitoring of the production system. Identical errors are grouped into one group with a counter.
  • The project mailbox, with rules by address and domain.

The client portal carries the agency's mark, not ours.

What the client saw on the 20th

On the twentieth, without asking for a report, the client opened the portal and saw:

  • 420 hours logged so far, together with the amount for them;
  • 64 tasks, 58 of them already completed;
  • 214 monitoring events that month;
  • a month-end forecast of 465 hours, against an average of 412 hours for the same month in previous years.

The largest department, the recommendation and ranking engine, took 88 hours across 7 tasks. The client opened it and saw the time entries behind each task.

The gap between 465 and 412 came up in a conversation in the middle of the month, not in the end-of-month report.

Month end: submission and acceptance, not a file

At month end the agency submits the month to the client, and from that moment the hours are locked for both sides. The client either accepts, and a snapshot of the report is kept, or returns it with a note, and the hours open again while the note stays with the month.

Above the report sits a monthly summary written automatically from the same data, and the report exports to PDF and Excel in one click.

A note sent back with the month is a record, not a quarrel: six months later you can see what was asked and what was fixed.

What stays private

  • Rates, cost and margin are not shown to the client by default.
  • The internal split of the hours shows, of the hours billed, how many the team did itself and how many went to subcontractors. Margin is calculated from it, so only the business owner sees it. The client sees exactly the same billed hours, without the split.
  • The warnings journal is private: when the client asked for a solution against advice, what was advised and what was decided is written down.
  • A monthly cap in money on a task highlights an overrun for both sides and does not block time entry.

What it does not solve

  • If the team does not log hours, there is nothing to build a report from. SLAtech Vantage does not invent hours.
  • Assigning a task to a department is still a person's decision.
  • A knowledge base starts working only after somebody writes its first article.

What the agency gained in this scenario is not a number of hours saved, because we did not measure that. It gained one conversation in the middle of the month instead of one argument after it.

Frequently asked questions

Is this story real?
Not as the story of one customer. It is a scenario assembled from our practice, and the names in it are fictional, "Urban Retail" included. The figures are the ones shown on our example screens, and they agree with each other: hours, tasks, pace and forecast all come from one invented month. The mechanisms described, from the month-end forecast to submitting the month to the client, exist in the system.
How is the month-end forecast calculated?
The forecast is built from the pace of work already recorded in the current month and is shown beside the average for the same month in previous years. The expected amount uses the average rate of the work already done that month rather than a single project rate, because every line of hours keeps the rate it was recorded at. Recurring payments such as hosting are not included in it.
What happens if the client disagrees with the month?
They return it with a note. Returning opens the hours for editing again, and the note stays with the month, with who wrote it and when. After the correction the agency submits again. An accepted month is locked and a snapshot of its report is kept; changing it requires a request to reopen, and that request is recorded with its reason too.
Does the client see our rates and our margin?
No, unless the agency chooses to show them. Rates, cost and the margin on the project are private by default, as are the team's internal discussion and the warnings journal. The client sees the tasks, the hours that went into the report and the amount per department, so they understand what they are paying for. Other clients' projects are fully isolated from them.

Want to see your client's month like this? You can start with a trial.

Start a free trial