3. Primary uses: analytics, budgeting and billing

On billing

Klepsidra is a mixed-purpose product: it needs to be a platform for analytics on how and where time is spent, on a personal and commercial level. It aspires towards the kind—without the personally-invasive level of detail—of tracking that Stephen Wolfram’s method achieves. An important aspect of this is that it manages client billing, making it painless, quick and easy to use.

Essentially, time tracking is useful if it helps to:

• Bill accurately for your time
• Track productivity and see if tasks are taking longer than they should
• Discover and prioritize high-value tasks to boost business profits
• Discover and reduce non-billable tasks to minimize wasted time
• Understand your resource availability by estimating how many hours will be needed to complete tasks
• Schedule resources accurately
• Pay employees fairly for time spent on time-intensive tasks

The system will be considered successful if it manages all of the above.

Personal time tracking and analytics

Most of the day cannot be spent on work. Practitioners of every field must fill their time by maintaining their existing knowledge, putting into practice—even if bona fide—their skills to keep sharp, and learning and developing new skills and abilities. They will spend time branching out from their area completely, learing marketing, advertising, accounting, design, speaking a new language, and other areas but their own. It’s important to do this at a sustained pace, and consistency may be more important than the degree of measurable progress. It would be desirable to track these forays, the amount of time invested into learning or practising, a note describing what was done and learned in these sessions, and also a snapshot of consistency.

Insight into this will pay dividends in the future. Not only will it be easy to see how much time has been invested into any area, but it will be glaringly obvious if too much time has been spent, and if it may be better to [re]focust future attentions. The mind easily forgets things, especially without consistency. Data will bear out how consistent efforts have been, and will help foster regular, daily practice; by presenting time invested on a heatmap—not dissimilar to the way GitHub records our commitments to code—it is my hope that this will instigate a more serious approach towards learning and experimenting in me, for example.

A personal failing I have witnessed in me is that, while in the midst of it, I am sure what I have done, learned and achieved; at the end of the year though, I have forgotten most of what it was. By recording simple but deliberated notes for each timed activity, a timeline of exactly what I have learned will miraculously appear. To some, this will help at the next review meeting, or in future pay negotiations, to others it will be the embodiment of a living portfolio.

For personal analytics, activity tracking and analytics, I need the system to:

• Show me a list of high-level activities (catrgorisations) I engage in
• Sum the time I spend on activities, in a month, quarter and year
• Display a heat map, by day, of activities engaged in, by time spent
• Build a timeline and report, reminding me of things I have learned
• Calculate proportions between time spent on personal pursuits versus commercial ones
• Record activity times, not only durations, as it is valuable to know when I engage in certain activities, informing future personal time management

The system must differentiate from billable time, as well as other commercial time, e.g. time used internally for administrative duties, accounting, marketing and any other activities which are neither billable to a client, nor reflective of personal and professional development.

Budgeting and time estimation

One of the greatest problems I face is being able to estimate time needed for a project or task, or to quote a flat fee, while achieving any kind of accuracy. It’s not a unique problem and it isn’t even limited to the technical sector, though it’s most noticeable there. Many engineering projects—particularly civil engineering—fall prey to the same problem. Why is this? One obvious reason that’s common across many industries in the desire to please clients, or at least, not to scare them away with a high cost. This tendency, coupled with tender processes, often favours the least expensive provider, to put it reductively. Without ascribing any greed or malice, this tends to lead to projects which end up egregiously over budget and time estimates.

We get into this state of affairs not merely by misrepresenting the true picture to clients; we wilfully lie to ourselves, convinced that an optimistic time and cost estimate is going to be correct. Without oversimplifying matters, this is true for at least three reasons: (1) we believe we’ve learned lessons from the past and we will be faster now; (2) we ignore many of the things that may go wrong; (3) we budget way too little for unknown unknowns, which will become massive time sinks over the course of the project.

One factor that underlies all of this is lack of information. Since in software, construction, engineering and similar fields, past projects rarely perfectly mimic future ones, using past experience is never the most accurate predictor. However, this is squarely due to a lack of data. If we had detailed records of clearly defined stages—down to very fine levels of detail—which honestly included timing not only of the final success, but also all the dead-ends, bottlenecks and problems encountered, a sufficiently large corpus of this date would become statistically significant. Mining this data will yield a probability distribution as well as the ability to plot a trendline, with known margins of error, based on past execution. The more past data we build up, the more accurate trendlines will result, with tighter margins of error.

Both of these tools would lead us to more accurate estimation in the future. It is a truism that with more data—more projects carried out—our trendline would become more accurate and meaningful. The only solution is to diligently record all our projects and tasks to build up our data, helping us deduce more valuable timelines from that.

To achieve this we need to record:

• All types of projects, tasks and activities
• Record time taken honestly, without removing or reducing time spent on unpalatable problems
• Record activities consistently, recording a high level of detail in our categorisation to be able to use faceted search and filtering when analysing past activities

Our activity timer must not allow easy modification of the actual time recorded, like an accounting system, paving the way to auditing our past successes and mistakes.

Billing

Billing is an important area, as many professions need to bill for their time, according to how much time has been used for a client. It is easy to build a primitive timer, and there are many in existence; Klepsidra has lofty goals which need sophisticated handling.

In timing activities, we strive for an append-only recording strategy, in a practical sense. This means that Klepsidra will not do anything to help changing the past and rewriting activity timings. However, there are many ways this can backfire.

• We forget to start a timer when we start a new task
• We forget to stop a timer on time
• We are not near any user interface exposed by Klepsidra, or there is a technology failure preventing us from accurately timing an activity
• We are unaware at the time of starting something that this is actually a timeable activity

There are surely more reasons than that, but what is important is that there will be lapses, which must be handled to result in the quality of data we desire. A design decision is to provide three types of time tracker: (1) automated tracker activated by start and stop actions; (2) a manual timer where all data available in the first timer may be manually recorded; and (3) a simple duration log, where times are not available at all, and only the task duration is recorded.

The automated timer interface will actively prevent any changing of start and end timestamps. To handle recording errors identified, an adjustment field will be provided, paired with a categorisation of correction and a description field to explain the particular circumstance. The adjustment time unit will match the actual duration unit, e.g. if the duration is counted in minutes, the adjustment will be in minutes.

The manual timer needs to be available to retroactively record activities which wasn’t possible with the automated timer, either because of technical problems, use in a strict offline environment, because of a user’s recording by analogue means, and other similar reasons. In this case the interface will record all the same information, but start and end dates will be manually entered. As this is a manual entry, no adjustments will be made to the duration, since it is expected that any lost time has been accounted for in the timestamps.

The third type of recording will have only the duration field. This is believed to be necessary as there will be many practitioners and activities where accurate time recording isn’t practical. Instead, they will report the actual time taken, in minutes or hours. This feature necessitates using a floating point recording of duration, particularly when hours or days are used as the recording unit.

In all three cases, a further adjusting entry is desirable: billable time. Despite being able to configure Klepsidra to round up time durations for billing, or round it down, there will be many situations in which a time increment has only just been broached, and it may be desirable to adjust the billing down to the next lowest block. Just as with duration adjustments, an adjustment category and reason should be provided. This reason may be passed through to the invoice for building up customer trust in the billing process, providing transparency. The correction will be denominated in the same time unit as the calculated duration. The billable increment (see below) is calculated from the total duration, including the billing adjustment.

Timed activities need to be categorised as billable, which will impact client invoices, personal/professional development—for personal analytics—and other for activities that don’t follow either of these patterns.

Time increments used in billing

The easiest form of billing is per-hour billing. This has its own disadvantages as it is a very coarse measure, which is a contentious tug-of-war between clients who obviously prefer much finer increments, in some examples demanding down to per-minute detailed charging, and service providers who tend towards more coarse time units. There is much to be said for both tendencies, but what is really important is that there is no standard and many billing increments are used in commerce.

To name a few examples, those in the legal profession often use tenths of an hour—six minute increments; customer support may use the even finer five-minute increments; Medicare practitioners use eight-minute blocks; quarter-hour (15 minute) increments are used across most service providers; designers, developers and other professionals use half-hour, hour, and even two-hour blocks. In fact, this is a business-specific decision, and there are often complex policies using a combination of several of the above.

To satisfy all the above needs, Klepsidra needs to provide all the above increments for flexibility across all practical service providers’ requirements. The ex_cldr_unit library makes it relatively easy to create custom units, based on those already in the library. The catch is that this is not a dynamic process, rather a pre-defined and compiled one “…units are compiled into code” (Elixir-Cldr/Cldr_units, 2017/2023). This forces the hard-coding of all possible increments into code to be able to rely on all these complex time conversions, whereupon the user interface will have to be used to limit the list to only desired increments. A good explanation states “Common billing increments range from minutes to hours, each serving specific purposes and preferences within different industries and professions” (Forecast, 2024).

Compiled list of all sensible billing increments to be used

Below is a list of billing increments in use to some extent across a range of service providers. Is is important to keep in mind that, whichever billing increment, Klepsidra will—by default—round up towards a multiple of that increment. For example, if 13 minutes have elapsed, this would be equivalent to three 6-minute, two 10-minute, one 1-hour increments, for example, and would be invoiced pro-rata according to that calculation. Please note that, when all the increments are taken into account combinatorically, there is a wealth of billing choices here!

That’s fourteen different billing increments there, in addition to the base unit—minute—which should provide sufficient flexibility to most service providers. This is not a complex system, and precludes use by some regulated professionals such as the previously mentioned physical therapists and related providers on Medicare, for example. Successfully providing for their needs requires a more complex calculation, including time ranges, providing the ability to define staggered, unequal billing increments, as well as those where there is an initial flat fee increment, followed by finer increments once a predefined lenght of time has elapsed.

References

• Cldr.Unit—Cldr Units v3.16.4. (2023, November 2). https://hexdocs.pm/ex_cldr_units/Cldr.Unit.html#content

• Elixir-cldr/cldr_units. (2023). [Elixir]. Elixir CLDR. https://github.com/elixir-cldr/cldr_units (Original work published 2017)

• Forecast. (2024, March 18). What are Billing Increments? https://www.forecast.app/learn/what-are-billing-increments