ASL Tickets — Source library
Public documentation snapshot: 2026-09-08
Stop losing track of who asked for what.
Every request your team gets, tracked and owned, inside the product they already use.
Stop losing track of who asked for what.
Built for: An office manager or practice owner who is the unofficial help desk for everyone in the building · A city or utility administrator taking work requests from field crews, staff, and the front counter · A small operations team that answers customer questions and has no place to put them except a shared mailbox · An organization admin who has to answer 'what happened with that?' months later and wants a record, not a memory
ASL Tickets exists because of this.
Requests do not arrive in one place. Someone texts you. Someone stops you in the hallway on the way to a meeting. A client emails the address you check twice a week. A crew calls it in from the truck. By Thursday you cannot honestly say which of those got done, who did it, or whether anyone ever told the person who asked. So you ask around, and somebody says they thought somebody else had it. Email becomes the system by default, and email is a bad place for this work. A message has no status. It has no owner. The record is whatever is left sitting in one person's mailbox, and the day that person leaves, the history walks out with them. Meanwhile people put things into those messages that should never live in a shared inbox for years — an account number, a detail about a client, a photo of a document — and that copy is now on every phone and laptop that ever synced the mailbox. Nobody decided that. It just happened, one reply at a time. And when the problem is with the software itself, it gets worse. You write to a general address and hear nothing back. You cannot tell whether it was read, whether anyone owns it, or whether it is still open. So a week later you send it again, slightly angrier, and hope that this time it lands in front of a person who can actually do something about it.
ASL Tickets exists because of this.
The privacy claim is checked rather than asserted: an automated check fails if a request body ever reaches an outgoing notification email.
ASL Tickets exists because of this.
A request belonging to another organization answers "not found" instead of "access denied", so it never even confirms to the wrong person that it exists.
ASL Tickets exists because of this.
Attachments are never copied into a request. The request holds a reference into the encrypted file service, and a link to anywhere else is refused outright.
ASL Tickets exists because of this.
Every action on a request is sealed to the action before it, so an altered or deleted entry is visible instead of silent.
ASL Tickets exists because of this.
The public support page and the in-app request panel feed the same queue, so a message from someone without an account and a request from a signed-in user become one tracked item, not two.
ASL Tickets exists because of this.
The Android app is a real Android app, not a web page in a shell, and it never holds a service credential — only a short-lived session limited to one organization, one person, and one role, which it refuses to accept in any other form.
ASL Tickets exists because of this.
Internal requests and requests to Auto Secure Login are separated at the root, so our ability to see the support queue is not a route into your organization's own work.
How ASL Tickets works, start to finish.
ASL Tickets turns a request into a thing instead of a message. Someone asks for something, and it becomes a numbered request with a subject, a description, a status, a priority, and — as soon as someone picks it up — a name. It appears inside the Auto Secure Login product your team already has open, on the same screen and behind the same sign-in, so nobody logs in twice or learns a second tool. The person who filed it can see it too, which is usually what stops the third follow-up email. A request moves through five plain states — open, in progress, waiting, resolved, closed — and carries one of four priorities that an agent or admin can change as the situation develops. It can be assigned to yourself in one tap or handed to a teammate, so unassigned work shows up as unassigned rather than being quietly ignored. Replies stay attached to the request, stamped with who wrote them and what role they held, so the reasoning behind a decision is still there when someone reads it back in March. This is a shared queue and it behaves like one: everyone in your organization who can open the request panel sees your organization's requests, not only the ones they filed themselves. There are two lanes, and they never mix. A request inside your organization stays inside your organization: it is not visible to Auto Secure Login staff, and it is not visible to any other organization, including another organization using the same product. When you deliberately route a request to Auto Secure Login, it goes to our support queue, we get an alert, and you get told when we reply or change its state. Our staff view is limited to that lane; being able to see the support queue gives nobody a path into your internal requests. If someone with no account at all needs to reach us, the public support page turns their message into a real tracked request in the same queue, so there is one history rather than two inboxes. The content is treated as if it matters. Subjects, request text, replies, and the notification address are encrypted where they are stored. Request text and replies are not written into logs, not placed into a web address, and never carried in the email that tells you something changed — an automated check fails if a request body ever turns up in an outgoing message. The subject line is the deliberate exception: a notification names the request by its subject so the recipient knows which one moved, which is exactly why the form asks people to keep the subject short and plain. Files are never copied into a request either — a request can point at up to ten files held in the encrypted file service, and a link to anywhere else is rejected outright. Every creation, reply, status change, priority change, and assignment is written into a running history where each entry is sealed to the one before it, so an altered or removed entry breaks the seal instead of disappearing quietly. For people who are not at a desk there is a signed Android app — a real Android app, not a web page in a shell. You start it by pasting a short-lived connection code that the product you already signed into hands you; the app keeps that session encrypted on the phone, expires it on its own after about an hour, and lets you clear it whenever you want. It never holds a service credential of any kind, and it refuses the platform key outright. The phone app is also where the boundary is stated most fully: before it will let you send, you have to tick a line confirming you left out emergencies, clinical detail, passwords, payment data, private keys, and recovery codes. The panel inside your product prints the shorter version of that warning on the form itself. Either way the boundary is printed where people can see it, not buried in a policy nobody reads.
Everything in the current release.
Each of these is built and working today. Nothing on this list is a roadmap item.
One place every request lands
A request stops being a message you have to remember and becomes a numbered item with a state. It shows up inside the product your team already has open, so nobody signs in twice or learns another tool. The person who asked can watch it move, which is usually what ends the follow-up emails.
Two lanes that never mix
A request inside your organization stays inside your organization. A request to Auto Secure Login goes to Auto Secure Login. You pick the lane when you create it, and the two queues are separated at the root — our staff view of the support lane is not a door into your internal work.
Status you can answer from across the room
Every request carries one of five states: open, in progress, waiting, resolved, or closed. It also carries a priority — low, normal, high, or urgent — that an agent or admin can raise or lower as things develop. "What happened with that?" becomes a glance instead of a search through a mailbox.
A name on every request
Requests can be assigned to yourself in one tap or handed to a teammate by name. Work that nobody has picked up shows as unassigned instead of sitting invisibly in a queue. When something changes hands, the handover is part of the record rather than a hallway conversation two people remember differently.
The conversation stays with the request
Replies live on the request itself, stamped with who wrote them and what role they held at the time. Nothing important lives in a private thread a colleague cannot find. When the request is finally resolved, the reasoning that got it there is still attached to it.
A shared queue, on purpose
Everyone in your organization who can open the request panel sees your organization's requests, not only their own. That is what makes cover possible when someone is out and what stops a request dying in one person's view. It also means the queue is the wrong place for anything a colleague should not read, which is why the form says so before anyone sends.
Content encrypted where it sits
Subjects, request text, replies, and the notification address are encrypted at rest. They are kept out of logs and out of web addresses. If a stored copy or a backup file were ever taken on its own, what is on it is ciphertext rather than readable text — the service holds the key, so this protects the copy, not against us.
Request text never travels in notification email
When you reply or move a request's status, the person who opened it gets an email naming the request and telling them to open the product where they filed it. The request body and replies never travel in that email, and an automated check fails if a body ever appears in an outgoing message. The subject line does appear, so that people can tell which request moved — keep subjects plain.
Another organization's request does not exist for you
Separation is by organization within each product, not by an organization name alone. If someone from a different organization asks for a request that is not theirs, they are not told "access denied" — they are told it does not exist, which does not even confirm there is something to look for. An automated check covers that case.
Only the right roles can change things
A requester can open a request and reply to it. Changing status, priority, or assignment is limited to agents and organization admins. Auto Secure Login staff can act only on requests deliberately routed to us, and cannot open a request of their own inside your organization. Every one of those actions is written into the history with the name of the person who took it.
Attachments by reference, never by copy
A request can point at up to ten files held in the encrypted file service, and the request record itself never contains file content. Only references to that service are accepted; a link to anywhere else is refused. Delete the file in one place and there is no forgotten second copy sitting inside a request.
A history that shows tampering
Every creation, reply, status change, priority change, and assignment is written to a running record where each entry is sealed to the one before it. Editing or removing an entry breaks the seal on everything that follows. The service keeps that record; there is no screen or export for it yet, so if you need it produced you ask us and we produce it.
Requests from your phone
There is a signed Android app for people who are not at a desk — a field crew, an on-call admin, an owner between appointments. It is a genuine Android app rather than a web page in a shell. You connect by pasting a short-lived code from the product where you already signed in; the app keeps it encrypted on the device, expires it by itself after about an hour, and clears it on demand.
Requests from people with no account
Someone who has never signed in can send a message through the public support page, and it becomes a real tracked request in the same queue rather than landing in a separate inbox nobody watches. One queue, one history, one place to look. The visitor gets a real item, not an auto-reply.
Clear boundaries printed on the form
The phone app makes you tick a line confirming you left out emergencies, clinical detail, passwords, payment data, private keys, and recovery codes before it will let you send. The panel inside your product prints the shorter version of that warning on the form. Scoping the content on purpose is what keeps the record limited to administrative and support work, which is exactly what it is for.
Numbers we can stand behind.
Every figure below comes from the product's own release record or test suite, not from a marketing estimate.
Numbers we can stand behind.
It is already carried inside working Auto Secure Login products rather than sold as something you would have to stand up and configure yourself.
Surfaces and status.
Status as of 2026-09-02. Checked live on 2026-09-02: the service health check answered and the embedded request panel was served the same day. README records activation on 2026-07-31 with an end-to-end run over the public internet — a request created from one organization, appearing in the platform support queue, then assigned, replied to, and closed, with three real notification emails delivered. Request panels are carried inside working Auto Secure Login products: a real request was created through Repo Runner's own screen on 2026-08-01, and the panel shipped inside the Municipal Utilities release of 2026-08-18 alongside team chat and scheduling. The public support page has been filing real requests into the same queue since 2026-08-01. A signed Android client 1.0.0 was built and checked on two devices on 2026-08-23. Note for the site build: the service address itself is not a public page — it redirects to the homepage and is marked not to be indexed — so no visitor-facing link to it should be offered. Provenance note: the 2026-08-01 Repo Runner check, the 2026-08-18 Municipal Utilities release, and the public support page wiring are recorded in the operator platform notes rather than inside this repository.
Worth more together.
Products on this platform share one sign-in, one support queue, and one engineering standard. These pair naturally with ASL Tickets.
ASL Support
The public front door. Someone with no account describes their problem on one page and it becomes a real tracked request in the same queue, instead of an email nobody owns.
ASL Files
Where attachments actually live. A request points at a file held there rather than carrying a copy, so deleting the file really deletes it.
ASL Messaging
For the back-and-forth that is a conversation rather than a request. Chat handles the quick question; Tickets handles the thing someone has to finish.
ASL Command Center
Where requests routed to Auto Secure Login from across every product land in one queue, so an escalation is seen and owned rather than sitting in a mailbox.
ASL Therapy
A practice already using Therapy gets the request panel for administrative and scheduling questions from staff, with the clinical boundary stated on the form.
ASL Municipal Utilities
Field crews and counter staff raise work requests inside the same system they already use for billing and scheduling, so nothing lives on a separate notepad.
Recent progress.
This product ships often. The most recent verified changes, newest first.
Recent progress.
2026-08-23 a signed Android client, version 1.0.0, was built and put through a full check before signing: clean build, unit checks, release lint, and hands-on runs on an Android 15 emulator and a physical Pixel 8 on Android 14. That run covered connecting, creating a request, assigning it, changing status and priority, replying, resolving it, seeing the same state on a second device, losing and regaining network, relaunching with the session intact, clearing the session, and confirming the app refuses a credential it should never accept. Fresh crash checks after relaunch found nothing on either device. The store listing, data-safety notes, reviewer-access instructions, five phone screenshots, product icon, and feature graphic were prepared and the public upload certificate was published alongside the release; that is the most recent change in the repository.
Recent progress.
2026-08-18 the request panel shipped inside the Municipal Utilities release of that date, alongside team chat and scheduling.
Recent progress.
2026-09-02 the service health check and the embedded request panel both answered, and nothing has needed changing since the Android work, which is what a finished piece of the platform is supposed to look like.
Recent progress.
Pricing for ASL Tickets is quoted after a short conversation about your situation, because the right scope differs from one team to the next. There is no charge for that conversation.
What does it cost?
Pricing for Tickets on its own is not published. Today it comes with the Auto Secure Login products that carry it rather than as a separate line, so if you already run one of those, the request panel is there and there is nothing extra to buy. If you want it inside software you run yourself, tell us what you need and we will quote against that instead of a list price.
We already use email and a shared inbox. Why change?
Keep them if they genuinely work. What a mailbox cannot do is tell you the state of a request, who owns it, and what was decided, without a person remembering. It also cannot stop sensitive text sitting in plain form on every device that ever synced it. If you never lose track of a request and nothing sensitive is in that inbox, you do not need this.
Who in our organization can see a request?
Everyone in your organization who can open the request panel. It is a shared queue by design — that is what lets a colleague pick up your work when you are out, and what stops a request dying in one person's view. It also means it is the wrong place for anything a colleague should not read, which is why the form asks people to leave clinical detail, credentials, and payment data out before they send.
What happens to our requests if we stop paying or leave?
Your requests are yours. Retention follows the published privacy policy and whatever your organization asks for, and nothing in the design is meant to hold your history hostage. There is no self-service export button today, so if you are leaving, ask and we will hand your organization's request history back to you rather than making you screenshot it.
How safe is the content people put in a request?
Subjects, request text, replies, and the notification address are encrypted where they are stored and kept out of logs and web addresses. Request text and replies are never copied into notification email — that one is enforced by an automated check that fails if a body ever leaks into a message; the subject line does appear, so the recipient can tell which request moved. Requests are separated by organization, and another organization asking for yours is told it does not exist. The review behind those statements is our own, not an outside audit, and we say so rather than dressing it up.
Is it actually ready, or are we going to be the ones finding the problems?
It has been running on its own address since 2026-07-31 and answered its health check again on 2026-09-02. It has been driven end to end over the public internet — a request created, routed, assigned, replied to, closed, with real notification emails delivered — and it is already carried inside working Auto Secure Login products, including one where a real request was created through the product's own screen. The Android app was checked on two real devices before it was signed. What it does not have yet is search, escalation rules, and an export screen, and we would rather tell you that now.
Can we move our existing tickets in?
There is no bulk import today. Most teams start clean: new requests go here and the old mailbox stays readable for as long as you keep it, which costs nothing and avoids importing years of noise. If you have a history you genuinely need carried across, describe its shape and we will tell you honestly whether we can do it.
Can a client, resident, or customer file a request, or is this staff only?
Both. Someone signed into the product raises a request from inside it and can watch it move. Someone with no account uses the public support page, and their message becomes a real tracked request in the same queue rather than an email in a separate inbox. There is one history either way. Bear in mind that a request raised inside an organization is visible to that whole organization, so it suits administrative work rather than anything private to one person.
Who at Auto Secure Login can read our requests?
Our support view only holds requests you deliberately routed to us. A request you keep inside your organization is not in that view, our staff cannot open a request of their own inside your organization, and every action our staff take on a support request is recorded with a name. To be straight about it: encryption at rest protects stored copies and backups, but the service holds the key, so this is not a design in which we would be unable to read the content. That is why the form tells people to keep clinical detail, credentials, and card numbers out of it.
What should I know before I rely on it?
We would rather you hear this from us than discover it later. As of 2026-09-02:
What should I know before I rely on it?
A request panel shows your whole organization's requests to everyone in that organization who can open it. There is no per-person filter, so it is a shared queue, not a private mailbox.
What should I know before I rely on it?
Files are attached by reference to the encrypted file service. The phone app has a field where you paste those file references; the panel inside your product has no file field at all today, and neither has an upload button.
What should I know before I rely on it?
The notification email names the request by its subject line so the recipient knows which one moved. The request text and replies never travel in it, but the subject does — keep subjects plain.
What should I know before I rely on it?
Replying to a notification email does not add a comment. The email says so and points you back to the product where the request lives.
What should I know before I rely on it?
There are no service-level timers, escalation rules, scheduled reminders, or automatic routing.
What should I know before I rely on it?
A request view shows the 100 most recently updated requests. Search, filtering, tags, categories, and custom fields are not built yet.
What should I know before I rely on it?
The sealed history is kept by the service, but there is no screen or export that shows it to you. If you need it produced, ask us.
What should I know before I rely on it?
Deleting a request is not offered anywhere in the product today — not in the phone app and not in the panel. Retention follows the published privacy policy and your organization's own workflow.
What should I know before I rely on it?
A request or reply is up to 5,000 characters and a subject up to 240, so it is a place for a request, not for a long attached document.
What should I know before I rely on it?
The phone app is connected by pasting a short-lived code the product gives you, not by an automatic hand-off, and that session expires by itself after about an hour. Long sessions on a phone mean pasting a fresh code.
Stop losing track of who asked for what.
Prefer email? contact@autosecurelogin.com