Why we built TagOrbit
The idea behind TagOrbit: start from what your company runs, show an estimate as an estimate, and keep every hand-over as dated history.
The short answer
Most tracking tools hand you a template and ask your business to fit it. TagOrbit starts the other way round: it asks what you run.
We built TagOrbit because a tracking tool should fit your business, not the other way round. So TagOrbit starts with a question: what do you run?
Who makes TagOrbit?
TagOrbit comes from the same company in Athens, Greece, that makes TagPulse, a tool that monitors the health of computers. Our About page tells you more about the company.
Why not start from a template?
Most trackers hand you a template and a rulebook. The template decides what you can record. The rulebook decides the steps and the words. Your business has to bend to fit them.
But no two businesses run the same way. A construction company thinks in machines, engine hours and fuel. A camera hire company thinks in kits and bookings. An IT team thinks in laptops, licence seats and people who join and leave. One fixed template cannot fit all of them, so someone ends up working around the tool.
What does TagOrbit do instead?
TagOrbit asks what you run. You describe your business in one sentence. TagOrbit proposes categories, fields, alerts and departments for it. You keep, rename or delete each one, so the screens use the words your company uses.
A category can hold anything: things you own, the people and companies you deal with, or things that happen. Features such as custody, meters, bookings and kits are switches you turn on per category, only where they fit. Almost nothing is required, so a record always saves, even when you only have part of the information.
Why does an estimate say it is an estimate?
Some dates are facts. A warranty ends on a set day. Other dates are guesses. A machine's 500-hour service has no fixed date: it depends on how hard the machine works.
We think a guess should never look like a fact. When TagOrbit works out a service date from meter readings, it labels the date as estimated and names the reading it came from. You can see why the date is where it is, and judge it for yourself. A time backstop always applies as well, so the date never depends on the readings alone.
Why keep custody as history?
The quick way to record who has something is one field with a name in it. When the item changes hands, you type over the old name, and the past is gone. Later, nobody can say who had the item before, or for how long.
In TagOrbit, each hand-over is a dated span with a name on it, never an overwritten field. You can see who held an item, from when to when. An optional due-back date raises an overdue alert. When someone leaves the company, one action, Return everything, returns all they hold.
The same idea runs through the whole application. Every change keeps its before and after, with who made it and when.
What is the idea, in short?
| What we chose not to do | What TagOrbit does instead |
|---|---|
| Hand you a template and a rulebook | Ask what you run, then propose a setup you can keep, rename or delete |
| Show a calculated date as if it were certain | Label an estimated date as estimated and name the reading it came from |
| Keep one holder field and type over it | Keep each hand-over as a dated span with a name on it |
You can see what TagOrbit can track, or start free.