Product decisions we have not made: customer requests, asks and SLAs

[imshashank]

Orbit's roadmap has a "Not doing" section, and one of the entries is:

Being a CRM, a helpdesk, a wiki platform or a spreadsheet. Orbit tracks work. Tools that do everything are the reason people are looking for a replacement in the first place.

That is a good principle and it is why most of Orbit is coherent. It also rules out, or appears to rule out, three features that every commercial tracker now ships and that people will keep asking for.

Rather than filing them as issues and pretending the question is settled, they are here.

The three

Customer requests

Linear has these: a customer record, and requests from that customer attached to issues, so you can see that eleven customers are waiting on one bug and weigh it accordingly.

The case for: it is not a CRM. It is a weight on an issue. The question "how many people asked for this and who" is a prioritisation question, which is squarely what a tracker is for. A team currently answers it with a spreadsheet or by guessing.

The case against: it needs a customer entity, and once there is a customer entity people want contacts, then fields, then history, and then it is a CRM. The line is easy to state and hard to hold.

A narrower version: no customer entity at all. Just a count and a set of links on an issue, from wherever the request came from. Less useful, much less likely to grow into something else.

Asks

Linear's Asks turns a Slack message into a tracked request, for teams that receive work from the rest of the company. IT, design, data, ops.

The case for: Orbit already has an intake table and a triage issue (#197), and the Slack milestone is already building message shortcuts. Asks is close to what those two produce when combined. It may already be most built by accident.

The case against: a helpdesk has a requester who is not a team member, a conversation with them, a resolution they accept, and a satisfaction signal. That is a different product with a different permission model.

The question: is there a version of this that is just "triage, with a Slack front door", and is that enough?

SLAs

A clock on an issue, and an escalation when it runs out.

The case for: it is a due date with consequences, and Orbit already has due_date on issue. Teams with any external commitment need it.

The case against: it only means something with a helpdesk around it, and it introduces the idea that some issues have contractual weight, which changes what a tracker is for. It also needs a business hours calendar, holiday handling and escalation rules, which is a lot of machinery.

What to say here

The useful comment is not "yes please" or "no thanks". It is what you are doing today instead.

• If you keep a spreadsheet of who asked for what, say what is in it and how you use it
• If your team receives requests from elsewhere in the company, say how they arrive now and what breaks
• If you have committed to a response time, say how you track it

That tells us whether there is a small version of any of these that solves the real problem without turning Orbit into three products. Descriptions of a painful workflow move things far more than a request for a feature, which is what CONTRIBUTING.md already asks for in feature requests.

What happens next

If a clear, narrow shape emerges for any of these, it becomes an issue with a design attached. If it does not, the roadmap's "Not doing" entry stands and this discussion is the record of why, which is worth having on its own.

Related issues: triage and intake #197, the Slack milestone, and the planning epic #205.